The transport-info action is used to exchange transport candidates; it is mainly used in XEP-0176 but might be used in other transport specifications.
The transport-replace action is used to redefine a transport method.
+The transport-replace action is used to redefine a transport method, typically for fallback to a different method (e.g., changing from ICE-UDP to Raw UDP for a datagram transport, or changing from &xep0065; to &xep0047; for a streaming transport).
It is possible that two instances of certain actions can be sent at the same time in the context of an existing session, one by each party; for example, both parties might simulaneously attempt to send a content-add, content-modify, or content-remove action. In all such cases, the action sent by the initiator MUST overrule the action sent by the responder; i.e., both parties MUST accept the action sent by the initiator and the initiator MUST return an &unexpected; error to the responder for the duplicate action.
@@ -1097,8 +1097,8 @@ PENDING o----------------------+ |Specified Jingle conformance, including the preference for lossy transports over reliable transports and the process of sending and receiving audio content over each transport type.
Specified Jingle conformance, including the preference for datagram transports over streaming transports and the process of sending and receiving audio content over each transport type.
The application format negotiation process is defined in the Negotiating a Jingle RTP Session section of this document.
The semantics of the &DESCRIPTION; element are defined in the Application Format section of this document.
A mapping of Jingle semantics to the Session Description Protocol is provided in the Mapping to Session Description Protocol section of this document.
A Jingle RTP session SHOULD use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;, but MAY use a reliable transport such as "ice-tcp" if a low-bandwidth codec is employed and the media negotiated is not unduly heavy (e.g., it might be possible to use a reliable transport for audio, but not for video).
A Jingle RTP session SHOULD use a datagram transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;, but MAY use a streaming transport such as "ice-tcp" if a low-bandwidth codec is employed and the media negotiated is not unduly heavy (e.g., it might be possible to use a streaming transport for audio, but not for video).
Content is to be sent and received as follows:
For lossy transports, outbound content shall be encoded into RTP packets and each packet shall be sent individually over the transport. Each inbound packet received over the transport is an RTP packet.
For reliable transports, outbound content shall be encoded into RTP packets and each packet data shall be sent in succession over the transport. Incoming data received over the transport shall be processed as a stream of RTP packets, where each RTP packet boundary marks the location of the next packet.
For datagram transports, outbound content shall be encoded into RTP packets and each packet shall be sent individually over the transport. Each inbound packet received over the transport is an RTP packet.
For streaming transports, outbound content shall be encoded into RTP packets and each packet data shall be sent in succession over the transport. Incoming data received over the transport shall be processed as a stream of RTP packets, where each RTP packet boundary marks the location of the next packet.
Specified Jingle conformance, including definition of transport type as lossy; added section on service discovery.
Specified Jingle conformance, including definition of transport type as datagram; added section on service discovery.
&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 between XMPP entities using a raw User Datagram Protocol (UDP) "connection" (see &rfc0768;). This "raw-udp" method results in a lossy transport method suitable for use in media applications where some packet loss is tolerable (e.g., audio and video).
+&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 between XMPP entities using a raw User Datagram Protocol (UDP) "connection" (see &rfc0768;). This "raw-udp" method results in a datagram transport method suitable for use in media applications where some packet loss is tolerable (e.g., audio and video).
Note: The Raw UDP transport does not provide end-to-end traversal of Network Address Translators (NATs); if NAT traversal is needed, Jingle clients SHOULD use &ice; as described in &xep0176;. The Raw UDP transport method is defined only for the purpose of specifying the IP address and port that an entity considers "most likely to succeed" and is a "hit-or-miss" method that might work end-to-end in some circumstances. However, this method can prove useful when the communications architecture includes intermediate gateways or relays, as described in XEP-0176.
The transport negotiation process is defined in the Protocol Description section of this document.
The semantics of the &TRANSPORT; element are defined in the Transport Initiation section of this document.
Successful negotiation of the Raw 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 Raw 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, the first component shall be associated with the port in the transport initiation stanza and the second component (e.g., for RTCP) shall be associated with a UDP port that is one number higher than the specified port (e.g., if the specified port is 13540 then the port for the second component shall be 13541).