<abstract>This document specifies methods for discovering STUN servers for use in negotiation of certain Jingle transport methods.</abstract>
&LEGALNOTICE;
<number>0215</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT YET ASSIGNED</shortname>
&stpeter;
&seanegan;
<revision>
<version>0.1</version>
<date>2007-05-16</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.5</version>
<date>2007-05-10</date>
<initials>psa</initials>
<remark><p>Added attributes for username and password; reverted to IQ method since credentials are individualized.</p></remark>
</revision>
<revision>
<version>0.0.4</version>
<date>2007-04-18</date>
<initials>psa</initials>
<remark><p>Modified to use a well-known publish-subscribe node instead of a dedicated IQ exchange.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2007-03-30</date>
<initials>psa</initials>
<remark><p>Made port mandatory since spec assumes that SRV is not available; added XML schema.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2007-03-27</date>
<initials>psa</initials>
<remark><p>Made port optional.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2007-03-23</date>
<initials>psa/se</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>The administrator of an XMPP server may wish to deploy one or more STUN servers (see &rfc3489; and &rfc3489bis;) in order to ease the process of negotiating media exchanges via &xep0176;. A client can become aware of a STUN server in the following ways:</p>
<p>Unfortunately, the foregoing methods are subject to human error or cannot be deployed in wide range of scenarios. Therefore, this document defines a way for an XMPP server to advertise a list of STUN servers and provide credentials for use by an XMPP client at a STUN server. This method should be used only as a fallback when DNS SRV lookups are not possible for the client or server.</p>
<p>Note: The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service and documented at <<linkurl='http://code.google.com/apis/talk/jep_extensions/jingleinfo.html'>http://code.google.com/apis/talk/jep_extensions/jingleinfo.html</link>>.</p>
</section1>
<section1topic='Protocol'anchor='protocol'>
<p>In order to learn about available STUN servers associated with or known by an XMPP server, a client sends an IQ-get containing a <stun/> element qualified by the "http://www.xmpp.org/extensions/xep-0215.html#ns" namespace &NSNOTE;.</p>
<examplecaption='Entity Requests STUN Server List from XMPP Server'><![CDATA[
<p>The XMPP server SHOULD return the list of STUN servers, but MAY instead return an appropriate error, such as &unavailable; if the server does not support the STUN Server Discovery protocol or &forbidden; if the requesting entity does not have permission to receive the list of STUN servers.</p>
<p>The syntax of the <server/> element is as follows:</p>
<ul>
<li>The <server/> element SHOULD be empty.</li>
<li>The 'host' attribute is REQUIRED and specifies either a fully qualified domain name (FQDN) or an IP address (IPv4 or IPv6).</li>
<li>The 'port' attribute is REQUIRED and specifies the communications port to be used at the host. <note>The port is necessary since this specification assumes that DNS SRV lookups are not possible.</note></li>
<li>The 'username' and 'password' attributes are OPTIONAL and are used as described below.</li>
</ul>
<p>A STUN server may require a username and password in order to accept STUN binding requests and/or STUN allocate requests. In this case, the XMPP server would typically generate a short-term authentication credential based on a private key shared with the STUN server. <note>Other implementations are possible, and long-term credentials could be used instead; see <cite>RFC 3489</cite> and <cite>rfc3489bis</cite> for details).</note></p>
<p>If an entity supports the STUN Server Discovery protocol, it MUST report that fact by including a service discovery feature of "http://www.xmpp.org/extensions/xep-0215.html#ns" &NSNOTE; in response to a &xep0030; information request:</p>
<examplecaption="Service Discovery Information Request"><![CDATA[
<p>Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0215.html#ns"; upon advancement of this specification, the ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>