Updated to reflect changes to XEP-0166; clarified media data checking.
Note: The Raw UDP transport does not provide traversal of Network Address Translators (NATs) and is provided only for the purpose of specifying the IP address and port that an entity considers most likely to succeed without the need for NAT traversal. If NAT traversal is needed, &xep0176; SHOULD be used.
+Note: The Raw UDP transport does not provide traversal of Network Address Translators (NATs) and is provided only for the purpose of specifying the IP address and port that an entity considers most likely to succeed without the need for NAT traversal.
In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one content type. If the initiating entity wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'http://www.xmpp.org/extensions/xep-0177.html#ns' namespace (see Protocol Namespaces), which MUST
In order for the initiator in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one content type. If the initiator wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'http://www.xmpp.org/extensions/xep-0177.html#ns' namespace (see Protocol Namespaces), which MUST
As described in XEP-0166, to provisionally accept the session initiation request, the receiver returns an IQ-result:
-Once the receiving entity provisionally accepts the session, it:
+Once the responder provisionally accepts the session, it:
These are done simultaneously in order to ensure that a connection can be made, since the initiating entity's Raw UDP candidate may not result in success.
-The receiving entity MUST immediately attempt to send media data to the IP and port specified in the initiation request. If media data can be delivered, the recipient MUST send a Jingle "transport-accept" action to the initiator (either explicitly, or implicitly via a "content-accept" or "session-accept" action.
-The responder MUST immediately attempt to send data to the IP and port specified in the initiation request. Because delivery of UDP data is not necessarily acknowledged, the data can be sent using &rfc0862;; if the data is echoed back, the recipient would then send a Jingle "content-accept" (or "session-accept") action to the initiator.
+The initiating entity MUST then acknowledge acceptance by returning an IQ result (or return a standard XMPP error).
-While checking the initiating entity's Raw UDP candidate, the receiving entity SHOULD its own Raw UDP candidate to the initiating entity by sending a transport-info message to the initiating entity, as shown in the following example.
-The initiating entity MUST then acknowledge receipt by returning an IQ result (or return a standard XMPP error).
-Naturally, the intiating entity then MUST also check the receiving entity's Raw UDP candidate by following the checking procedure outlined above.
+Naturally, the initiator then MUST also check the responder's Raw UDP candidate by following the checking procedure outlined above.
While checking the initiating entity's Raw UDP candidate, the receiving entity MAY send an informational message to communicate the status of transport checking. The informational message MUST be an IQ-set containing a &JINGLE; element of type "transport-info", where the informational message is a payload element specified in the Informational Messages section of this document.
+While checking the initiator's Raw UDP candidate, the responder MAY send an informational message to communicate the status of transport checking. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info", where the informational message is a payload element specified in the Informational Messages section of this document.
Informational messages MAY be sent by the receiver within the context of the Raw UDP transport to communicate the status of transport checking. The informational message MUST be an IQ-set containing a &JINGLE; element of type "transport-info", where the informational message is a payload element qualified by the 'http://www.xmpp.org/extensions/xep-0177.html#ns-info' namespace (see Protocol Namespaces). The following payload elements are defined:
+Informational messages MAY be sent by the receiver within the context of the Raw UDP transport to communicate the status of transport checking. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info", where the informational message is a payload element qualified by the 'http://www.xmpp.org/extensions/xep-0177.html#ns-info' namespace (see Protocol Namespaces). The following payload elements are defined:
| Element | @@ -187,8 +193,7 @@
|---|
To follow.
+ +When the initiator sends a session-initiate stanza to the receiver, the &DESCRIPTION; element includes all of the payload types that the initiator can receive for Jingle video (each one encapsulated in a separate &PAYLOADTYPE; element):
+Upon receiving the session-initiate stanza, the receiver determines whether it can provisionally accept the session and proceed with the negotiation. The general Jingle error cases are specified in XEP-0166. In addition, the receiver must determine if it supports any of the payload types advertised by the initiator; if it does not, it MUST reject the session by sending a <unsupported-codecs/> error:
+If there is no error, the receiver provisionally accepts the session:
+The receiver then should send a list of the payload types that it can receive via a Jingle "content-accept" (or "session-accept") action. The list that the receiver sends MAY include any payload types (not a subset of the payload types sent by the initiator) but SHOULD retain the ID numbers and order specified by the initiator.
+The initiator acknowledges the 'content-accept' with an empty IQ result:
+After successful transport negotiation (not shown here), the receiver then accepts the session:
+And the initiator acknowledges session acceptance:
+If an entity supports the Jingle video content description format, it MUST advertise that fact by returning a feature of "http://www.xmpp.org/extensions/xep-0166.html#ns/description/video" in response to &xep0030; information requests.
+ +If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in RFC 4566. The generic format for the media field is as follows:
+
+ ]]>
+ In the context of Jingle video sessions, the <media> is "video", the <port> is the preferred port for such communications (which may be determined dynamically), the <transport> is whatever transport method is negotiated via the Jingle negotiation (e.g., "RTP/AVT"), and the <fmt list> is the payload-type ID.
+For example, consider the following static payload-type:
+If the payload type is dynamic (payload-type IDs 96 through 127 inclusive), it SHOULD be mapped to an SDP media field plus an SDP attribute field named "rtpmap".
+For example, consider a VC-1 payload such as that described in &rfc4425;:
+As noted, if additional parameters are to be specified, they shall be represented as attributes of the <payload-type/> element of the child <parameter/> element, as in the following example.
+If an entity supports Jingle video exchanges via RTP, it MUST advertise that fact by returning a feature of "http://www.xmpp.org/extensions/xep-0180.html#ns" in response to &xep0030; information requests.
Informational messages may be sent by either party within the context of Jingle to communicate the status of a Jingle video session, device, or principal. The informational message MUST be an IQ-set containing a &JINGLE; element of type "content-info", where the informational message is a payload element qualified by the 'http://www.xmpp.org/extensions/xep-0166.html#ns/info/video' namespace. No payload elements have yet been defined, but will be specified in a future version of this document.
+Informational messages may be sent by either party within the context of Jingle to communicate the status of a Jingle video session, device, or principal. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info", where the informational message is a payload element qualified by the 'http://www.xmpp.org/extensions/xep-0180.html#ns-info' namespace. No payload elements have yet been defined, but may be specified in a future version of this document.
Support for the Theora codec
The description of a format for video sessions introduces no known security vulnerabilities.
+In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged; for example, in the case of UDP, that would include Datagram Transport Layer Security (DTLS) as specified in &rfc4347;. &sdpdtls; defines such methods for the Session Description Protocol; the relevant RTP profile (e.g., "UDP/TLS/RTP/AVP" for transporting the RTP stream over DTLS with UDP) shall be specified as the value of the &CONTENT; element's 'profile' attribute.
This document requires no interaction with &IANA;.
Until this specification advances to a status of Draft, its associated namespaces shall be "http://www.xmpp.org/extensions/xep-0180.html#ns" and "http://www.xmpp.org/extensions/xep-0180.html#ns-info"; upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.
The XMPP Registrar shall include "video" in its registry of Jingle content description formats. The registry submission is as follows:
+The XMPP Registrar shall include "video-rtp" in its registry of Jingle content description formats. The registry submission is as follows:
- video
- Jingle sessions that support video exchanges
+ video-rtp
+ Jingle sessions that support video exchange via the Real-time Transport Protocol
XEP-0180
]]>