From 1922ba534dd3bdc61da78aedbcefb4e6ce833d4a Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 23 Mar 2007 22:08:23 +0000 Subject: [PATCH] 0.5 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@690 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0177.xml | 57 +++++++++------- xep-0180.xml | 186 +++++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 197 insertions(+), 46 deletions(-) diff --git a/xep-0177.xml b/xep-0177.xml index bf2f111d..abc34f0b 100644 --- a/xep-0177.xml +++ b/xep-0177.xml @@ -26,6 +26,12 @@ &scottlu; &hildjj; &seanegan; + + 0.5 + 2007-03-23 + psa +

Updated to reflect changes to XEP-0166; clarified media data checking.

 + 0.4 2006-12-21 @@ -61,18 +67,18 @@
  • Make it relatively easy to implement support in standard Jabber/XMPP clients.
  • Where communication with non-XMPP entities is needed, push as much complexity as possible onto server-side gateways between the XMPP network and the non-XMPP network.
    • -

    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. This is also helpful for bootstrapping of Jingle implementation by developers working on a local network. If NAT traversal is needed, &xep0176; SHOULD be used.

    -

    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 This is required to avoid a round trip and help expedite the negotiation. include the initiating entity's Raw UDP candidate via the 'ip', 'port', 'generation', and 'name' attributes of the &CANDIDATE; element.

    +

    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 This is required to avoid a round trip and help expedite the negotiation. include the initiator's Raw UDP candidate via the 'ip', 'port', 'generation', and 'name' attributes of the &CANDIDATE; element.

    - + @@ -102,27 +108,27 @@     - +

    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:

      -
    • MUST check the initiating entity's Raw UDP candidate by attempting to send media data to the specified IP and port.
      • -
    • SHOULD send its own Raw UDP candidate to the initiating entity via a Jingle "transport-info" message.
      • +
    • MUST check the initiator's Raw UDP candidate by attempting to send data via UDP to the specified IP and port (see next section).
      • +
    • SHOULD send its own Raw UDP candidate to the initiator via a Jingle "transport-info" message.
    • MAY send an informational message.
    -

    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.

    - These are done simultaneously in order to ensure that a connection can be made, since the initiator's Raw UDP candidate may not result in success.

    + +

    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.

    + - + @@ -130,20 +136,20 @@ ]]> -

    The initiating entity MUST then acknowledge acceptance by returning an IQ result (or return a standard XMPP error).

    - The initiator MUST then acknowledge acceptance by returning an IQ result (or 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.

    - While checking the initiator's Raw UDP candidate, the responder SHOULD send its own Raw UDP candidate to the initiator by sending a transport-info message to the initiator, as shown in the following example.

    + - + @@ -151,19 +157,19 @@ ]]> -

    The initiating entity MUST then acknowledge receipt by returning an IQ result (or return a standard XMPP error).

    - The initiator MUST then acknowledge receipt by returning an IQ result (or 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:

    @@ -187,8 +193,7 @@ - -

    In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method; in the case of UDP, that would include Datagram Transport Layer Security (DTLS) as specified in &rfc4347;.

    +

    In order to secure the data stream that is negotiated via the Jingle ICE transport, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged (for details regarding audio and video exchanges via RTP, refer to XEP-0167 and XEP-0180).

         diff --git a/xep-0180.xml b/xep-0180.xml index aff27a7b..bedc08cc 100644 --- a/xep-0180.xml +++ b/xep-0180.xml @@ -6,8 +6,8 @@
    - Jingle Video Content Description Format - This document defines a content description format for Jingle video sessions. + Jingle Video via RTP + This document defines methods for negotiating Jingle video sessions that use the Real-time Transport Protocol (RTP) for media exchange. &LEGALNOTICE; 0180 Experimental @@ -27,6 +27,12 @@ Chen Milton.Chen@vseelab.com + + 0.5 + 2007-03-23 + psa +

    Added negotiation flow and SDP mapping; renamed to mention RTP as the associated transport; corrected negotiation flow to be consistent with SIP/SDP (each party specifies a list of the payload types it can receive); added profile attribute to content element in order to specify RTP profile in use.

     +     0.4 2006-12-21 @@ -59,23 +65,25 @@
    -

    &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.

    +

    &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:

    1. Enable negotiation of parameters necessary for video exchange.
    2. Map these parameters to Session Description Protocol (SDP; see &rfc4566;) to enable interoperability.
      3. -
    3. Define informational messages related to video exchange chat.
      4. +
    4. Define informational messages related to video chat.
     + -

    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 &rfc3550;) 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 96), although other encodings are allowed (these "dynamic" types use payload IDs 97 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. 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.

    + - - + + ]]> @@ -134,11 +142,143 @@
    Element
    - -

    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):

    + + + action='session-initiate' + initiator='romeo@montague.net/orchard' + sid='v1d30k1ll3dth3r4d10st4r'> + + + + + + + + + + + + ]]> +

    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.

    + + + action='content-accept' + initiator='romeo@montague.net/orchard' + sid='v1d30k1ll3dth3r4d10st4r'> + + + + + + + + + + + + + + + ]]> +

    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 See <http://www.theora.org/>. is RECOMMENDED.

         + -

    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 ]]>     +