moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

RFC 5489

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2439 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-10-27 16:22:42 +00:00
parent 45669acfa1
commit d431c15912
4 changed files with 4 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0176.xml
View File

@ -522,7 +522,7 @@ INITIATOR RESPONDER
<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>
<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>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>

2
xep-0177.xml
View File

@ -199,7 +199,7 @@ INITIATOR RESPONDER
</tr>
<tr>
<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>
</table>
</section2>

2
xep-0215.xml
View File

@ -73,7 +73,7 @@
</header>
<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 &lt;<link url='http://code.google.com/apis/talk/jep_extensions/jingleinfo.html'>http://code.google.com/apis/talk/jep_extensions/jingleinfo.html</link>&gt;, 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 &lt;<link url='http://code.google.com/apis/talk/jep_extensions/jingleinfo.html'>http://code.google.com/apis/talk/jep_extensions/jingleinfo.html</link>&gt;, 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>
<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>

1
xep.ent
View File

@ -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 &lt;<link url='http://tools.ietf.org/html/rfc5054'>http://tools.ietf.org/html/rfc5054</link>&gt;.</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 &lt;<link url='http://tools.ietf.org/html/rfc5081'>http://tools.ietf.org/html/rfc5081</link>&gt;.</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) &lt;<link url='http://tools.ietf.org/html/rfc5122'>http://tools.ietf.org/html/rfc5122</link>&gt;.</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) &lt;<link url='http://tools.ietf.org/html/rfc5489'>http://tools.ietf.org/html/rfc5489</link>&gt;.</note>" >
<!-- Internet-Drafts -->