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:

1. The server is specified in the default settings for the client.
2. The server is manually added by a human user into the client's configuration.
3. The server is discovered via DNS SRV records as specified in Section 9.1 of RFC 3489.

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.

Note: The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service and documented at <http://code.google.com/apis/talk/jep_extensions/jingleinfo.html>.

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;.

An example of the payload format for this node is as follows:

(Naturally, the XMPP 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 server list.)

The 'host' attribute is REQUIRED and specifies either a fully qualified domain name (FQDN) or an IP address (IPv4 or IPv6). The 'port' attribute is REQUIRED and specifies the communications port to be used at the host. The port is necessary since this specification assumes that DNS SRV lookups are not possible.

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 (naturally, other implementations are possible, and long-term credentials could be used instead; see RFC 3489 and rfc3489bis for details).

The 'username' and 'password' attributes are OPTIONAL.

An XMPP server MAY send an updated list of STUN servers by "pushing" the list to a client that has previously requested the list:

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: