&xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is video exchange. This document specifies a format for describing Jingle video sessions, where the media exchange occurs using the Real-time Transport Protocol (see &rfc3550;). Such sessions require the use of a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;.
+&xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is video exchange. This document specifies a format for describing Jingle video sessions, where the media exchange occurs using the Real-time Transport Protocol (see &rfc3550;).
The Jingle content description format defined herein is designed to meet the following requirements:
A Jingle video session is described by one or more encodings contained within a wrapper &DESCRIPTION; element. In the language of RFC 4566 these encodings are payload-types; therefore, each <payload-type/> child element specifies an encoding that can be used for the video stream. Such encodings are often used in the context of the Real-time Transfer Protocol (RTP; see RFC 3550) but may be used in other contexts as well. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The &PAYLOADTYPE; element's 'id' attribute is REQUIRED and its 'name' attribute is RECOMMENDED. The encodings SHOULD be provided in order of preference.
+A Jingle video session is described by one or more encodings contained within a wrapper &DESCRIPTION; element qualified by the 'http://www.xmpp.org/extensions/xep-0180.html#ns' namespace &NSNOTE;. In the language of RFC 4566 these encodings are payload-types; therefore, each <payload-type/> child element specifies an encoding that can be used for the video stream. Such encodings are often used in the context of the Real-time Transfer Protocol (RTP; see RFC 3550) but may be used in other contexts as well. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed in accordance with the dynamic assignment rules described in Section 3 of RFC 3551 (these "dynamic" types use payload IDs 96 to 127). The &PAYLOADTYPE; element's 'id' attribute is REQUIRED and its 'name' attribute is RECOMMENDED. The encodings SHOULD be provided in order of preference.
Each <payload-type/> element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rtptheora;, the "configuration", "configuration-uri", "delivery-method", and "sampling" parameters may be specified in relation to usage of the Theora
Each <payload-type/> element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rtptheora;, the "configuration", "configuration-uri", "delivery-method", and "sampling" parameters may be specified in relation to usage of the Theora
]]>
@@ -229,7 +229,7 @@
]]>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:
+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 ¬acceptable; error, which SHOULD include a Jingle-specific error condition of <unsupported-codecs/>:
After successful transport negotiation (not shown here), the receiver then accepts the session:
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.
+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/AVP"), and the <fmt list> is the payload-type ID.
For example, consider the following static payload-type:
That Jingle-formatted information would be mapped to SDP as follows:
That Jingle-formatted information would be mapped to SDP as follows:
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.
+As noted, if additional parameters are to be specified, they shall be represented as attributes of the <payload-type/> element or its child <parameter/> element, as in the following example.
That Jingle-formatted information would be mapped to SDP as follows:
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.
+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 &NSNOTE;.
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.
+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". No informational message payload elements have yet been defined, but they may be specified in a future version of this document.
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;.
+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-errors"; 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-rtp" in its registry of Jingle content description formats. The registry submission is as follows:
@@ -462,6 +465,27 @@ delivery-method=inline; configuration=somebase16string; + + ]]> +
+
+
+
+
+
+
+
+
]]>
The format for the XML DTMF representation is as follows &NSNOTE;:
The <dtmf/> element SHOULD possess one 'action' attribute, which MUST be either "button-up" or "button-down", specifying whether the button is being depressed or released. This allows DTMF tones to be reconstructed in real-time. If the 'action' attribute is not included, the recipient MUST assume this to be a "button-down" event, and imply a "button-up" event after a reasonable timeout (100 milliseconds is RECOMMENDED) or when another DMTF event is received.
+The <dtmf/> element SHOULD possess an 'action' attribute, the value of which MUST be either "button-up" or "button-down" (specifying whether the button is being depressed or released). This enables DTMF tones to be reconstructed in real time. If the 'action' attribute is not included, the recipient MUST assume that the action is a "button-down" event and act as if a "button-up" event occurs after a reasonable timeout (100 milliseconds is RECOMMENDED) or when another DMTF event is received.
Unless the 'action' attribute has a value of "button-up", the <dmtf/> element MUST possess a 'code' attribute that specifies the tone to be generated. The value of the 'code' attribute SHOULD be one the following characters: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, #, and * -- however, the characters A, B, C, and D MAY be sent as well.
The <dtmf> element SHOULD be sent as the payload of a Jingle session-info message as illustrated in the following example &NSNOTE;.
If the receiving entity does not understand or cannot process the payload, it MUST return an error &feature; with a Jingle-specific error condition of <unsupported-info/>.
+If the receiving entity does not understand or cannot process the payload, it MUST return a &feature; stanza error, which SHOULD include a Jingle-specific error condition of <unsupported-info/>.
If the recipient does not support the requested DTMF method, it MUST return an error of a <feature-not-implemented/> error with a DTMF-specific error condition of <unsupported-dtmf-method/>:
+If the recipient does not support the requested DTMF method, it MUST return a <feature-not-implemented/> stanza error, which SHOULD include a DTMF-specific error condition of <unsupported-dtmf-method/>:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -217,6 +234,28 @@
- ]]>
+ ]]>
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+ &xep0166; defines a framework for negotiating and managing out-of-band data exchange sessions over XMPP. Unfortunately, most developers of XMPP clients have limited experience with multimedia applications such as voice and video, making it difficult to get started with implementation of Jingle technologies. Therefore this document provides a simple transport and session type that client developers can use to bootstrap Jingle implementations.
-Note: The methods specified herein are provided for experimentation and unit testing only and are not intended for inclusion in released software or production environments.
+&xep0166; defines a framework for using XMPP to negotiate and manage out-of-band media sessions. Unfortunately, most developers of XMPP clients have limited experience with multimedia applications such as voice and video, making it difficult to get started with implementation of Jingle technologies. Therefore this document provides a simple transport and session type that client developers can use to bootstrap Jingle implementations.
+Note: The methods specified herein are provided for experimentation and unit testing only. They are not intended for inclusion in released software or production environments.
The intent of this simple Jingle profile is to enable exchange of data using the Echo Protocol specified in &rfc0862;, but using a port other than 7 -- the default port for this usage is 17777. The protocol flow is as follows. (The following examples use &xep0177; as the transport protocol; although it is possible to complete echo protocol exchanges via TCP, that is deemed less useful and there is no Jingle transport for direct TCP exchanges.)
+The intent of this simple Jingle profile is to enable exchange of data using the Echo Protocol specified in &rfc0862;, but using a port other than 7 (the default port for this experimental usage is 17777). The protocol flow is as follows. (The following examples use &xep0177; as the transport protocol; although it is possible to complete echo protocol exchanges via TCP, that is deemed less useful and there is no Jingle transport for direct TCP exchanges.)
Note: The port SHOULD be 17777.
The parties may now exchange data using the echo protocol in order to test the connection.
-Note: Protocol flows for additional use cases (e.g., renegotiation) will be added to future versions of this specification.
+Note: Protocol flows for additional use cases (e.g., renegotiation) may be added to future versions of this specification.
The administrator of an XMPP server may wish to deploy one or more STUN servers (see &rfc3489; and &rfc3489bis;) in order to ease the process of negotiating media exchanges via &xep0176;. A client can become aware of a STUN server in the following ways:
Unfortunately, the foregoing methods are subject to human error or cannot be deployed in wide range of scenarios. Therefore, this document defines a way for an XMPP server to advertise a list of STUN servers and provide credentials for use by an XMPP client at a STUN server. This method SHOULD be used only as a fallback when DNS SRV lookups are not possible for the client or server.
+Unfortunately, the foregoing methods are subject to human error or cannot be deployed in wide range of scenarios. Therefore, this document defines a way for an XMPP server to advertise a list of STUN servers and provide credentials for use by an XMPP client at a STUN server. This method should be used only as a fallback when DNS SRV lookups are not possible for the client or server.
Note: The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service and documented at <http://code.google.com/apis/talk/jep_extensions/jingleinfo.html>.
In order to learn about available STUN servers associated with or known by an XMPP server, a client sends an IQ-get containing a <stun/> element qualified by the "http://www.xmpp.org/extensions/xep-0215.html#ns" namespace &NSNOTE;.
-An example of the payload format for this node is as follows:
The XMPP server SHOULD return the list of STUN servers, but MAY instead return an appropriate error, such as &unavailable; if the server does not support the STUN Server Discovery protocol or &forbidden; if the requesting entity does not have permission to receive the list of STUN servers.
(Naturally, the XMPP MAY instead return an appropriate error, such as &unavailable; if the server does not support the STUN Server Discovery protocol or &forbidden; if the requesting entity does not have permission to receive the server list.)
-The 'host' attribute is REQUIRED and specifies either a fully qualified domain name (FQDN) or an IP address (IPv4 or IPv6). The 'port' attribute is REQUIRED and specifies the communications port to be used at the host.
A STUN server may require a username and password in order to accept STUN binding requests and/or STUN allocate requests. In this case, the XMPP server would typically generate a short-term authentication credential based on a private key shared with the STUN server (naturally, other implementations are possible, and long-term credentials could be used instead; see RFC 3489 and rfc3489bis for details).
+The syntax of the <server/> element is as follows:
+A STUN server may require a username and password in order to accept STUN binding requests and/or STUN allocate requests. In this case, the XMPP server would typically generate a short-term authentication credential based on a private key shared with the STUN server.
The 'username' and 'password' attributes are OPTIONAL.
An XMPP server MAY send an updated list of STUN servers by "pushing" the list to a client that has previously requested the list: