From 546f040c3d13e66765773d164cee7adbee8a1929 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 2 Dec 2009 19:49:46 +0000 Subject: [PATCH] 1.1rc4 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3665 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0167.xml | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/xep-0167.xml b/xep-0167.xml index eb095e04..e3278ff8 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -19,6 +19,8 @@ XMPP Core XEP-0166 RFC 3550 + RFC 3551 + RFC 3711 @@ -42,10 +44,10 @@ &robmcqueen; &diana; - 1.1rc3 + 1.1rc4 in progress, last updated 2009-12-02 psa -

Added creator attribute to mute and unmute elements so that these events can be correlated with a particular content type; clarified use of the reason element in cases other than termination; defined handling of content-add when none of the offered payload-types are supported, where the signalling uses a content-reject message with a Jingle reason of <failed-application/> and a list of the supported codecs; clarified that the SDP transport is RTP/AVP by default, that the transport is RTP/SAVP if security preconditions are present, and that additional transports such as RTP/AVPF and RTP/SAVPF might be supported in a future version of this specification.

 +

Added creator attribute to mute and unmute elements so that these events can be correlated with a particular content type; clarified use of the reason element in cases other than termination; defined handling of content-add when none of the offered payload-types are supported, where the signalling uses a content-reject message with a Jingle reason of <failed-application/> and a list of the supported codecs; clarified that the RTP profile is RTP/AVP by default, that the profile is RTP/SAVP if security preconditions are present, and that additional profiles such as RTP/AVPF and RTP/SAVPF might be supported in a future version of this specification.

 1.0 @@ -309,6 +311,12 @@

A Jingle RTP session is described by a content type that contains one application format and one transport method. Each <content/> element defines a single RTP session. A Jingle negotiation MAY result in the establishment of multiple RTP sessions (e.g., one for audio and one for video). An application SHOULD consider all of the RTP sessions that are established via the same Jingle negotiation to be synchronized for purposes of streaming, playback, recording, etc.

+

RTP as defined in RFC 3550 is used in the context of various "profiles" that are defined by other specifications. Jingle RTP treats RTP profiles as follows:

+
    +
  1. By default the RTP profile in Jingle RTP MUST be considered "RTP/AVP" as defined in &rfc3551;.
    2. +
  2. If the session initiation request contains an <encryption/> element to specify use of SRTP as described under Negotiation of SRTP, then the RTP profile MUST instead be considered "RTP/SAVP" as defined in &rfc3711;.
    3. +
  3. Future versions of this specification might define how to use other RTP profiles, such as "RTP/AVPF" and "RTP/SAVPF" as defined in &rfc4585; and &rfc5124; respectively.
    4. +

The application format consists of one or more encodings contained within a wrapper <description/> element qualified by the 'urn:xmpp:jingle:apps:rtp:1' namespace &VNOTE;. In the language of RFC 4566 each encoding is a payload-type; therefore, each <payload-type/> element specifies an encoding that can be used for the RTP stream, as illustrated in the following example.

@@ -374,7 +382,7 @@ OPTIONAL -

In Jingle RTP, the encodings are used in the context of RTP. 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 payload IDs are represented in the 'id' attribute.

+

In Jingle RTP, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in RFC 3551 (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 payload IDs are represented in the 'id' attribute.

Each <payload-type/> element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rfc5574;, the "cng", "mode", and "vbr" parameters can be specified in relation to usage of the Speex See <http://www.speex.org/>. codec. Where such parameters are encoded via the "fmtp" SDP attribute, they shall be represented in Jingle via the following format:

@@ -519,8 +527,7 @@ Initiator Responder ]]> -

The SDP <media> parameter is "audio" or "video" or some other media type as specified by the Jingle 'media' attribute, the <port> parameter is the preferred port for such communications (which might be determined dynamically), and the <fmt list> parameter is the payload-type ID.

-

By default the SDP <transport> MUST be considered "RTP/AVP" as defined in RFC 3550. If the initiation request contains a <security/> element to specify security preconditions for the session, then the SDP <transport> MUST instead be considered "RTP/SAVP" as defined in RFC 3711. Future versions of this specification might define how to use other SDP transports, such as "RTP/AVPF" and "RTP/SAVPF" as defined in &rfc4585; and &rfc5124; respectively.

+

The SDP <media> parameter is "audio" or "video" or some other media type as specified by the Jingle 'media' attribute, the <port> parameter is the preferred port for such communications (which might be determined dynamically), the <transport> parameter shall correspond to the RTP profile as described under Application Format, and the <fmt list> parameter is the payload-type ID.

For example, consider the following static payload-type: