Corrected fallback scenario to use transport-replace and transport-accept.
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.
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.
&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.
-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 ice-udp method results in a lossy transport suitable for media applications where some packet loss is tolerable (e.g., audio and video).
+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 ice-udp method results in a datagram transport suitable for media applications where some packet loss is tolerable (e.g., audio and video).
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.
The process for ICE negotiation is largely the same in Jingle as it is in ICE. There are several differences:
The transport negotiation process is defined in the Protocol Description section of this document.
The semantics of the &TRANSPORT; element are defined in the ICE Negotiation section of this document.
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.
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.
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).
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.
-Romeo then acknowledges the content-add action and immediately also sends a content-accept.
-The gateway then acknowledges the acceptance on behalf of Juliet.
-Now the gateway removes the old content definition based on the ICE-UDP transport.
-Romeo then acknowledges the content-replace action.
-Eventually, the responder sends a session-accept.
+Eventually, the responder sends a session-accept through the gateway.