mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-25 02:32:18 -05:00
RFC 5489
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2439 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
parent
45669acfa1
commit
d431c15912
@ -522,7 +522,7 @@ INITIATOR RESPONDER
|
|||||||
<section2 topic='Connectivity Checks' anchor='protocol-checks'>
|
<section2 topic='Connectivity Checks' anchor='protocol-checks'>
|
||||||
<p>As the initiator and responder receive candidates, they probe the various candidate transports for connectivity. In performing these connectivity checks, each party SHOULD follow the procedure specified in Section 7 of &icecore;. The following business rules apply:</p>
|
<p>As the initiator and responder receive candidates, they probe the various candidate transports for connectivity. In performing these connectivity checks, each party SHOULD follow the procedure specified in Section 7 of &icecore;. The following business rules apply:</p>
|
||||||
<ol>
|
<ol>
|
||||||
<li>Each party sends a STUN Binding Request (see &rfc3489bis;) from each local candidate it generated to each remote candidate it received.</li>
|
<li>Each party sends a STUN Binding Request (see &rfc5489;) from each local candidate it generated to each remote candidate it received.</li>
|
||||||
<li>In accordance with &icecore;, the STUN Binding Request MUST include the PRIORITY attribute (computed according to Section 7.1.1.1. of &icecore;).</li>
|
<li>In accordance with &icecore;, the STUN Binding Request MUST include the PRIORITY attribute (computed according to Section 7.1.1.1. of &icecore;).</li>
|
||||||
<li>For the purposes of the Jingle ICE-UDP Transport Method, both parties are full ICE implementations and therefore the controlling role MUST be assumed by the initiator and the controlled role MUST be assumed by the responder.</li>
|
<li>For the purposes of the Jingle ICE-UDP Transport Method, both parties are full ICE implementations and therefore the controlling role MUST be assumed by the initiator and the controlled role MUST be assumed by the responder.</li>
|
||||||
<li>The STUN Binding Requests generated by the initiator MAY include the USE-CANDIDATE attribute to indicate that the initiator wishes to cease checks for this component.</li>
|
<li>The STUN Binding Requests generated by the initiator MAY include the USE-CANDIDATE attribute to indicate that the initiator wishes to cease checks for this component.</li>
|
||||||
|
@ -199,7 +199,7 @@ INITIATOR RESPONDER
|
|||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td>Permissive</td>
|
<td>Permissive</td>
|
||||||
<td>Server reflexive or peer reflexive candidate discovered via STUN (see &rfc3489; and &rfc3489bis;)</td>
|
<td>Server reflexive or peer reflexive candidate discovered via STUN (see &rfc5489;)</td>
|
||||||
</tr>
|
</tr>
|
||||||
</table>
|
</table>
|
||||||
</section2>
|
</section2>
|
||||||
|
@ -73,7 +73,7 @@
|
|||||||
</header>
|
</header>
|
||||||
|
|
||||||
<section1 topic='Introduction' anchor='intro'>
|
<section1 topic='Introduction' anchor='intro'>
|
||||||
<p>An XMPP client or other entity may need to discover services external to the XMPP network in order to complete certain XMPP-related use cases. One example is the discovery of STUN servers (see &rfc3489; and &rfc3489bis;) and STUN relays (see &turn;) for the sake of negotiating media exchanges via &xep0176;. <note>The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service for discovery of STUN servers, as documented at <<link url='http://code.google.com/apis/talk/jep_extensions/jingleinfo.html'>http://code.google.com/apis/talk/jep_extensions/jingleinfo.html</link>>, but has been broadened in scope to address additional use cases if desired.</note> An XMPP entity can already discover such external services in several ways, including:</p>
|
<p>An XMPP client or other entity may need to discover services external to the XMPP network in order to complete certain XMPP-related use cases. One example is the discovery of STUN servers (see &rfc5489;) and STUN relays (see &turn;) for the sake of negotiating media exchanges via &xep0176;. <note>The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service for discovery of STUN servers, as documented at <<link url='http://code.google.com/apis/talk/jep_extensions/jingleinfo.html'>http://code.google.com/apis/talk/jep_extensions/jingleinfo.html</link>>, but has been broadened in scope to address additional use cases if desired.</note> An XMPP entity can already discover such external services in several ways, including:</p>
|
||||||
<ol>
|
<ol>
|
||||||
<li>The service is specified in the application's default settings.</li>
|
<li>The service is specified in the application's default settings.</li>
|
||||||
<li>The service is manually added into the application's configuration by a human user.</li>
|
<li>The service is manually added into the application's configuration by a human user.</li>
|
||||||
|
1
xep.ent
1
xep.ent
@ -543,6 +543,7 @@ THE SOFTWARE.
|
|||||||
<!ENTITY rfc5054 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5054'>RFC 5054</link></span> <note>RFC 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication <<link url='http://tools.ietf.org/html/rfc5054'>http://tools.ietf.org/html/rfc5054</link>>.</note>" >
|
<!ENTITY rfc5054 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5054'>RFC 5054</link></span> <note>RFC 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication <<link url='http://tools.ietf.org/html/rfc5054'>http://tools.ietf.org/html/rfc5054</link>>.</note>" >
|
||||||
<!ENTITY rfc5081 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5081'>RFC 5081</link></span> <note>RFC 5081: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication <<link url='http://tools.ietf.org/html/rfc5081'>http://tools.ietf.org/html/rfc5081</link>>.</note>" >
|
<!ENTITY rfc5081 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5081'>RFC 5081</link></span> <note>RFC 5081: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication <<link url='http://tools.ietf.org/html/rfc5081'>http://tools.ietf.org/html/rfc5081</link>>.</note>" >
|
||||||
<!ENTITY rfc5122 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5122'>RFC 5122</link></span> <note>RFC 5122: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <<link url='http://tools.ietf.org/html/rfc5122'>http://tools.ietf.org/html/rfc5122</link>>.</note>" >
|
<!ENTITY rfc5122 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5122'>RFC 5122</link></span> <note>RFC 5122: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <<link url='http://tools.ietf.org/html/rfc5122'>http://tools.ietf.org/html/rfc5122</link>>.</note>" >
|
||||||
|
<!ENTITY rfc5489 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5489'>RFC 5489</link></span> <note>RFC 5489: Session Traversal Utilities for NAT (STUN) <<link url='http://tools.ietf.org/html/rfc5489'>http://tools.ietf.org/html/rfc5489</link>>.</note>" >
|
||||||
|
|
||||||
<!-- Internet-Drafts -->
|
<!-- Internet-Drafts -->
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user