<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 &rfc5489;) from each local candidate it generated to each remote candidate it received.</li>
<li>Each party sends a STUN Binding Request (see &rfc5389;) 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>
<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 <<linkurl='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 &rfc5389;) 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 <<linkurl='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>
<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>
Peter Saint-Andre
15 years ago