draft-ietf-mmusic-sdp-media-capabilities-05.txt   draft-ietf-mmusic-sdp-media-capabilities-06.txt 
MMUSIC R. Gilman MMUSIC R. Gilman
Internet-Draft NDCI Internet-Draft NDCI
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: January 15, 2009 Polycom Expires: July 13, 2009 Gesher Erove Ltd
F. Andreasen F. Andreasen
Cisco Systems Cisco Systems
July 14, 2008 January 9, 2009
SDP media capabilities Negotiation SDP media capabilities Negotiation
draft-ietf-mmusic-sdp-media-capabilities-05.txt draft-ietf-mmusic-sdp-media-capabilities-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on July 13, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
Session Description Protocol (SDP) capability negotiation provides a Session Description Protocol (SDP) capability negotiation provides a
general framework for indicating and negotiating capabilities in SDP. general framework for indicating and negotiating capabilities in SDP.
The base framework defines only capabilities for negotiating The base framework defines only capabilities for negotiating
transport protocols and attributes. In this document, we extend the transport protocols and attributes. In this document, we extend the
framework by defining media capabilities that can be used to framework by defining media capabilities that can be used to
negotiate media types and their associated parameters. This negotiate media types and their associated parameters. This
extension is designed to map easily to existing and future SDP media extension is designed to map easily to existing and future SDP media
attributes. attributes, but not encodings or formatting.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SDP Media Capabilities . . . . . . . . . . . . . . . . . . . . 6 3. SDP Media Capabilities . . . . . . . . . . . . . . . . . . . . 6
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 7 3.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 7
3.3. New Capability Attributes . . . . . . . . . . . . . . . . 12 3.3. New Capability Attributes . . . . . . . . . . . . . . . . 13
3.3.1. The Media Encoding Capability Attribute . . . . . . . 13 3.3.1. The Media Encoding Capability Attribute . . . . . . . 13
3.3.2. The Media Format Parameter Capability Attribute . . . 14 3.3.2. The Media Format Parameter Capability Attribute . . . 14
3.3.3. The Media-Specific Capability Attribute . . . . . . . 17 3.3.3. The Media-Specific Capability Attribute . . . . . . . 17
3.3.4. Additional Capability Attributes . . . . . . . . . . . 18 3.3.4. New Configuration Parameters . . . . . . . . . . . . . 18
3.3.5. The Latent Configuration Attribute . . . . . . . . . . 20 3.3.5. The Latent Configuration Attribute . . . . . . . . . . 20
3.3.6. Enhanced Potential Configuration Attribute . . . . . . 24 3.3.6. Enhanced Potential Configuration Attribute . . . . . . 22
3.3.7. Substitution of Media Payload Type Numbers in 3.3.7. Substitution of Media Payload Type Numbers in
Capability Attribute Parameters . . . . . . . . . . . 27 Capability Attribute Parameters . . . . . . . . . . . 25
3.3.8. The Session Capability Attribute . . . . . . . . . . . 28 3.3.8. The Session Capability Attribute . . . . . . . . . . . 27
3.4. Offer/Answer Model Extensions . . . . . . . . . . . . . . 32 3.4. Offer/Answer Model Extensions . . . . . . . . . . . . . . 31
3.4.1. Generating the Initial Offer . . . . . . . . . . . . . 33 3.4.1. Generating the Initial Offer . . . . . . . . . . . . . 31
3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 33 3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 32
3.4.3. Offerer Processing of the Answer . . . . . . . . . . . 34 3.4.3. Offerer Processing of the Answer . . . . . . . . . . . 32
3.4.4. Modifying the Session . . . . . . . . . . . . . . . . 34 3.4.4. Modifying the Session . . . . . . . . . . . . . . . . 32
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. Alternative Codecs . . . . . . . . . . . . . . . . . . . . 35 4.1. Alternative Codecs . . . . . . . . . . . . . . . . . . . . 33
4.2. Alternative Combinations of Codecs (Session 4.2. Alternative Combinations of Codecs (Session
Configurations) . . . . . . . . . . . . . . . . . . . . . 38 Configurations) . . . . . . . . . . . . . . . . . . . . . 36
4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 38 4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 36
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
6. Security Considerations . . . . . . . . . . . . . . . . . . . 43 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
7. Changes from previous versions . . . . . . . . . . . . . . . . 44 7. Changes from previous versions . . . . . . . . . . . . . . . . 41
7.1. Changes from version 03 . . . . . . . . . . . . . . . . . 44 7.1. Changes from version 04 . . . . . . . . . . . . . . . . . 41
7.2. Changes from version 02 . . . . . . . . . . . . . . . . . 44 7.2. Changes from version 03 . . . . . . . . . . . . . . . . . 41
7.3. Changes from version 01 . . . . . . . . . . . . . . . . . 45 7.3. Changes from version 02 . . . . . . . . . . . . . . . . . 42
7.4. Changes from version 00 . . . . . . . . . . . . . . . . . 45 7.4. Changes from version 01 . . . . . . . . . . . . . . . . . 42
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 7.5. Changes from version 00 . . . . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Normative References . . . . . . . . . . . . . . . . . . . 47 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . . . 47 9.1. Normative References . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 9.2. Informative References . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
Session Description Protocol (SDP) capability negotiation [SDPCapNeg] Session Description Protocol (SDP) capability negotiation [SDPCapNeg]
provides a general framework for indicating and negotiating provides a general framework for indicating and negotiating
capabilities in SDP[RFC4566]. The base framework defines only capabilities in SDP[RFC4566]. The base framework defines only
capabilities for negotiating transport protocols and attributes. capabilities for negotiating transport protocols and attributes.
SDP Simple Capability Declaration (simcap) is defined in RFC 3407
[RFC3407]. It defines a set of SDP attributes that enables a limited
set of capabilities to be described at a session level or on a per
media stream basis. The capabilities include a simple form of media
capabilities. RFC 3407 defines capability declaration only. Actual
negotiation procedures taking advantage of such capabilities have not
been defined. The SDP capability negotiation framework defined in
[SDPCapNeg] adds this required functionality, but does not define
media capabilities. This document updates RFC3407 and [SDPCapNeg]
and new implementations SHOULD use the functionality defined in the
current document to negotiate media capabilities.
The [SDPCapNeg] document lists some of the issues with the current The [SDPCapNeg] document lists some of the issues with the current
SDP capability negotiation process. An additional real life case is SDP capability negotiation process. An additional real life case is
to be able to offer one media stream (e.g. audio) but list the to be able to offer one media stream (e.g. audio) but list the
capability to support another media stream (e.g. video) without capability to support another media stream (e.g. video) without
actually offering it currently. actually offering it currently.
In this document, we extend the framework by defining media In this document, we extend the framework by defining media
capabilities that can be used to indicate and negotiate media types capabilities that can be used to indicate and negotiate media types
and their associated stream parameters such as bandwidth. This and their associated format parameters. This document also adds the
document also adds the ability to declare support for media streams, ability to declare support for media streams, the use of which can be
the use of which can be offered and negotiated later. The offered and negotiated later, and the ability to specify session
configurations as combinations of media stream configurations. The
definitions of new attributes for media capability negotiation are definitions of new attributes for media capability negotiation are
chosen to make the translation from these attributes to chosen to make the translation from these attributes to
"conventional" SDP [RFC4566] media attributes as straightforward as "conventional" SDP [RFC4566] media attributes as straightforward as
possible in order to simplify implementation. This goal is intended possible in order to simplify implementation. This goal is intended
to reduce processing in two ways: each proposed configuration in an to reduce processing in two ways: each proposed configuration in an
offer may be easily translated into a conventional SDP media stream offer may be easily translated into a conventional SDP media stream
record for processing by the receiver; and the construction of an record for processing by the receiver; and the construction of an
answer based on a selected proposed configuration is straightforward. answer based on a selected proposed configuration is straightforward.
2. Terminology 2. Terminology
skipping to change at page 7, line 20 skipping to change at page 7, line 20
mechanism. mechanism.
REQ-09: Provide the ability to specify acceptable combinations of REQ-09: Provide the ability to specify acceptable combinations of
media streams and encodings. For example, offer a PCMU audio media streams and encodings. For example, offer a PCMU audio
stream with an H264 video stream, or a G729 audio stream with an stream with an H264 video stream, or a G729 audio stream with an
H263 video stream. This ability would give the offerer a means to H263 video stream. This ability would give the offerer a means to
limit processing requirements for simultaneous streams. This limit processing requirements for simultaneous streams. This
would also permit an offer to include the choice of an audio/T38 would also permit an offer to include the choice of an audio/T38
stream or an image/T38 stream, but not both. stream or an image/T38 stream, but not both.
REQ-10: Provide capability negotiation attributes for all media-
level SDP line types in the same manner as already done for the
attribute type, with the exception of the media line type itself.
The media line type is handled in a special way to permit compact
expression of media coding/format options.
Other possible extensions have been discussed, but have not been Other possible extensions have been discussed, but have not been
treated in this document. They may be considered in the future. Two treated in this document. They may be considered in the future. Two
such extensions are: such extensions are:
FUT-01: Provide the ability to mix, or change, media types within a FUT-01: Provide the ability to mix, or change, media types within a
single media block. Conventional SDP does not support this single media block. Conventional SDP does not support this
capability explicitly; the usual technique is to define a media capability explicitly; the usual technique is to define a media
subtype that represents the actual format within the nominal media subtype that represents the actual format within the nominal media
type. For example, T.38 FAX as an alternative to audio/PCMU type. For example, T.38 FAX as an alternative to audio/PCMU
within an audio stream is identified as audio/T38; a separate FAX within an audio stream is identified as audio/T38; a separate FAX
stream would use image/T38. stream would use image/T38.
FUT-02: Provide the ability to support multiple transport protocols FUT-02: Provide the ability to support multiple transport protocols
within an active media stream without reconfiguration. This is within an active media stream without reconfiguration. This is
not explicitly supported by conventional SDP. not explicitly supported by conventional SDP.
FUT-03: Provide capability negotiation attributes for all media-
level SDP line types in the same manner as already done for the
attribute type, with the exception of the media line type itself.
The media line type is handled in a special way to permit compact
expression of media coding/format options. The lines types are
bandwidth ("b="), information ("i="), connection data ("c="), and,
possibly, the deprecated encryption key ("k=").
3.2. Solution Overview 3.2. Solution Overview
The solution consists of new capability attributes corresponding to The solution consists of new capability attributes corresponding to
conventional SDP line types, new parameters for the pcfg attribute conventional SDP line types, new parameters for the pcfg attribute
extending the base attributes from [SDPCapNeg], and a use of the pcfg extending the base attributes from [SDPCapNeg], and a use of the pcfg
attribute to return capability information in the SDP answer. attribute to return capability information in the SDP answer.
Three new attributes are defined in a manner that can be related to Three new attributes are defined in a manner that can be related to
the capabilities specified in a media line, and its corresponding the capabilities specified in a media line, and its corresponding
rtpmap and fmtp attributes. rtpmap and fmtp attributes.
skipping to change at page 8, line 22 skipping to change at page 8, line 23
o A new attribute ("a=mfcap") specifies media format parameters o A new attribute ("a=mfcap") specifies media format parameters
associated with one or more media capabilities. The mfcap associated with one or more media capabilities. The mfcap
attribute is used primarily to associate the formatting attribute is used primarily to associate the formatting
capabilities normally carried in the fmtp attribute. capabilities normally carried in the fmtp attribute.
o A new attribute ("a=mscap") that specifies media parameters o A new attribute ("a=mscap") that specifies media parameters
associated with one or more media capabilities. The mscap associated with one or more media capabilities. The mscap
attribute is used to associate capabilities with attributes other attribute is used to associate capabilities with attributes other
than fmtp or rtpmap, for example, the rtcp-fb attribute. than fmtp or rtpmap, for example, the rtcp-fb attribute.
o Several new capability attributes, corresponding to several SDP
line types (e.g., the bandwidth type "b="}, are defined for use in
capability negotiations.
o A new attribute ("a=lcfg") specifies latent media stream o A new attribute ("a=lcfg") specifies latent media stream
configurations when no corresponding media line ("m=") is offered. configurations when no corresponding media line ("m=") is offered.
An example is the offer of a latent configuration for video even An example is the offer of a latent configuration for video even
though no video is currently offered. If both parties indicate though no video is currently offered. If both parties indicate
support for one or more latent configurations, the corresponding support for one or more latent configurations, the corresponding
media stream(s) may be added via a new offer/answer exchange. media stream(s) may be added via a new offer/answer exchange.
o A new attribute ("a=sescap") is used to specify an acceptable o A new attribute ("a=sescap") is used to specify an acceptable
combination of simultaneous media streams as a list of potential combination of simultaneous media streams as a list of potential
and/or latent configurations. and/or latent configurations.
skipping to change at page 9, line 14 skipping to change at page 9, line 11
o A new parameter type ("pt=") is added to the potential o A new parameter type ("pt=") is added to the potential
configuration, actual configuration, and latent configuration configuration, actual configuration, and latent configuration
attributes. This parameter associates RTP payload types numbers attributes. This parameter associates RTP payload types numbers
with the referenced media capabilities, and is appropriate only with the referenced media capabilities, and is appropriate only
when the transport protocol uses RTP. when the transport protocol uses RTP.
o A new parameter type ("mt=") is used to specify the media type for o A new parameter type ("mt=") is used to specify the media type for
latent configurations. latent configurations.
o New parameter types (e.g., "b=") are used to specify conventional
SDP parameters in potential or latent configurations.
Special processing rules are defined for capability attribute Special processing rules are defined for capability attribute
arguments in order to reduce the need to replicate essentially- arguments in order to reduce the need to replicate essentially-
identical attribute lines for the base configuration and potential identical attribute lines for the base configuration and potential
configurations. configurations.
o A substitution rule is defined for any capability attribute to o A substitution rule is defined for any capability attribute to
permit the replacement of the (escaped) media capability number permit the replacement of the (escaped) media capability number
with the media format identifier (e.g., the payload type number in with the media format identifier (e.g., the payload type number in
audio/video profiles). audio/video profiles).
skipping to change at page 11, line 36 skipping to change at page 11, line 36
The "a=mfcap:5" line specifies the fmtp formatting parameters for The "a=mfcap:5" line specifies the fmtp formatting parameters for
capability 5 (the DTMF touchtones 0-9,*,#). capability 5 (the DTMF touchtones 0-9,*,#).
The "a=acap:1" line specified in the base protocol provides the The "a=acap:1" line specified in the base protocol provides the
"crypto" attribute which provides the keying material for SRTP using "crypto" attribute which provides the keying material for SRTP using
SDP security descriptions. SDP security descriptions.
The "a=pcfg:" attributes provide the potential configurations The "a=pcfg:" attributes provide the potential configurations
included in the offer by reference to the media capabilities, included in the offer by reference to the media capabilities,
transport capabilities, and associated payload type number mappings. transport capabilities, and associated payload type number mappings.
Three explicit alternatives are provided; the first one, numbered 1 Three explicit alternatives are provided; the lowest-numbered one is
is the preferred one. It specifies media capabilities 4 and 5, i.e., the preferred one. The "a=pcfg:1 ..." line specifies media
G.729B and DTMF, or media capability 1 and 5, i.e., G.729 and DTMF. capabilities 4 and 5, i.e., G.729B and DTMF, or media capability 1
Furthermore, it specifies transport protocol capability 1 (i.e. the and 5, i.e., G.729 and DTMF. Furthermore, it specifies transport
RTP/SAVP profile - secure RTP), and the attribute capability 1, i.e. protocol capability 1 (i.e. the RTP/SAVP profile - secure RTP), and
the crypto attribute provided. Lastly, it specifies a payload type the attribute capability 1, i.e. the crypto attribute provided.
number mapping for media capabilities 1, 4, and 5, thereby permitting Lastly, it specifies a payload type number mapping for media
the offeror to distinguish between encrypted media and unencrypted capabilities 1, 4, and 5, thereby permitting the offeror to
media received prior to receipt of the answer. Use of unique payload distinguish between encrypted media and unencrypted media received
type numbers is not required; codecs such as AMR-WB [RFC4867] have prior to receipt of the answer.
the potential for so many combinations of options that it may be
impractical to define unique payload type numbers for all supported
combinations. If unique payload type numbers cannot be specified,
then the offerer will be obliged to wait for the SDP answer before
rendering received media. For SRTP using SDES inline keying
[RFC4568], the offeror will still need to receive the answer before
being able to decrypt the stream.
The second alternative specifies media capability 2, i.e. PCMU, Use of unique payload type numbers is not required; codecs such as
under the RTP/SAVP profile, with the same SRTP key material. AMR-WB [RFC4867] have the potential for so many combinations of
options that it may be impractical to define unique payload type
numbers for all supported combinations. If unique payload type
numbers cannot be specified, then the offerer will be obliged to wait
for the SDP answer before rendering received media. For SRTP using
SDES inline keying [RFC4568], the offeror will still need to receive
the answer before being able to decrypt the stream.
The third alternative offers G.729B unsecured; it's only purpose in The second alternative ("a=pcfg:2 ...") specifies media capability 2,
this example is to show a preference for G.729B over PCMU. i.e. PCMU, under the RTP/SAVP profile, with the same SRTP key
material.
The third alternative ("a=pcfg:3 ...") offers G.729B unsecured; it's
only purpose in this example is to show a preference for G.729B over
PCMU.
The media line, with any qualifying attributes such as fmtp or The media line, with any qualifying attributes such as fmtp or
rtpmap, is itself considered a valid configuration; it is assumed to rtpmap, is itself considered a valid configuration; it is assumed to
be the lowest preference. be the lowest preference.
Bob receives the SDP offer from Alice. Bob supports G.729B, PCMU, Bob receives the SDP offer from Alice. Bob supports G.729B, PCMU,
and telephone events over RTP, but not SRTP, hence he accepts the and telephone events over RTP, but not SRTP, hence he accepts the
potential configuration 3 for RTP provided by Alice. Bob generates potential configuration 3 for RTP provided by Alice. Bob generates
the following answer: the following answer:
skipping to change at page 14, line 9 skipping to change at page 14, line 12
media capabilities and associates them with a media capability number media capabilities and associates them with a media capability number
in the same manner as the rtpmap attribute defines them and in the same manner as the rtpmap attribute defines them and
associates them with a payload type number. associates them with a payload type number.
In ABNF, we have: In ABNF, we have:
media-capability-line = "a=mcap:" media-cap-num-list media-capability-line = "a=mcap:" media-cap-num-list
1*WSP media-cap 1*WSP media-cap
["/" clock-rate ["/" encoding-parms]] ["/" clock-rate ["/" encoding-parms]]
media-cap-num-list = media-cap-num *[COMMA media-cap-num] media-cap-num-list = media-cap-num *[COMMA media-cap-num]
media-cap-num = 1*DIGIT | media-cap-range media-cap-num = 1*DIGIT / media-cap-range
media-cap-range = 1*DIGIT "-" 1*DIGIT media-cap-range = 1*DIGIT "-" 1*DIGIT
media-cap = token ; Subtype name(PCMU, G729, etc.) media-cap = token ; Subtype name(PCMU, G729, etc.)
clock-rate = 1*DIGIT clock-rate = 1*DIGIT
encoding-parms = token encoding-parms = token
The clock-rate and encoding-params are as defined to appear in an The clock-rate and encoding-params are as defined to appear in an
rtpmap attribute for each media type/subtype. Thus, it is easy to rtpmap attribute for each media type/subtype. Thus, it is easy to
convert an mcap attribute line into one or more rtpmap attribute convert an mcap attribute line into one or more rtpmap attribute
lines, once a payload type number is assigned to a media-cap-num (see lines, once a payload type number is assigned to a media-cap-num (see
section 3.3.5). section 3.3.5).
skipping to change at page 16, line 48 skipping to change at page 17, line 4
Finally, for six format combinations of the Adaptive MultiRate codec: Finally, for six format combinations of the Adaptive MultiRate codec:
a=mcap:1-3 AMR/8000/1 a=mcap:1-3 AMR/8000/1
a=mcap:4-6 AMR-WB/16000/1 a=mcap:4-6 AMR-WB/16000/1
a=mfcap:1,2,3,4 mode-change-capability=1 a=mfcap:1,2,3,4 mode-change-capability=1
a=mfcap:5,6 mode-change-capability=2 a=mfcap:5,6 mode-change-capability=2
a=mfcap:1,2,3,5 max-red=220 a=mfcap:1,2,3,5 max-red=220
a=mfcap:3,4,5,6 octet-align=1 a=mfcap:3,4,5,6 octet-align=1
a=mfcap:1,3,5 mode-set=0,2,4,7 a=mfcap:1,3,5 mode-set=0,2,4,7
a=mfcap:2,4,6 mode-set=0,3,5,6 a=mfcap:2,4,6 mode-set=0,3,5,6
So that AMR codec #1, when specified in a pcfg attribute within an So that AMR codec #1, when specified in a pcfg attribute within an
audio stream block (and assigned payload type number 98) as in audio stream block (and assigned payload type number 98) as in
a=pcfg:1 m=1 pt=1:98 a=pcfg:1 m=1 pt=1:98
is essentially equivalent to the following is essentially equivalent to the following
m=audio 49170 RTP/AVP 98 m=audio 49170 RTP/AVP 98
a=rtpmap:98 AMR/8000/1 a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-change-capability=1; max-red=220; mode- a=fmtp:98 mode-change-capability=1; max-red=220; mode-
set=0,2,4,7 set=0,2,4,7
and AMR codec #4 with payload type number 99, is essentially and AMR codec #4 with payload type number 99,depicted by the
equivalent to the following: potential configuration:
a=pcfg:4 m=4, pt=4:99
is equivalent to the following:
m=audio 49170 RTP/AVP 99 m=audio 49170 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000/1 a=rtpmap:99 AMR-WB/16000/1
a=fmtp:99 mode-change-capability=1; octet-align=1; mode- a=fmtp:99 mode-change-capability=1; octet-align=1; mode-
set=0,3,5,6 set=0,3,5,6
and so on for the other four combinations. SDP could thus convert and so on for the other four combinations. SDP could thus convert
the media capabilities specifications into one or more alternative the media capabilities specifications into one or more alternative
media stream specifications, one of which can be chosen for the media stream specifications, one of which can be chosen for the
answer. answer.
skipping to change at page 17, line 43 skipping to change at page 18, line 4
<media-caps> ; defined in 3.3.2 <media-caps> ; defined in 3.3.2
1*WSP <att-field> ; from [RFC4566] 1*WSP <att-field> ; from [RFC4566]
1*WSP <ms-parameters> 1*WSP <ms-parameters>
ms-parameters = byte-string ; as defined per attribute. ms-parameters = byte-string ; as defined per attribute.
Given an association between a media capability and a payload type Given an association between a media capability and a payload type
number as specified by the pt= parameters in an lcfg or pcfg number as specified by the pt= parameters in an lcfg or pcfg
attribute line, a mscap line may be translated easily into a attribute line, a mscap line may be translated easily into a
conventional SDP attribute line of the form conventional SDP attribute line of the form
a=<att-field>":"<fmt> <ms-parameters> ; fmt defined in [RFC4566] a=<att-field>":"<fmt> <ms-parameters> ; fmt defined in [RFC4566]
The resulting attribute SHOULD be a legal SDP attribute, otherwise it A resulting attribute that is not a legal SDP attribute as specified
MUST be ignored by the receiver. by RFC4566 MUST be ignored by the receiver.
A single mscap line may refer to multiple media capabilities; this is A single mscap line may refer to multiple media capabilities; this is
equivalent to multiple mscap lines, each with the same attribute equivalent to multiple mscap lines, each with the same attribute
values, one line per media capability. values, one line per media capability.
Multiple mscap lines may refer to the same media capability, but, Multiple mscap lines may refer to the same media capability, but,
unlike the mfcap attribute, no concatenation operation is defined. unlike the mfcap attribute, no concatenation operation is defined.
Hence, multiple mscap lines applied to the same media capability is Hence, multiple mscap lines applied to the same media capability is
equivalent to multiple lines of the specified attribute in a equivalent to multiple lines of the specified attribute in a
conventional media record. conventional media record.
skipping to change at page 18, line 33 skipping to change at page 18, line 41
and if the proposed configuration is chosen, then the equivalent and if the proposed configuration is chosen, then the equivalent
media block would look like media block would look like
m=video 51372 RTP/AVPF 98 m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir a=rtcp-fb:98 ccm fir
a=rtcp-fb:* ccm tmmbr smaxpr=120 a=rtcp-fb:* ccm tmmbr smaxpr=120
3.3.4. Additional Capability Attributes 3.3.4. New Configuration Parameters
SDP [RFC4566] provides a number of line types which may be useful in
negotiation of media streams. In particular, those line types that
may be used at the media level, specifically media (m=), session
information (i=), connection (c=), bandwidth (b=), encryption key
(k=), and attribute (a=) may require a corresponding capability
negotiation attribute. The a= attribute line has been treated in
[SDPCapNeg] to produce the acap attribute. Consideration of the m=
media line leads to the pcfg attribute defined in [SDPCapNeg] and the
lcfg, mcap, mfcap, and mscap attributes defined in this document. A
CapNeg attribute for the connection line (c=) has been described in
[I-D.garcia-mmusic-sdp-cs]. It seems better to define such
attributes here, rather than have the definitions appear across a
number of documents not directly related to capabilities negotiation.
Without spending much effort to assess future utility, this section
defines a number of capability attributes that may prove useful in
the future.
SDP types that can appear only at the session level, and only one
time, are not expected to be negotiable. This applies to the
protocol version ("v="), origin ("o="), session name ("s="), and URI
("u=") types. Email ("e="), phone ("p="), and time/repeat/timezone
fields ("t=", "r=", and "z=") may appear multiple times in a session
description, but it's not clear why one might negotiate different
email addresses or phone numbers for a particular session. It might
be useful to negotiate different times for a session (a broadcast of
the CEOs speech, for example) depending on the video encoding to be
used (e.g., H.263 or H.264), but this could just as well be
accomplished by announcing two sessions, one for each encoding; in
practice, a single session will likely offer multiple encodings at
the same time. For the present, we adopt the position that the
session-level-only types need not be negotiable via CapNeg. The
following capability attributes are always to be interpreted as
media-level fields when invoked by a potential (pcfg) or latent
(lcfg) configuration. Note that the SDP encryption key type (k=) is
NOT RECOMMENDED in RFC 4566; use of the kcap attribute should be
limited to cases in which no convenient alternative exists. The
encryption key field should be included only when/if the key is
transported over a secure, trusted channel.
The general form of the capability attributes is the same for the Along with the new attributes for media capabilities, new extension
above SDP types. Given the SDP line (from [RFC4566]) parameters are defined for use in the potential configuration, the
actual configuration, and the latent configuration (defined in
Section 3.3.5).
<type>=<value> 3.3.4.1. The Media Configuration Parameter (m=)
we define the corresponding capability attribute as The media configuration list is used to specify the media encodings
and related parameters for a configuration. The list is defined in
accordance with the following format:
a=<type-cap-attr> ":" <type-attr-num> 1*WSP <value> m=["+"]<med-cap-list> *["|"<med-cap-list>]
where where <med-cap-list> is a comma-separated list of media capability
numbers (media-cap-num) as defined by a=mcap: lines (section 3.3.1).
In ABNF form (adhering to the ABNF for extension-config-list in
[SDPCapNeg]
<type-cap-attr> = <type> "cap" media-config-list = ["+"]"m=" med-cap-list
[*(BAR med-cap-list)]
; BAR is defined in [SDPCapNeg]
med-cap-list = med-cap-num *("," med-cap-num)
med-cap-num = 1*DIGIT ; defined in SDP
<type> = %x69 / ; "i" Alternative media configurations are separated by a vertical bar
%x63 / ; "c" ("|"). The alternatives are ordered by preference, most-preferred
%x62 / ; "b" first. When media capabilities are not included in a potential
%x6b / ; "k" configuration at the media level, the media type and media format
%x61 / ; "a" from the associated "m=" line will be used.
<type-attr-num> = 1*DIGIT ; integer, 1 to 2^31, inclusive 3.3.4.2. The Payload Type Number Mapping Parameter (pt=)
where <value> is as defined specifically for each <type> in [RFC4566] We define the payload type number mapping parameter, payload-number-
and, possibly, extended in other RFCs. The definitions above config-list, in accordance with the extension-config-list format
correspond to the acap definition in [SDPCapNeg] and the ccap defined in [SDPCapNeg]
definition proposed in [I-D.garcia-mmusic-sdp-cs].
As an example, consider the negotiation of bandwidth. In some cases payload-number-config-list = ["+"]"pt=" med-map-list
it is desirable to specify different bandwidth limits for different med-map-list = med-map *["," med-map]
media configurations. This may be done by use of the "a=bcap" med-map = med-cap-num ":" payload-type-number
attribute, which, from the above and [RFC4566], is defined as ; med-cap-num is defined in section 3.4.1
follows: payload-type-number = 1*DIGIT / "*" ; RTP payload type number
a=bcap:<bw-cap-num> <bwtype>:<bandwidth> The example in the section 3.3.7 shows how the parameters from the
mcap line are mapped to payload type numbers from the pcfg "pt"
parameter. The "*" value is used in cases such as BFCP [RFC4583] in
which the fmt list in the m-line is ignored.
where <bw-cap-num> is an integer between 1 and 2^31-1 (both included) A latent configuration represents a future capability, hence the pt=
used to identify the bandwidth capability, <bwtype> is the bandwidth parameter is not directly meaningful in the lcfg attribute because no
type, and <bandwidth> is the bandwidth value, as defined for the b= actual media session is being offered or accepted; it is permitted in
line in RFC4566[RFC4566] order to tie any payload type number parameters within attributes to
the proper media format. A primary example is the case of format
parameters for the RED payload, which are payload type numbers.
Specific payload type numbers used in a latent configuration may be
interpreted as suggestions to be used in any future offer based on
the latent configuration, but they are not binding; the offeror
and/or answerer may use any payload type numbers each deems
appropriate. The use of explicit payload type numbers for latent
configurations can be avoided by use of the parameter substitution
rule of section 3.3.7. Future extensions are also permitted.
The "bcap" attribute can appear at the session level, where it can be 3.3.4.3. The Media Type Parameter
referenced by lcfg or pcfg attributes, or at the media level, where
it can be referenced by pcfg attributes. When invoked by a pcfg or
lcfg attribute, the resulting bandwidth line (b=) is to be
interpreted at the media-level for that configuration. There can be
more than one bcap attribute. The unique bw-cap-num is used to
identify it in potential configurations. No provision has been made
for negotiation of total session bandwidth capabilities.
Bandwidth capabilities may be included in a potential configuration When a latent configuration is specified (always at the session
via the "b=" parameter (see below). Any bandwidth capability level), indicating the ability to support an additional media stream,
included replaces any media-level bandwidth of the same type declared it is necessary to specify the media type (audio, video, etc.) as
in a "b=" SDP line. well as the format and transport type. The media type parameter is
defined as
The following example offers a preferred potential configuration for media-type = "mt=" 1*WSP media; media defined in RFC4566.
H.263 QCIF at 360 Kbit/sec and a second potential configuration for
H.263 CIF at the offered 500 Kbit/sec
m=video 49170 RTP/AVP 99 At present, the media-type parameter is used only in the latent
b=TIAS:500000 configuration attribute. The media format(s) and transport type(s)
a=rtpmap:99 H263-1998/90000 are specified using the media configuration parameter ("m=") defined
a=fmtp:99 CIF=4; QCIF=2 above, and the transport parameter ("t=") defined in [SDPCapNeg],
a=mcap:1,2 video H263-1998/90000 respectively.
a=mfcap:1 QCIF=2
a=mfcap:2 CIF=4; QCIF=2;F=1;K=1
a=bcap:1 TIAS:360000
a=pcfg:1 m=1 b=1 pt=1:100
a=pcfg:2 m=2 pt=2:101
3.3.5. The Latent Configuration Attribute 3.3.5. The Latent Configuration Attribute
One of the goals of this work is to permit the exchange of One of the goals of this work is to permit the exchange of
supportable media configurations in addition to those offered or supportable media configurations in addition to those offered or
accepted for immediate use. Such configurations are referred to as accepted for immediate use. Such configurations are referred to as
"latent configurations". For example, a party may offer to establish "latent configurations". For example, a party may offer to establish
a session with an audio stream, and, at the same time, announce its a session with an audio stream, and, at the same time, announce its
ability to support a video stream as part of the same session. The ability to support a video stream as part of the same session. The
offerer can supply its video capabilities by offering a latent video offerer can supply its video capabilities by offering one or more
configuration along with the media stream for audio; the responding latent video configurations along with the media stream for audio;
party may indicate its ability and willingness to support such a the responding party may indicate its ability and willingness to
video session by returning a corresponding latent configuration. support such a video session by returning a corresponding latent
configuration.
Latent configurations returned in SDP answers must match offered Latent configurations returned in SDP answers must match offered
latent configurations (or parameter subsets thereof). Therefore, it latent configurations (or parameter subsets thereof). Therefore, it
is appropriate for the offering party to announce most, if not all, is appropriate for the offering party to announce most, if not all,
of its capabilities in the initial offer. [Editor's note: this of its capabilities in the initial offer. This choice has been made
choice has been made in order to keep the size of the answer more in order to keep the size of the answer more compact by not requiring
compact by not requiring acap, mcap, tcap, etc. lines in the answer. acap, mcap, tcap, etc. lines in the answer.
However, this restriction can be changed if it seems desirable.]
Latent configurations may be announced by use of the latent Latent configurations may be announced by use of the latent
configuration attribute, which is defined in a manner very similar to configuration attribute, which is defined in a manner very similar to
the potential configuration attribute. The media type (mt=) and the the potential configuration attribute. The media type (mt=) and the
transport protocol(s) (t=) MUST be specified since there is no transport protocol(s) (t=) MUST be specified since there is no
corresponding m-line for defaults. In most cases, the media corresponding m-line for defaults. In most cases, the media
configuration (m=) parameter must be present as well (see section configuration (m=) parameter must be present as well (see section
3.3.8 for examples). The lcfg attribute is a session level 3.3.8 for examples). The lcfg attribute is a session level
attribute, and all capability attributes referenced by lcfg attribute attribute, and all capability attributes referenced by lcfg attribute
parameters must appear at the session level in the SDP record. parameters must appear at the session level in the SDP record.
latent-media-config = "a=lcfg:" <config-number> The latent configuration attribute is defined as:
1*WSP "mt=" <media> ;[RFC4566]
1*WSP transport-protocol-config-list
; defined in [SDPCapNeg]
[1*WSP media-config-list]
[1*WSP attribute-config-list]
; defined in [SDPCapNeg]
[1*WSP payload-number-config-list]
[1*WSP info-cap]
[1*WSP connection-config-list]
[1*WSP bandwidth-config-list]
[1*WSP key-config-list]
[1*(1*WSP extension-config-list)]
; defined in [SDPCapNeg]
The mt= parameter identifies the media type (audio, video, etc.) to
be associated with the latent media stream; the transport (t=) and
attribute (a=) parameters are identical in format and meaning to
those defined for the pcfg: attribute in [SDPCapNeg]. The media
subtype(s) and format parameters to be associated with the stream are
specified by the m= parameter.
The transport parameter (t=) is identical in format and meaning as
defined for the pcfg attribute in [SDPCapNeg]
We define the media configuration parameter, media-config-list, in
accordance with the following format:
m=<med-cap-list> *["|"<med-cap-list>]
where <med-cap-list> is a comma-separated list of media capability
numbers (media-cap-num) as defined by a=mcap: lines (section 3.3.1).
In ABNF form (adhering to the ABNF for extension-config-list in
[SDPCapNeg]
media-config-list = "m=" med-cap-list *(BAR med-cap-list)
; BAR is defined in [SDPCapNeg]
med-cap-list = med-cap-num *("," med-cap-num)
med-cap-num = 1*DIGIT ; defined in SDP
Each potential media configuration is a comma-separated list of media
capability numbers where med-cap-num refers to media capability
numbers defined explicitly by a=mcap attributes and hence MUST be
between 1 and 2^31-1 (both included). Alternative potential media
configurations are separated by a vertical bar ("|"). The
alternatives are ordered by preference.
The attribute parameter (a=) is identical in format and meaning as
defined for the pcfg attribute in [SDPCapNeg].
We define the payload type number mapping parameter, pt-media-map, in
accordance with the following format:
payload-number-config-list = "pt=" med-map-list
med-map-list = med-map *["," med-map]
med-map = med-cap-num ":" payload-type-number
; med-cap-num is defined in section 3.4.1
payload-type-number = 1*DIGIT | "*" ; RTP payload type number
The example in the section 3.3.7 shows how the parameters from the
mcap line are mapped to payload type numbers from the pcfg "pt"
parameter. The "*" value is used in cases such as BFCP [RFC4583] in
which the fmt list in the m-line is ignored.
The session information parameter, info-cap, provides the capability a=lcfg: <config-number> 1*WSP <pot-cfg-list>
number of a session information (icap) capability attribute. In
accordance with RFC 4566, which permits no more than one i-line per
media stream, only one icap attribute may be specified. The format
of the parameter is defined as
info-cap = "i=" [delete] icap-num
delete = "-:" ; delete media-level i= line, if present
icap-num = 1*DIGIT ; cap-num from icap attribute
The connection data parameter, connection-config-list, may be used to which adheres to the RFC4566 "attribute" production with an att-value
provide stream-specific connection data by reference to one or more defined as:
ccap attributes in the SDP record.
connection-config-list = "c=" [delete] full-ccap-list att-value = config-number 1*(1*WSP latent-cfg-parm))
full-ccap-list = mandatory-ccap-list ["," optional-ccap-list]
mandatory-ccap-list = ccap-list
optional-ccap-list = "[" ccap-list "]"
ccap-list = ccap-num [1*("," ccap-num)]
ccap-num = 1*DIGIT ; cap-num from ccap attribute
The bandwidth configuration parameter, bandwidth-config-list, may be where
used to provide bandwidth specifications by reference to bcap
attributes described in section 3.3.4.
bandwidth-config-list = "b=" [delete] full-bcap-list latent-cfg-parm = media-type
full-bcap-list = mandatory-bcap-list ["," optional-bcap-list] ; defined in Sect. 3.3.4.3
mandatory-bcap-list = bcap-list / transport-protocol-config-list
optional-bcap-list = "[" bcap-list "]" ; defined in [SDPCapNeg]
bcap-list = bcap-num *("," bcap-num) / media-config-list
bcap-num = 1*DIGIT ; cap-num from bcap attribute ; defined in Sect. 3.3.4.1
/ attribute-config-list
; defined in [SDPCapNeg]
/ payload-number-config-list
; defined in Sect. 3.3.4.2
/ extension-config-list
; defined in [SDPCapNeg]
Although use of the encryption key line is NOT RECOMMENDED by RFC The media-type (mt=) parameter identifies the media type (audio,
4566, kcap attributes, defined in section 3.3.4, may be referenced video, etc.) to be associated with the latent media stream, and must
through the k= parameter. be present. The transport-protocol-config-list (t=) parameter and
the media-config-list (m=) parameter must also be present. Except
for the extension-config-list, the pot-cfg-list MUST NOT contain more
than one instance of each parameter list.
key-config-list = "k=" [delete] full-kcap-list The transport-protocol-config-list(t=), the attribute-config-list
full-kcap-list = mandatory-kcap-list ["," optional-kcap-list] (a=), and the extension-config-list are identical in format and
mandatory-kcap-list = kcap-list meaning as defined for the pcfg attribute in [SDPCapNeg]. As
optional-kcap-list = "[" kcap-list "]" specified in [SDPCapNeg], the use of the "+" prefix for a parameter
kcap-list = kcap-num *("," kcap-num) indicates that the entire configuration must be ignored if the
kcap-num = 1*DIGIT ; cap-num from kcap attribute parameter is not understood; otherwise, the parameter itself may be
ignored.
A latent configuration represents a future capability, hence the pt= Media stream payload numbers are not assigned by a latent
parameter is not directly meaningful in the lcfg attribute because no configuration. Assignment will take place if and when the
actual media session is being offered or accepted; it is permitted in corresponding stream is actually offered in a later exchange. The
order to tie any payload type number parameters within attributes to payload-number-config-list is included as a parameter to the lcfg
the proper media format. A primary example is the case of format attribute in case it is necessary to tie payload numbers in attribute
parameters for the RED payload, which are payload type numbers. capabilities to specific media capabilities.
Specific payload type numbers used in a latent configuration may be
interpreted as suggestions to be used in any future offer based on
the latent configuration, but they are not binding; the offeror
and/or answerer may use any payload type numbers each deems
appropriate. The use of explicit payload type numbers for latent
configurations can be avoided by use of the parameter substitution
rule of section 3.3.7. Future extensions are also permitted.
Each latent configuration MUST be specified at the session level; it Each latent configuration MUST be specified at the session level; it
represents an additional media stream to those in the media block(s} represents an additional media stream to those in the media block(s}
of the offer or answer. If an acap: attribute is declared at the of the offer or answer. If an acap: attribute is declared at the
session level for use in an lcfg line, it SHOULD NOT be used in a session level for use in an lcfg line, it SHOULD NOT be used in a
pcfg line at the media level unless it is to become a session-level pcfg line at the media level unless it is to become a session-level
attribute in the answer. attribute in the answer if that potential configuration becomes the
actual configuration. [Editors note: it could simplify processing if
all capabilities referenced by latent or potential configurations
became media-level attributes/capabilities when transformed into
media configurations. Are there examples where session-level
attributes must be negotiated at the media level? Perhaps we need
some sort of "session configuration" or "scfg=" to handle the
session-level fields. Perhaps that could be somehow added to the
sescap attribute defined below.]
The configuration numbers for latent configurations share the same The configuration numbers for latent configurations share the same
preference rule as potential configurations: a lower-numbered preference rule as potential configurations: a lower-numbered
configuration is preferred over a higher-numbered configuration. If configuration is preferred over a higher-numbered configuration. In
latent configurations are used in session capability (sescap=) order to permit intermixing of latent and potential configurations in
attributes (section 3.3.8), the configuration numbers MUST be session capabilities (see 3.3.8), latent configuration numbers MUST
different from those used for pcfg attributes. be different from those used for pcfg attributes.
If a cryptographic attribute, such as the SDES "a=crypto:" attribute If a cryptographic attribute, such as the SDES "a=crypto:" attribute
[RFC4568], is referenced by a latent configuration through an acap [RFC4568], is referenced by a latent configuration through an acap
attribute, any key material REQUIRED in the conventional attribute, attribute, any key material REQUIRED in the conventional attribute,
such as the SDES key/salt string, MUST be included in order to such as the SDES key/salt string, MUST be included in order to
satisfy formatting rules for the attribute. The actual value(s) of satisfy formatting rules for the attribute. The actual value(s) of
the key material SHOULD be meaningless, and the receiver of the lcfg: the key material SHOULD be meaningless, and the receiver of the lcfg:
attribute MUST ignore the values. attribute MUST ignore the values.
3.3.6. Enhanced Potential Configuration Attribute 3.3.6. Enhanced Potential Configuration Attribute
skipping to change at page 24, line 46 skipping to change at page 23, line 4
a=pcfg: <config-number> [<pot-cfg-list>] a=pcfg: <config-number> [<pot-cfg-list>]
where where
config-number = 1*DIGIT ;defined in [RFC5234] config-number = 1*DIGIT ;defined in [RFC5234]
pot-cfg-list = pot-config *(1*WSP pot-config) pot-cfg-list = pot-config *(1*WSP pot-config)
pot-config = attribute-config-list / pot-config = attribute-config-list /
;defined in [SDPCapNeg] ;defined in [SDPCapNeg]
transport-protocol-config-list / ;defined in [SDPCapNeg] transport-protocol-config-list / ;defined in [SDPCapNeg]
extension-config-list / ;[SDPCapNeg] extension-config-list / ;[SDPCapNeg]
media-config-list / ;sect. 3.3.5 media-config-list / ;sect. 3.3.4.1
payload-number-config-list / ; 3.3.5 payload-number-config-list / ; 3.3.4.2
info-cap / ;defined in section 3.3.5
connection-config-list / ; 3.3.5
bandwidth-config-list / ; 3.3.5
key-config-list ;section 3.3.5
The pot-cfg-list MUST NOT contain more than one instance of each Except for the extension-config-list, the pot-cfg-list MUST NOT
parameter list other than the extension-config-list. When media contain more than one instance of each parameter list.
capabilities are not included in a potential configuration at the
media level, the media type and media format from the associated "m="
line will be used.
3.3.6.1. Returning Capabilities in the Answer 3.3.6.1. Returning Capabilities in the Answer
Potential configuration attributes may be returned within the media Potential configuration attributes may be returned within the media
block(s) of an answer SDP to indicate the ability of the answerer to block(s) of an answer SDP to indicate the ability of the answerer to
to support alternative configurations of the corresponding stream(s). to support alternative configurations of the corresponding stream(s).
For example, an offer may include multiple potential configurations For example, an offer may include multiple potential configurations
for a media stream; the corresponding answer will indicate (via an for a media stream and/or latent configurations for additional
acfg attribute) which configuration is accepted, but it MAY also streams; the corresponding answer will indicate (via an acfg
contain potential configuration attributes, with parameters, to attribute) which configuration is accepted, but it MAY also contain
potential and/or latent configuration attributes, with parameters, to
indicate which other offered configurations would be acceptable. indicate which other offered configurations would be acceptable.
This information is useful if it becomes desirable to reconfigure a This information is useful if it becomes desirable to reconfigure a
media stream, e.g., to reduce resource consumption. media stream, e.g., to reduce resource consumption.
When potential configurations are returned in an answer, all When potential configurations are returned in an answer, all
numbering MUST refer to the configuration and capability attribute numbering MUST refer to the configuration and capability attribute
numbering of the offer. The referenced capability attributes MUST numbering of the offer. The referenced capability attributes MUST
NOT be returned in the answer. The parameter values of any returned NOT be returned in the answer. The parameter values of any returned
pcfg attributes MUST be a subset of those included in the offered pcfg or lcfg attributes MUST be a subset of those included in the
configurations; values may be omitted only if they were indicated as offered configurations; values may be omitted only if they were
alternative sets, or optional, in the original offer. The parameter indicated as alternative sets, or optional, in the original offer.
set indicated in the returned acfg attribute need not be repeated in The parameter set indicated in the returned acfg attribute need not
a returned pcfg attribute. The answerer may return more than one be repeated in a returned pcfg attribute. The answerer may return
pcfg attribute with the same configuration number if it is necessary more than one pcfg attribute with the same configuration number if it
to describe selected combinations of optional or alternative is necessary to describe selected combinations of optional or
parameters. alternative parameters.
Note that the answerer is unable to return additional capabilities Similarly, one or more session capability attributes (a=sescap) may
within an offered and answered media stream. For this reason, it be returned to indicate which of the offered session capabilities is/
seems advisable for the offerer to include most, if not all, are supportable by the answerer (see section 3.3.8.)
potential capabilities in the initial offer. Additional capabilities
MAY be announced via one or more latent configurations (representing Note that the answerer MUST NOT return capabilities beyond those
a new media stream), or when renegotiating the session in a second included by the offerer. For this reason, it seems advisable for the
offer/answer exchange. offerer to include most, if not all, potential and latent
configurations in the initial offer. Additional capabilities MAY be
announced later by renegotiating the session in a second offer/answer
exchange.
3.3.6.2. Payload Type Number Mapping 3.3.6.2. Payload Type Number Mapping
When media capabilities defined in mcap attributes are used in When media capabilities defined in mcap attributes are used in
potential configuration lines, and the transport protocol uses RTP, potential configuration lines, and the transport protocol uses RTP,
it is necessary to assign payload type numbers to them. In some it is necessary to assign payload type numbers to them. In some
cases, it is desirable to assign different payload type numbers to cases, it is desirable to assign different payload type numbers to
the same media capability when used in different potential the same media capability when used in different potential
configurations. One example is when configurations for AVP and SAVP configurations. One example is when configurations for AVP and SAVP
are offered: the offerer would like the answerer to use different are offered: the offerer would like the answerer to use different
skipping to change at page 27, line 16 skipping to change at page 25, line 18
o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753849 IN IP4 192.0.2.1
s= s=
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
a=creq:med-v0 a=creq:med-v0
m=audio 3456 RTP/AVP 0 18 100 m=audio 3456 RTP/AVP 0 18 100
a=rtpmap:100 telephone-events a=rtpmap:100 telephone-events
a=fmtp:100 0-11 a=fmtp:100 0-11
a=mcap:1 PCMU/8000 a=mcap:1 PCMU/8000
a=mcap:2 g729/8000 a=mcap:2 g729/8000
a=mcap:3 telephone-event/8000 a=mcap:3 telephone-events/8000
a=mfcap:3 0-15 a=mfcap:3 0-15
a=pcfg:1 m=2,3|1,3 pt=1:0,2:18,3:100 a=pcfg:1 m=2,3|1,3 pt=1:0,2:18,3:100
In this example, PCMU is media capability 1, G729 is media capability In this example, PCMU is media capability 1, G729 is media capability
2, and telephone-event is media capability 3. The a=pcfg: line 2, and telephone-event is media capability 3. The a=pcfg: line
specifies that the preferred configuration is G.729 with extended specifies that the preferred configuration is G.729 with extended
dtmf events, second is G.711 mu-law with extended dtmf events. dtmf events, second is G.711 mu-law with extended dtmf events.
Intermixing of G.729, G.711, and "commercial" dtmf events is least Intermixing of G.729, G.711, and "commercial" dtmf events is least
preferred (the base configuration provided by the "m=" line, which is preferred (the base configuration provided by the "m=" line, which is
always the least preferred configuration). The rtpmap and fmtp always the least preferred configuration). The rtpmap and fmtp
attributes of the base configuration are replaced by the mcap and attributes of the base configuration are replaced by the mcap and
mfcap attributes when invoked by the proposed configuration. mfcap attributes when invoked by the proposed configuration.
If the preferred configuration is selected, the SDP answer will look
like
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=csup:med-v0
m=audio 6543 RTP/AVP 18 100
a=rtpmap:100 telephone-events/8000
a=fmtp:100 0-15
a=acfg:1 m=2,3 pt=1:0,2:18,3:100
3.3.7. Substitution of Media Payload Type Numbers in Capability 3.3.7. Substitution of Media Payload Type Numbers in Capability
Attribute Parameters Attribute Parameters
In some cases, for example, when an RFC 2198 redundancy audio subtype In some cases, for example, when an RFC 2198 redundancy audio subtype
(RED) capability is defined in an mfcap attribute, the parameters to (RED) capability is defined in an mfcap attribute, the parameters to
an attribute may contain payload type numbers. Two options are an attribute may contain payload type numbers. Two options are
available for specifying such payload type numbers. They may be available for specifying such payload type numbers. They may be
expressed explicitly, in which case they are bound to actual payload expressed explicitly, in which case they are bound to actual payload
types by means of the payload type number parameter (pt=) in the types by means of the payload type number parameter (pt=) in the
appropriate potential or latent configuration. For example, the appropriate potential or latent configuration. For example, the
skipping to change at page 28, line 21 skipping to change at page 26, line 36
When an mfcap, mscap, or acap attribute is processed, its arguments When an mfcap, mscap, or acap attribute is processed, its arguments
will be scanned for sequences of the following form: "%" *DIGIT "%" will be scanned for sequences of the following form: "%" *DIGIT "%"
If found, the digit string is interpreted as a media capability If found, the digit string is interpreted as a media capability
number and the sequence is replaced by the payload type number number and the sequence is replaced by the payload type number
assigned to the media capability as specified by the pt= parameter in assigned to the media capability as specified by the pt= parameter in
the selected potential configuration. The sequence "%%" (null digit the selected potential configuration. The sequence "%%" (null digit
string) is replaced by a single percent sign and processing continues string) is replaced by a single percent sign and processing continues
with the next character, if any. with the next character, if any.
For example, the above sequence could have been written as For example, the above offer sequence could have been written as
m=audio 45678 RTP/AVP 0 m=audio 45678 RTP/AVP 0
a=rtp map:0 PCMU/8000 a=rtp map:0 PCMU/8000
a=mcap:1 PCMU/8000 a=mcap:1 PCMU/8000
a=mcap:2 RED/8000 a=mcap:2 RED/8000
a=mfcap:2 %1%/%1% a=mfcap:2 %1%/%1%
a=pcfg:1 m=2,1 pt=2:98,1:0 a=pcfg:1 m=2,1 pt=2:98,1:0
and the equivalent SDP is the same as above. This technique is and the equivalent SDP is the same as above. This technique is
especially useful for latent configurations, for which it may not especially useful for latent configurations, for which it may not
skipping to change at page 30, line 25 skipping to change at page 28, line 43
c=IN IP4 192.0.2.22 c=IN IP4 192.0.2.22
t=0 0 t=0 0
a=cusp:med-v0 a=cusp:med-v0
a=sescap:1 1,4 a=sescap:1 1,4
m=audio 23456 RTP/AVP 0 m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=acfg:1 a=acfg:1
m=video 41234 RTP/AVP 104 m=video 41234 RTP/AVP 104
a=rtpmap:100 H264/90000 a=rtpmap:100 H264/90000
a=fmtp:104 profile-level-id=42A01E; packetization-mode=2 a=fmtp:104 profile-level-id=42A01E; packetization-mode=2
a=acfg:4 a=acfg:4 m=1 a=1 pt=1:104
a=pcfg:3 a=pcfg:2
m=video 0 RTP/AVP 103 m=video 0 RTP/AVP 103
a=acfg:3 a=acfg:3
a=pcfg:3
m=application 0 TCP/BFCP * m=application 0 TCP/BFCP *
a=acfg:5 a=acfg:5
An endpoint that doesn't support Media capabilities negotiation, but An endpoint that doesn't support Media capabilities negotiation, but
does support H.263 video, would respond with one or two H.263 video does support H.263 video, would respond with one or two H.263 video
streams. In the latter case, the answerer may issue a second offer streams. In the latter case, the answerer may issue a second offer
to reconfigure the session to one audio and one video channel using to reconfigure the session to one audio and one video channel using
H.264 or H.263. H.264 or H.263.
Session capabilities MAY include latent capabilities as well. Here's Session capabilities MAY include latent capabilities as well. Here's
skipping to change at page 31, line 13 skipping to change at page 29, line 30
t=0 0 t=0 0
a=creq:med-v0 a=creq:med-v0
a=sescap:1 1,3,4,5 a=sescap:1 1,3,4,5
a=sescap:2 1,2 a=sescap:2 1,2
a=sescap:3 1 a=sescap:3 1
a=mcap:1 H263-1998/90000 a=mcap:1 H263-1998/90000
a=mfcap:1 CIF=4;QCIF=2;F=1;K=1 a=mfcap:1 CIF=4;QCIF=2;F=1;K=1
a=tcap:1 RTP/AVP TCP/BFCP a=tcap:1 RTP/AVP TCP/BFCP
a=acap:31 label:12 a=acap:31 label:12
a=acap:32 content:main a=acap:32 content:main
a=icap:3 primary video channel
a=lcfg:3 mt=video t=1 m=1 a=31,32 i=3 a=lcfg:3 mt=video t=1 m=1 a=31,32 i=3
a=acap:41 label:13 a=acap:41 label:13
a=acap:42 content:slides a=acap:42 content:slides
a=icap:4 secondary video channel (slides)
a=lcfg:4 mt=video t=1 m=1 a=41,42 i=4 a=lcfg:4 mt=video t=1 m=1 a=41,42 i=4
a=tcap:5 TCP/BFCP a=tcap:5 TCP/BFCP
a=mcap:2 *
a=acap:51 setup:passive a=acap:51 setup:passive
a=acap:52 connection:new a=acap:52 connection:new
a=acap:53 floorid:1 m-stream:12 13 a=acap:53 floorid:1 m-stream:12 13
a=acap:54 floor-control:s-only a=acap:54 floor-control:s-only
a=acap:55 confid:4321 a=acap:55 confid:4321
a=acap:56 userid:1234 a=acap:56 userid:1234
a=lcfg:5 mt=application t=2 a=lcfg:5 mt=application m=2 t=2
m=audio 54322 RTP/AVP 0 m=audio 54322 RTP/AVP 0
i= voice
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=label:11 a=label:11
a=pcfg:1 a=pcfg:1
m=video 22344 RTP/AVP 102 m=video 22344 RTP/AVP 102
i= default video
a=rtpmap:102 H264/90000 a=rtpmap:102 H264/90000
a=fmtp:102 profile-level-id=42A01E; packetization-mode=2 a=fmtp:102 profile-level-id=42A01E; packetization-mode=2
a=label:11 a=label:11
a=content:main a=content:main
a=pcfg:2 a=pcfg:2
In this example, the default offer, as seen by endpoints which do not In this example, the default offer, as seen by endpoints which do not
understand capabilities negotiation, proposes a PCMU audio stream and understand capabilities negotiation, proposes a PCMU audio stream and
an H.264 video stream. Note that the offered lcfg lines for the an H.264 video stream. Note that the offered lcfg lines for the
video streams don't carry pt= parameters because they're not needed video streams don't carry pt= parameters because they're not needed
(payload type numbers will be assigned in the offer/answer exchange (payload type numbers will be assigned in the offer/answer exchange
that establishes the streams. The lcfg line for the BFCP connection that establishes the streams). If the answerer supports Media
doesn't even use a media-configuration (m=) parameter because the CapNeg, and supports the most desired configuration, it would return
protocol is specified in the transport parameter. If the answerer the following SDP:
supports Media CapNeg, and supports the most desired configuration,
it would return the following SDP:
v=0 v=0
o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753849 IN IP4 192.0.2.1
s= s=
c=IN IP4 192.0.2.22 c=IN IP4 192.0.2.22
t=0 0 t=0 0
a=csup:med-v0 a=csup:med-v0
a=sescap:1 1,3,4,5 a=sescap:1 1,3,4,5
a=sescap:2 1,2 a=sescap:2 1,2
a=sescap:3 1 a=sescap:3 1
a=lcfg:3 mt=video t=1 m=1 a=31,32 i=3 a=lcfg:3 mt=video t=1 m=1 a=31,32
a=lcfg:4 mt=video t=1 m=1 a=41,42 i=4 a=lcfg:4 mt=video t=1 m=1 a=41,42
a=lcfg:5 mt=application t=2 a=lcfg:5 mt=application t=2
m=audio 23456 RTP/AVP 0 m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=acfg:1 a=acfg:1
m=video 0 RTP/AVP 102 m=video 0 RTP/AVP 102
a=pcfg:2 a=pcfg:2
This exchange supports immediate establishment of an audio stream for This exchange supports immediate establishment of an audio stream for
preliminary conversation. This exchange would presumably be followed preliminary conversation. This exchange would presumably be followed
at the appropriate time with a "reconfiguration" offer/answer at the appropriate time with a "reconfiguration" offer/answer
skipping to change at page 33, line 9 skipping to change at page 31, line 20
3.4. Offer/Answer Model Extensions 3.4. Offer/Answer Model Extensions
In this section, we define extensions to the offer/answer model In this section, we define extensions to the offer/answer model
defined in RFC3264 [RFC3264] and [SDPCapNeg] to allow for media defined in RFC3264 [RFC3264] and [SDPCapNeg] to allow for media
capabilities, bandwidth capabilities, and latent configurations to be capabilities, bandwidth capabilities, and latent configurations to be
used with the SDP Capability Negotiation framework. used with the SDP Capability Negotiation framework.
The [SDPCapNeg] provides a relatively compact means to offer the The [SDPCapNeg] provides a relatively compact means to offer the
equivalent of an ordered list of alternative media stream equivalent of an ordered list of alternative media stream
configurations (as would be described by separate m= lines and configurations (as would be described by separate m= lines and
associated attributes). The attributes acap, bcap, mscap, mfcap and associated attributes). The attributes acap, mscap, mfcap and mcap
mcap are designed to map somewhat straightforwardly into equivalent are designed to map somewhat straightforwardly into equivalent m=
m= lines and conventional attributes when invoked by a pcfg, lcfg, or lines and conventional attributes when invoked by a pcfg, lcfg, or
acfg attribute with appropriate parameters. The "a=pcfg:" lines, acfg attribute with appropriate parameters. The "a=pcfg:" lines,
along with the m= line itself, represent offered media along with the m= line itself, represent offered media
configurations. The "a=lcfg:" lines represent alternative configurations. The "a=lcfg:" lines represent alternative
capabilities for future use. capabilities for future use.
3.4.1. Generating the Initial Offer 3.4.1. Generating the Initial Offer
When an endpoint generates an initial offer and wants to use the When an endpoint generates an initial offer and wants to use the
functionality described in the current document, it should identify functionality described in the current document, it should identify
and define the codecs it can support via mcap, mfcap and mscap and define the codecs it can support via mcap, mfcap and mscap
skipping to change at page 33, line 50 skipping to change at page 32, line 17
When the answering party receives the offer and if it supports the When the answering party receives the offer and if it supports the
required capability negotiation extensions, it should select the required capability negotiation extensions, it should select the
most-preferred configuration it can support for each media stream, most-preferred configuration it can support for each media stream,
and build its answer accordingly. The configuration selected for and build its answer accordingly. The configuration selected for
each accepted media stream is placed into the answer as a media line each accepted media stream is placed into the answer as a media line
with associated parameters and attributes. If a proposed with associated parameters and attributes. If a proposed
configuration is chosen, the answer must include the supported configuration is chosen, the answer must include the supported
extension attribute and each media stream for which a proposed extension attribute and each media stream for which a proposed
configuration was chosen must contain an actual configuration (acfg) configuration was chosen must contain an actual configuration (acfg)
attribute to indicate just which pcfg attribute was used to build the attribute to indicate just which pcfg attribute was used to build the
answer. The answer should also include any latent configurations the answer. The answer should also include any potential or latent
answerer can support, especially any configurations compatible with configurations the answerer can support, especially any
other proposed or latent configurations received in the offer. The configurations compatible with other potential or latent
answerer should make note of those configurations it might wish to configurations received in the offer. The answerer should make note
offer in the future. of those configurations it might wish to offer in the future.
3.4.3. Offerer Processing of the Answer 3.4.3. Offerer Processing of the Answer
When the offeror receives the answer, it should make note of any When the offeror receives the answer, it should make note of any
capabilities and/or latent configurations for future use. The media capabilities and/or latent configurations for future use. The media
line(s) must be processed in the normal way to identify the media line(s) must be processed in the normal way to identify the media
stream(s) accepted by the answer, if any. The acfg attribute, if stream(s) accepted by the answer, if any. The acfg attribute, if
present, may be used to verify the proposed configuration used to present, may be used to verify the proposed configuration used to
form the answer, and to infer the lack of acceptability of higher- form the answer, and to infer the lack of acceptability of higher-
preference configurations that were not chosen. Note that the base preference configurations that were not chosen. Note that the base
skipping to change at page 34, line 30 skipping to change at page 32, line 45
3.4.4. Modifying the Session 3.4.4. Modifying the Session
If, at a later time, one of the parties wishes to modify the If, at a later time, one of the parties wishes to modify the
operating parameters of a session, e.g., by adding a new media operating parameters of a session, e.g., by adding a new media
stream, or by changing the properties used on an existing stream, it stream, or by changing the properties used on an existing stream, it
may do so via the mechanisms defined for offer/answer[RFC3264]. If may do so via the mechanisms defined for offer/answer[RFC3264]. If
the initiating party has remembered the codecs, potential the initiating party has remembered the codecs, potential
configurations, and latent configurations announced by the other configurations, and latent configurations announced by the other
party in the earlier negotiation, it may use this knowledge to party in the earlier negotiation, it may use this knowledge to
maximize the likelihood of a successful modification of the session. maximize the likelihood of a successful modification of the session.
Alternatively, it may perform a new capabilities exchange as part of Alternatively, the initiator may perform a new capabilities exchange
the reconfiguration. as part of the reconfiguration. In such a case, the new capabilities
will replace the previously-negotiated capabilities. This may be
"[Editors note: should a new offer/answer exchange replace all caps useful if conditions change on the endpoint.
from previous exchange(s)? This would permit an endpoint to remove
caps it can no longer support.]
4. Examples 4. Examples
In this section, we provide examples showing how to use the Media In this section, we provide examples showing how to use the Media
Capabilities with the SDP Capability Negotiation. Capabilities with the SDP Capability Negotiation.
4.1. Alternative Codecs 4.1. Alternative Codecs
This example provide a choice of one of six variations of the This example provide a choice of one of six variations of the
adaptive multirate codec. In this example, the default configuration adaptive multirate codec. In this example, the default configuration
skipping to change at page 35, line 45 skipping to change at page 33, line 45
17. a=mfcap:2,4,6 mode-set=0,3,5,6 17. a=mfcap:2,4,6 mode-set=0,3,5,6
18. pcfg:1 m=1 pt=1:96 18. pcfg:1 m=1 pt=1:96
19. pcfg:2 m=2 pt=2:97 19. pcfg:2 m=2 pt=2:97
20. pcfg:3 m=3 pt=3:98 20. pcfg:3 m=3 pt=3:98
21. pcfg:4 m=4 pt=4:99 21. pcfg:4 m=4 pt=4:99
22. pcfg:5 m=5 pt=5:100 22. pcfg:5 m=5 pt=5:100
23. pcfg:6 m=6 pt=6:101 23. pcfg:6 m=6 pt=6:101
In the above example, media capability 1 could have been excluded In the above example, media capability 1 could have been excluded
from the mcap declaration in line 10 and from the mfcap attributes in from the mcap declaration in line 10 and from the mfcap attributes in
lines 12, 14, and 16. The pcfg line 18 could then have been simply lines 12, 14, and 16. The pcfg on line 18 could then have been
"pcfg:1". simply "pcfg:1".
The next example offers a video stream with three options of H.264 The next example offers a video stream with three options of H.264
and 4 transports. It also includes an audio stream with different and 4 transports. It also includes an audio stream with different
audio qualities: four variations of AMR, or AC3. The offer looks audio qualities: four variations of AMR, or AC3. The offer looks
something like: something like:
v=0 v=0
o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753849 IN IP4 192.0.2.1
s=An SDP Media NEG example s=An SDP Media NEG example
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
skipping to change at page 36, line 33 skipping to change at page 34, line 33
a=candidate 56789 1 UDP 3 192.0.2.100 49000 relay raddr a=candidate 56789 1 UDP 3 192.0.2.100 49000 relay raddr
192.0.2.56 rport 49170 192.0.2.56 rport 49170
a=candidate 67890 2 UDP 3 192.0.2.100 49001 relay raddr a=candidate 67890 2 UDP 3 192.0.2.100 49001 relay raddr
192.0.2.56 rport 51540 192.0.2.56 rport 51540
b=AS:10000 b=AS:10000
b=TIAS:10000000 b=TIAS:10000000
b=RR:4000 b=RR:4000
b=RS:3000 b=RS:3000
a=rtpmap:100 H264/90000 a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42A01E; packetization-mode=2; a=fmtp:100 profile-level-id=42A01E; packetization-mode=2;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==; \
sprop-interleaving-depth=45; sprop-deint-buf-req=64000; sprop-interleaving-depth=45; sprop-deint-buf-req=64000;
sprop-init-buf-time=102478; deint-buf-cap=128000 sprop-init-buf-time=102478; deint-buf-cap=128000
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=mcap:1-3,7-9 H264/90000 a=mcap:1-3,7-9 H264/90000
a=mcap:4-6 rtx/90000 a=mcap:4-6 rtx/90000
a=mfcap:1-9 profile-level-id=42A01E a=mfcap:1-9 profile-level-id=42A01E
a=mfcap:1-9 aMljiA== a=mfcap:1-9 aMljiA==
a=mfcap:1,4,7 packetization-mode=0 a=mfcap:1,4,7 packetization-mode=0
a=mfcap:2,5,8 packetization-mode=1 a=mfcap:2,5,8 packetization-mode=1
a=mfcap:3,6,9 packetization-mode=2 a=mfcap:3,6,9 packetization-mode=2
a=mfcap:1-9 sprop-parameter-sets=Z0IACpZTBYmI a=mfcap:1-9 sprop-parameter-sets=Z0IACpZTBYmI
a=mfcap:1,7 sprop-interleaving-depth=45; sprop-deint-buf- a=mfcap:1,7 sprop-interleaving-depth=45; sprop-deint-buf-
req=64000; req=64000; \
sprop-init-buf-time=102478; deint-buf-cap=128000 sprop-init-buf-time=102478; deint-buf-cap=128000
a=mfcap:4 apt=100 a=mfcap:4 apt=100
a=mfcap:5 apt=99 a=mfcap:5 apt=99
a=mfcap:6 apt=98 a=mfcap:6 apt=98
a=mfcap:4-6 rtx-time=3000 a=mfcap:4-6 rtx-time=3000
a=mscap:1-6 rtcp-fb nack a=mscap:1-6 rtcp-fb nack
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 \
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
a=pcfg:1 t=1 m=1,4 a=1 pt=1:100,4:97 a=pcfg:1 t=1 m=1,4 a=1 pt=1:100,4:97
a=pcfg:2 t=1 m=2,5 a=1 pt=2:99,4:96 a=pcfg:2 t=1 m=2,5 a=1 pt=2:99,4:96
a=pcfg:3 t=1 m=3,6 a=1 pt=3:98,6:95 a=pcfg:3 t=1 m=3,6 a=1 pt=3:98,6:95
a=pcfg:4 t=2 m=7 a=1 pt=7:100 a=pcfg:4 t=2 m=7 a=1 pt=7:100
a=pcfg:5 t=2 m=8 a=1 pt=8:99 a=pcfg:5 t=2 m=8 a=1 pt=8:99
a=pcfg:6 t=2 m=9 a=1 pt=9:98 a=pcfg:6 t=2 m=9 a=1 pt=9:98
a=pcfg:7 t=3 m=1,3 pt=1:100,4:97 a=pcfg:7 t=3 m=1,3 pt=1:100,4:97
a=pcfg:8 t=3 m=2,4 pt=2:99,4:96 a=pcfg:8 t=3 m=2,4 pt=2:99,4:96
a=pcfg:9 t=3 m=3,6 pt=3:98,6:95 a=pcfg:9 t=3 m=3,6 pt=3:98,6:95
skipping to change at page 37, line 45 skipping to change at page 35, line 45
a=maxprate:120 a=maxprate:120
a=rtpmap:98 AMR-WB/16000 a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1; mode-change-capability=2 a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 AMR-WB/16000 a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2 a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2
a=rtpmap:100 AMR-WB/16000/2 a=rtpmap:100 AMR-WB/16000/2
a=fmtp:100 octet-align=1; interleaving=30 a=fmtp:100 octet-align=1; interleaving=30
a=rtpmap:101 AMR-WB+/72000/2 a=rtpmap:101 AMR-WB+/72000/2
a=fmtp:101 interleaving=50; int-delay=160000; a=fmtp:101 interleaving=50; int-delay=160000;
a=mcap:14 ac3/48000/6 a=mcap:14 ac3/48000/6
a=acap:23 crypto:1 AES_CM_128_HMAC_SHA1_80 a=acap:23 crypto:1 AES_CM_128_HMAC_SHA1_80 \
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
a=tcap:4 RTP/SAVP a=tcap:4 RTP/SAVP
a=pcfg:10 t=4 a=23 a=pcfg:10 t=4 a=23
a=pcfg:11 t=4 m=14 a=23 pt=14:102 a=pcfg:11 t=4 m=14 a=23 pt=14:102
This offer illustrates the advantage in compactness that arises if This offer illustrates the advantage in compactness that arises if
one can avoid deleting the base configuration attributes and one can avoid deleting the base configuration attributes and
recreating them in acap attributes for the potential configurations. recreating them in acap attributes for the potential configurations.
4.2. Alternative Combinations of Codecs (Session Configurations) 4.2. Alternative Combinations of Codecs (Session Configurations)
skipping to change at page 41, line 34 skipping to change at page 39, line 34
Appropriate Values: see Section 3.3.2 Appropriate Values: see Section 3.3.2
Attribute name: mscap Attribute name: mscap
Long form name: media-specific capability Long form name: media-specific capability
Type of attribute: session-level and media-level Type of attribute: session-level and media-level
Subject to charset: no Subject to charset: no
Purpose: associate media-specific attributes and Purpose: associate media-specific attributes and
parameters with media capabilities parameters with media capabilities
Appropriate Values: see Section 3.3.3 Appropriate Values: see Section 3.3.3
Attribute name: bcap
Long form name: bandwidth capability
Type of attribute: session-level or media-level
Subject to charset: no
Purpose: associate bandwidth limitations with potential
or latent configurations.
Appropriate Values: see Section 3.3.4
Attribute name: icap
Long form name: session information capability
Type of attribute: media-level
Subject to charset: no
Purpose: associate session information with potential
or latent configurations.
Appropriate Values: see Section 3.3.4
Attribute name: ccap
Long form name: connection information capability
Type of attribute: media-level
Subject to charset: no
Purpose: associate connection information with potential
or latent configurations.
Appropriate Values: see Section 3.3.4
Attribute name: kcap
Long form name: encryption key capability
Type of attribute: media-level
Subject to charset: no
Purpose: associate encryption key with potential
or latent configurations.
Appropriate Values: see Section 3.3.4
Attribute name: lcfg Attribute name: lcfg
Long form name: latent configuration Long form name: latent configuration
Type of attribute: session-level Type of attribute: session-level
Subject to charset: no Subject to charset: no
Purpose: to announce supportable media configurations Purpose: to announce supportable media configurations
without offering them for immediate use. without offering them for immediate use.
Appropriate Values: see Section 3.3.5 Appropriate Values: see Section 3.3.5
Attribute name: sescap Attribute name: sescap
Long form name: session capability Long form name: session capability
skipping to change at page 44, line 7 skipping to change at page 41, line 7
encoding and bandwidth parameters for every media stream selected. encoding and bandwidth parameters for every media stream selected.
Pending an understanding of capabilities negotiation, the middlebox Pending an understanding of capabilities negotiation, the middlebox
should examine the answer SDP to obtain the best picture of the media should examine the answer SDP to obtain the best picture of the media
streams being established. streams being established.
As always, middleboxes can best do their job if they fully understand As always, middleboxes can best do their job if they fully understand
media capabilities negotiation. media capabilities negotiation.
7. Changes from previous versions 7. Changes from previous versions
7.1. Changes from version 03 7.1. Changes from version 04
o The definitions for bcap, ccap, icap, and kcap attributes have
been removed, and are to be defined in another document.
o Corrected formatting of m= and p= configuration parameters to
conform to extension-config-list form defined in [SDPCapNeg]
o Reorganized definitions of new parameters to make them easier to
find in document.
o Added ability to renegotiate capabilities when modifying the
session (Section 3.4.4).
o Made various editorial changes, clarifications, and typo
corrections.
7.2. Changes from version 03
o A new session capability attribute (sescap) has been added to o A new session capability attribute (sescap) has been added to
permit specification of acceptable media stream combinations. permit specification of acceptable media stream combinations.
o Capability attribute definitions corresponding to the i, c, b, and o Capability attribute definitions corresponding to the i, c, b, and
k SDP line types have been added for completeness. k SDP line types have been added for completeness.
o Use of the pcfg: attribute in SDP answers has been included in o Use of the pcfg: attribute in SDP answers has been included in
order to conveniently return information in the answer about order to conveniently return information in the answer about
acceptable configurations in the media stream offer. acceptable configurations in the media stream offer.
skipping to change at page 44, line 40 skipping to change at page 42, line 8
o The description of the mscap attribute has been modified to make o The description of the mscap attribute has been modified to make
it clear that it should not be used to generate undefined SDP it clear that it should not be used to generate undefined SDP
attributes, or to "extend" existing attributes. attributes, or to "extend" existing attributes.
o <ms-parameters> are made optional in the mscap attribute o <ms-parameters> are made optional in the mscap attribute
definition. definition.
o "AMR" changed to "AMR-WB" in cases in which the sample rate is o "AMR" changed to "AMR-WB" in cases in which the sample rate is
16000. 16000.
7.2. Changes from version 02 7.3. Changes from version 02
This version contains several detail changes intended to simplify This version contains several detail changes intended to simplify
capability processing and mapping into conventional SDP media blocks. capability processing and mapping into conventional SDP media blocks.
o The "mcap" attribute is enhanced to include the role of the "ecap" o The "mcap" attribute is enhanced to include the role of the "ecap"
attribute; the latter is eliminated. attribute; the latter is eliminated.
o The "fcap" attribute has been renamed "mfcap". New replacement o The "fcap" attribute has been renamed "mfcap". New replacement
rules vis-a-vis fmtp attributes in the base media specification rules vis-a-vis fmtp attributes in the base media specification
have been added. have been added.
skipping to change at page 45, line 23 skipping to change at page 42, line 38
attribute. attribute.
o A new parameter, "mt=" is added to the latent configuration o A new parameter, "mt=" is added to the latent configuration
attribute (lcfg) to specify the media stream type (audio, video, attribute (lcfg) to specify the media stream type (audio, video,
etc.) when the lcfg is declared at the session level. etc.) when the lcfg is declared at the session level.
o The examples are expanded. o The examples are expanded.
o Numerous typos and misspellings have been corrected. o Numerous typos and misspellings have been corrected.
7.3. Changes from version 01 7.4. Changes from version 01
The documents adds a new attribute for specifying bandwidth The documents adds a new attribute for specifying bandwidth
capability and a parametr to list in the potential configuration. capability and a parametr to list in the potential configuration.
Other changes are to align the document with the terminolgy and Other changes are to align the document with the terminolgy and
attribute names from draft-ietf-mmusic-sdp-capability-negotiation-07. attribute names from draft-ietf-mmusic-sdp-capability-negotiation-07.
The document also clarifies some previous open issues. The document also clarifies some previous open issues.
7.4. Changes from version 00 7.5. Changes from version 00
The major changes include taking out the "mcap" and "cptmap" The major changes include taking out the "mcap" and "cptmap"
parameter. The mapping of payload type is now in the "pt" parameter parameter. The mapping of payload type is now in the "pt" parameter
of "pcfg". Media subtype need to explictly definesd in the "cmed" of "pcfg". Media subtype need to explictly definesd in the "cmed"
attribute if referenced in the "pcfg" attribute if referenced in the "pcfg"
8. Acknowledgements 8. Acknowledgements
This document is heavily influenced by the discussions and work done This document is heavily influenced by the discussions and work done
by the SDP Capability Negotiation Design team. The following people by the SDP Capability Negotiation Design team. The following people
skipping to change at page 47, line 24 skipping to change at page 44, line 24
June 2002. June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[SDPCapNeg] [SDPCapNeg]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-08 (work in draft-ietf-mmusic-sdp-capability-negotiation-09 (work in
progress), December 2007. progress), July 2008.
9.2. Informative References 9.2. Informative References
[I-D.garcia-mmusic-sdp-cs]
Garcia-Martin, M. and S. Veikkolainen, "Conventions for
the Use of the Session Description Protocol (SDP) for
Circuit-Switched Bearer Connections in the Public Switched
Telephone Network (PSTN)", draft-garcia-mmusic-sdp-cs-01
(work in progress), April 2008.
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format
for Binary Floor Control Protocol (BFCP) Streams", for Binary Floor Control Protocol (BFCP) Streams",
RFC 4583, November 2006. RFC 4583, November 2006.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"RTP Payload Format and File Storage Format for the "RTP Payload Format and File Storage Format for the
skipping to change at page 49, line 15 skipping to change at page 45, line 15
Authors' Addresses Authors' Addresses
Robert R Gilman Robert R Gilman
NDCI NDCI
Broomfield, CO 80020 Broomfield, CO 80020
USA USA
Email: bob_gilman@comcast.net Email: bob_gilman@comcast.net
Roni Even Roni Even
Polycom Gesher Erove Ltd
94 Derech Em Hamoshavot 14 David Hamelech
Petach Tikva 49130 Tel Aviv 64953
Israel Israel
Email: roni.even@polycom.co.il Email: ron.even.tlv@gmail.com
Flemming Andreasen Flemming Andreasen
Cisco Systems Cisco Systems
Edison, NJ Edison, NJ
USA USA
Email: fandreas@cisco.com Email: fandreas@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 94 change blocks. 
430 lines changed or deleted 306 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/