<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 (&rfc6544;) instead of overloading the existing 'type' attribute, with values of "active", "passive", and "so".</li>
<li>Added support for ICE-TCP (&rfc6544;), 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 &rfc8445;. 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 &rfc8445;. There are several differences:</p>
<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 &rfc8445;.</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>
<p>The reader is referred to &rfc8445; and draft-ietf-ice-trickle for a description of various terms used in the context of ICE. Those terms are not reproduced here.</p>
<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 15 of &rfc8445;, 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 &rfc8445; and as shown in the examples.</p>
<p>'ice2' attribute tells about compliancy with &rfc8445;. If the attribute is not set or set to 'false' in &TRANSPORT; element, the recipient can assume &rfc5245;. The value of the attribute may not be changed during lifetime of the transport instance, but it's not an error to skip the attribute in consequent transport-info updates.</p>
<p>The attributes of the <transport/> element are as follows.</p>
<td>A Foundation as defined in &rfc8445;. (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>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>
<note>In accordance with the rules specified in Section 5.1.2 of &rfc8445;, 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", "110" for peer reflexive 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>A TCP candidate type as defined in &rfc6544;. The allowable values are "active" for TCP active candidates, "passive" for TCP passive candidates, and "so" for TCP simultaneous-open candidates.</td>
<td>An ICE candidate type as defined in &rfc8445;. 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 (&rfc6544;) are handled via the 'tcptype' attribute.</td>
<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"><