<abstract>This specification defines a Jingle transport method that results in sending media data using datagram associations via the User Datagram Protocol (UDP) or using end-to-end connections via the Transport Control Protocol (TCP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology (which provides robust NAT traversal for media traffic) and also supports the ability to exchange candidates throughout the life of the session, consistent with so-called "Trickle ICE" (draft-ietf-ice-trickle).</abstract>
<li>Added a 'tcptype' attribute to support ICE-TCP (RFC 6544) instead of overloading the existing 'type' attribute, with values of "active", "passive", and "so".</li>
<li>Modified the syntax of the end-of-candidates indication so that it is wrapped in a <transport/> element in the same namespace.</li>
<li>Forked from XEP-0176 (see that specification for older revision history).</li>
<li>Added support for ICE-TCP (RFC 6544), specifically by allowing a value of "tcp" for the 'protocol' attribute and values of "tcp-active", "tcp-passive", and "tcp-so" for the 'type' attribute.</li>
<li>Changed title from ICE-UDP to ICE, but retained namespace name for backward compatibility.</li>
<li>Corrected data type of foundation attribute from xs:unsignedByte to xs:string.</li>
<li>Added a note about not mapping ice-options because it is not needed in XMPP.</li>
<li>Specified that the <transport/> element is extensible by adding xs:any to the schema.</li>
<li>Changed the normativity of the 'generation' attribute from required to optional because it is not absolutely necessary for ICE restarts.</li>
<li>Added informational message to indicate completion of sending ICE candidates (the "end-of-candidates indication") as in WebRTC and ORTC.</li>
<li>Verified compatibility with IETF "Trickle ICE" specification.</li>
</ul>
</remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>&xep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor application formats, leaving that up to separate specifications.</p>
<p>The current document defines a transport method for establishing and managing data exchanges between XMPP entities by means of the Interactive Connectivity Establishment (ICE) methodology specified in &rfc5245;. The Jingle usage of ICE was also the first technology to send ICE candidates incrementally, a technique that has since become known as "Trickle ICE" &trickle;.</p>
<p>The process for ICE negotiation is largely the same in Jingle as it is in RFC 5245. There are several differences:</p>
<ul>
<li>Instead of using the Session Initiation Protocol (SIP) as the signalling channel, Jingle uses XMPP as the signalling channel.</li>
<li>Syntax from the Session Description Protocol (see &rfc4566;) is mapped to an XML syntax suitable for sending over the XMPP signalling channel.</li>
<li>In Jingle, lists of "preferred" candidates are typically sent in the Jingle session-initiate and session-accept messages, in a way that is consistent with the SDP offer / answer model described in &rfc3264; and the process described in RFC 5245.</li>
<li>Candidates can also be sent in separate transport-info messages either before sending or receiving the session-accept message (to expedite negotiation) or after media begins to flow (to find modify existing candidates, find superior candidates, or adjust to changing network conditions). This usage, which has been part of the Jingle ICE transport method since 2005, has since come to be known as "Trickle ICE"; as defined here the usage is consistent with the IETF specification for Trickle ICE &trickle;.</li>
</ul>
<p>As originally defined in XEP-0166 and then &xep0176; the use of ICE in Jingle applied only to negotiations that established a User Datagram Protocol association (see &rfc0768;) and thus resulted in a Jingle datagram transport suitable for media applications where some packet loss is tolerable (e.g., audio and video). However, since the publication of &rfc6544; in 2012 it has also been possible to exchange Transmission Control Protocol (see &rfc0793;) candidates during ICE negotiation. Therefore this document expands the use of ICE in Jingle to also establish a TCP connection and thus result in a Jingle stream transport suitable for media applications where packet loss cannot be tolerated (e.g., file transfer). To reduce the possibility of confusion, the expanded definition provided here is specified in a new XEP, which is intended to supersede XEP-0176.</p>
</section1>
<section1topic='Glossary'anchor='terms'>
<p>The reader is referred to RFC 5245 and draft-ietf-ice-trickle for a description of various terms used in the context of ICE. Those terms are not reproduced here.</p>
</section1>
<section1topic='Requirements'anchor='reqs'>
<p>The Jingle transport method defined herein is designed to meet the following requirements:</p>
<ol>
<li>Make it possible to establish and manage out-of-band connections between two XMPP entities, even if they are behind Network Address Translators (NATs) or firewalls.</li>
<li>Enable use of UDP or TCP as the transport protocol.</li>
<li>Make it relatively easy to implement support in standard Jabber/XMPP clients.</li>
<li>Where communication with non-XMPP entities is needed, push as much complexity as possible onto server-side gateways between the XMPP network and the non-XMPP network.</li>
<p>In accordance with Section 10 of <cite>XEP-0166</cite>, this document specifies the following information related to the Jingle ICE transport method:</p>
<ol>
<li><p>The transport negotiation process is defined in the <linkurl='#protocol'>Protocol Description</link> section of this document.</p></li>
<li><p>The semantics of the &TRANSPORT; element are defined in the <linkurl='#protocol-negotiate'>ICE Negotiation</link> section of this document.</p></li>
<li><p>Depending on the kinds of candidates exchanged, successful negotiation of this method results in use of a datagram transport (suitable for applications where some packet loss is tolerable, such as audio and video) or of a streaming transport (suitable for applications where packet loss is not tolerable, such as file transfer).</p></li>
<li><p>If multiple components are to be communicated by the application type that uses the transport, the transport shall support those components and assign identifiers for them as described in the specification that defines the application type.</p></li>
<p>The overall protocol flow for negotiation of the Jingle ICE Transport Method is as follows (note: many of these events happen simultaneously, not in sequence).</p>
<p>Note: The examples in this document follow the scenario described in Section 17 of RFC 5245, except that we substitute the Shakespearean characters "Romeo" and "Juliet" for the generic entities "L" and "R".</p>
<p>In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in <cite>XEP-0166</cite>. If the initiator wishes to negotiate the ICE transport method for an application format, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:ice:0' namespace &VNOTE;. This element SHOULD in turn contain one &CANDIDATE; element for each of the initiator's higher-priority transport candidates as determined in accordance with the ICE methodology, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).</p>
<p>The &TRANSPORT; element's 'pwd' and 'ufrag' attributes MUST be included whenever sending one or more candidates to the other party, e.g., in a session-initiate, session-accept, transport-info, content-add, or transport-replace message. The values for these attributes are separately generated for both the initiator and the responder, in accordance with RFC 5245 and as shown in the examples. The attributes of the <transport/> element are as follows.</p>
<p>The attributes of the <candidate/> element are as follows.</p>
<tablecaption='Candidate Attributes'>
<tr>
<th>Name</th>
<th>Description</th>
<th>SDP Syntax</th>
<th>Example</th>
</tr>
<tr>
<td>component</td>
<td>A Component ID as defined in RFC 5245.</td>
<td>Component ID value in a=candidate line</td>
<td>1</td>
</tr>
<tr>
<td>foundation</td>
<td>A Foundation as defined in RFC 5245. (Note that version 1.0 of this specification container an error, whereby the data type for the Jingle 'foundation' attribute was defined as xs:unsignedByte; in version 1.1 this was corrected to xs:string, however some existing implementations might not use or expect strings.)</td>
<td>Foundation value in a=candidate line</td>
<td>2B78DADC1A9E</td>
</tr>
<tr>
<td>generation</td>
<td>An index, starting at 0, that enables the parties to keep track of updates to the candidate throughout the life of the session. For details, see the <linkurl='#protocol-restarts'>ICE Restarts</link> section of this document.</td>
<td>extended name/value pair in a=candidate line</td>
<td>0</td>
</tr>
<tr>
<td>id</td>
<td>A unique identifier for the candidate.</td>
<td>N/A</td>
<td>el0747fg11</td>
</tr>
<tr>
<td>ip</td>
<td>The Internet Protocol (IP) address for the candidate transport mechanism; this can be either an IPv4 address or an IPv6 address.</td>
<td>IP Address value in a=candidate line</td>
<td>192.0.2.3</td>
</tr>
<tr>
<td>network</td>
<td>An index, starting at 0, referencing which network this candidate is on for a given peer (used for diagnostic purposes if the calling hardware has more than one Network Interface Card).</td>
<td>N/A</td>
<td>0</td>
</tr>
<tr>
<td>port</td>
<td>The port at the candidate IP address.</td>
<td>Port value in a=candidate line</td>
<td>45664</td>
</tr>
<tr>
<td>priority</td>
<td>A Priority as defined in RFC 5245.
<note>In accordance with the rules specified in Section 4.1.1 of RFC 5245, the priority values shown in the examples within this document have been calculated as follows. The "type preference" for host candidates is stipulated to be "126" and for server reflexive candidates "100". The "local preference" for network 0 is stipulated to be "4096", for network 1 "2048", and for network 2 "1024".</note>
</td>
<td>Priority value in a=candidate line</td>
<td>2130706431</td>
</tr>
<tr>
<td>protocol</td>
<td>The protocol to be used. The values allowed by this specification are "udp" (see RFC 5245) and "tcp" (see RFC 6455).</td>
<td>Transport protocol field in a=candidate line</td>
<td>udp</td>
</tr>
<tr>
<td>rel-addr</td>
<td>A related address as defined in RFC 5245.</td>
<td>A TCP candidate type as defined in RFC 6455. The allowable values are "active" for TCP active candidates, "passive" for TCP passive candidates, and "so" for TCP simultaneous-open candidates.</td>
<td>Value of tcptype attribute in a=candidate line</td>
<td>An ICE candidate type as defined in RFC 5245. The allowable values are "host" for host candidates, "prflx" for peer reflexive candidates, "relay" for relayed candidates, and "srflx" for server reflexive candidates. Note that TCP candidate types (RFC 6455) are handled via the 'tcptype' attribute.</td>
<td>Value of typ attribute in a=candidate line</td>
<p>Note this specification does not provide an equivalent of the "ice-options" attribute defined in Section 15.5 of RFC 5245, since it is not needed in XMPP given the existence of the Service Discovery extension (XEP-0030).</p>
<p>As described in <cite>XEP-0166</cite>, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.</p>
<examplecaption="Responder acknowledges receipt of session-initiate request"><