<remark><p>Corrected fallback scenario to use transport-replace and transport-accept.</p></remark>
</revision>
<revision>
<version>0.21</version>
<date>2008-09-25</date>
@ -115,7 +121,7 @@
<version>0.8</version>
<date>2007-04-17</date>
<initials>psa</initials>
<remark><p>Separately defined ice-tcp and ice-udp transport methods to enable clearer definition of transport methods and reuse by application types; specified Jingle conformance, including definition of ice-udp as lossy and ice-tcp as reliable.</p></remark>
<remark><p>Separately defined ice-tcp and ice-udp transport methods to enable clearer definition of transport methods and reuse by application types; specified Jingle conformance, including definition of ice-udp as datagram and ice-tcp as streaming.</p></remark>
</revision>
<revision>
<version>0.7</version>
@ -162,7 +168,7 @@
</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 over the User Datagram Protocol (see &rfc0768;), using the ICE methodology developed within the IETF and specified in &ice; (hereafter referred to as &icecore;). Use of the <strong>ice-udp</strong> method results in a lossy transport suitable for media applications where some packet loss is tolerable (e.g., audio and video).</p>
<p>The current document defines a transport method for establishing and managing data exchanges between XMPP entities over the User Datagram Protocol (see &rfc0768;), using the ICE methodology developed within the IETF and specified in &ice; (hereafter referred to as &icecore;). Use of the <strong>ice-udp</strong> method results in a datagram transport suitable for media applications where some packet loss is tolerable (e.g., audio and video).</p>
<p>Note: &icecore; has been approved for publication as an RFC but has not yet been published as an RFC. While every effort has been made to keep this document synchronized with &icecore;, the interested reader is referred to &icecore; for a detailed description of the ICE methodology.</p>
<p>The process for ICE negotiation is largely the same in Jingle as it is in ICE. There are several differences:</p>
<ul>
@ -190,7 +196,7 @@
<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>Successful negotiation of the ice-udp method results in use of a lossy transport that is suitable for applications where some packet loss is tolerable, such as audio and video.</p></li>
<li><p>Successful negotiation of the ice-udp method results in use of a datagram transport that is suitable for applications where some packet loss is tolerable, such as audio and video.</p></li>
<li><p>If multiple components are to be communicated over the transport in the context of the Real-time Transport Protocol (RTP; see &rfc3550;), the component numbered "1" shall be associated with RTP and the component numbered "2" shall be associated with the Real Time Control Protocol (RTCP).</p></li>
</ol>
</section1>
@ -856,12 +862,12 @@ Romeo Gateway Juliet
|------------------------>| |
| ack | |
|<------------------------||
| content-add | |
| transport-replace | |
| (Raw UDP) | |
|<------------------------||
| ack | |
|------------------------>| |
| content-accept | |
| transport-accept | |
|------------------------>| |
| ack | |
|<------------------------|SIPINVITE|
@ -912,20 +918,17 @@ Romeo Gateway Juliet
to='romeo@montague.lit/orchard'
type='result'/>
]]></example>
<p>Immediately the gateway sends a content-add action to Romeo, specifying a transport of Raw UDP with a candidate whose IP address and port identify a media relay at the gateway.</p>
<examplecaption="Gateway sends content-add on behalf of responder"><![CDATA[
<p>Immediately the gateway sends a transport-replace action to Romeo, specifying a transport of Raw UDP with a candidate whose IP address and port identify a media relay at the gateway.</p>
<examplecaption="Gateway sends transport-replace on behalf of responder"><![CDATA[