draft-ietf-mmusic-sdp-media-capabilities-10.txt   draft-ietf-mmusic-sdp-media-capabilities-11.txt 
MMUSIC R. Gilman MMUSIC R. Gilman
Internet-Draft Independent Internet-Draft Independent
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: January 13, 2011 Gesher Erove Ltd Expires: September 1, 2011 Gesher Erove Ltd
F. Andreasen F. Andreasen
Cisco Systems Cisco Systems
July 12, 2010 February 28, 2011
SDP media capabilities Negotiation SDP Media Mapabilities Negotiation
draft-ietf-mmusic-sdp-media-capabilities-10 draft-ietf-mmusic-sdp-media-capabilities-11
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.
extension is designed to map easily to existing and future SDP media
attributes, but not encodings or formatting.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 13, 2011. This Internet-Draft will expire on September 1, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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 Format Capability Attribute . . . . . . . . 13
3.3.2. The Media Format Parameter Capability Attribute . . . 14 3.3.2. The Media Format Parameter Capability Attribute . . . 15
3.3.3. The Media-Specific Capability Attribute . . . . . . . 17 3.3.3. The Media-Specific Capability Attribute . . . . . . . 17
3.3.4. New Configuration Parameters . . . . . . . . . . . . . 18 3.3.4. New Configuration Parameters . . . . . . . . . . . . . 19
3.3.5. The Latent Configuration Attribute . . . . . . . . . . 20 3.3.5. The Latent Configuration Attribute . . . . . . . . . . 20
3.3.6. Enhanced Potential Configuration Attribute . . . . . . 22 3.3.6. Enhanced Potential Configuration Attribute . . . . . . 23
3.3.7. Substitution of Media Payload Type Numbers in 3.3.7. Substitution of Media Payload Type Numbers in
Capability Attribute Parameters . . . . . . . . . . . 25 Capability Attribute Parameters . . . . . . . . . . . 26
3.3.8. The Session Capability Attribute . . . . . . . . . . . 26 3.3.8. The Session Capability Attribute . . . . . . . . . . . 27
3.4. Offer/Answer Model Extensions . . . . . . . . . . . . . . 30 3.4. Offer/Answer Model Extensions . . . . . . . . . . . . . . 31
3.4.1. Generating the Initial Offer . . . . . . . . . . . . . 31 3.4.1. Generating the Initial Offer . . . . . . . . . . . . . 31
3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 31 3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 32
3.4.3. Offerer Processing of the Answer . . . . . . . . . . . 31 3.4.3. Offerer Processing of the Answer . . . . . . . . . . . 32
3.4.4. Modifying the Session . . . . . . . . . . . . . . . . 32 3.4.4. Modifying the Session . . . . . . . . . . . . . . . . 32
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. Alternative Codecs . . . . . . . . . . . . . . . . . . . . 33 4.1. Alternative Codecs . . . . . . . . . . . . . . . . . . . . 33
4.2. Alternative Combinations of Codecs (Session 4.2. Alternative Combinations of Codecs (Session
Configurations) . . . . . . . . . . . . . . . . . . . . . 36 Configurations) . . . . . . . . . . . . . . . . . . . . . 36
4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 36 4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 36
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 39 5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 39
5.2. New SDP Option Tag . . . . . . . . . . . . . . . . . . . . 40 5.2. New SDP Option Tag . . . . . . . . . . . . . . . . . . . . 40
5.3. New SDP Capability Negotiation Parameters . . . . . . . . 40 5.3. New SDP Capability Negotiation Parameters . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41
7. Changes from previous versions . . . . . . . . . . . . . . . . 42 7. Changes from previous versions . . . . . . . . . . . . . . . . 42
7.1. Changes from version 09 . . . . . . . . . . . . . . . . . 42 7.1. Changes from version 10 . . . . . . . . . . . . . . . . . 42
7.2. Changes from version 08 . . . . . . . . . . . . . . . . . 42 7.2. Changes from version 09 . . . . . . . . . . . . . . . . . 42
7.3. Changes from version 04 . . . . . . . . . . . . . . . . . 42 7.3. Changes from version 08 . . . . . . . . . . . . . . . . . 42
7.4. Changes from version 03 . . . . . . . . . . . . . . . . . 42 7.4. Changes from version 04 . . . . . . . . . . . . . . . . . 43
7.5. Changes from version 02 . . . . . . . . . . . . . . . . . 43 7.5. Changes from version 03 . . . . . . . . . . . . . . . . . 43
7.6. Changes from version 01 . . . . . . . . . . . . . . . . . 44 7.6. Changes from version 02 . . . . . . . . . . . . . . . . . 44
7.7. Changes from version 00 . . . . . . . . . . . . . . . . . 44 7.7. Changes from version 01 . . . . . . . . . . . . . . . . . 44
7.8. Changes from version 00 . . . . . . . . . . . . . . . . . 44
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.1. Normative References . . . . . . . . . . . . . . . . . . . 46 9.1. Normative References . . . . . . . . . . . . . . . . . . . 46
9.2. Informative References . . . . . . . . . . . . . . . . . . 46 9.2. Informative References . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
Session Description Protocol (SDP) capability negotiation [SDPCapNeg] Session Description Protocol (SDP) capability negotiation [RFC5939]
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.
The [SDPCapNeg] document lists some of the issues with the current The [RFC5939] document lists some of the issues with the current SDP
SDP capability negotiation process. An additional real life case is capability negotiation process. An additional real life case is to
to be able to offer one media stream (e.g. audio) but list the 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 concurrently. actually offering it concurrently.
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 format parameters. This document also adds the and their associated format parameters. This document also adds the
ability to declare support for media streams, the use of which can be ability to declare support for media streams, the use of which can be
offered and negotiated later, and the ability to specify session offered and negotiated later, and the ability to specify session
configurations as combinations of media stream configurations. The 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
skipping to change at page 5, line 17 skipping to change at page 5, line 17
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119] and document are to be interpreted as described in RFC2119 [RFC2119] and
indicate requirement levels for compliant RTP implementations. indicate requirement levels for compliant RTP implementations.
"Base Attributes": Conventional SDP attributes appearing in the base "Base Attributes": Conventional SDP attributes appearing in the base
configuration of a media block. configuration of a media block.
"Base Configuration": The media configuration represented by a media "Base Configuration": The media configuration represented by a media
block exclusive of all the capability negotiation attributes defined block exclusive of all the capability negotiation attributes defined
in this document, the base capability document[SDPCapNeg], or any in this document, the base capability document[RFC5939], or any
future capability negotiation document. future capability negotiation document. In an offer SDP, the base
configuration corresponds to the actual configuration as defined in
[RFC5939].
"Conventional Attribute": Any SDP attribute other than those defined "Conventional Attribute": Any SDP attribute other than those defined
by the series of capability negotiation specifications. by the series of capability negotiation specifications.
"Conventional SDP": An SDP record devoid of capability negotiation "Conventional SDP": An SDP record devoid of capability negotiation
attributes. attributes.
"Media Capability": A media encoding, typically a media subtype such "Media Capability": A media encoding, typically a media subtype such
as PCMU, H263-1998, or T38. as PCMU, H263-1998, or T38.
3. SDP Media Capabilities 3. SDP Media Capabilities
The SDP capability negotiation [SDPCapNeg] discusses the use of any The SDP capability negotiation [RFC5939] discusses the use of any SDP
SDP [RFC4566] attribute (a=) under the attribute capability "acap". [RFC4566] attribute (a=) under the attribute capability "acap". The
The limitations of using acap for fmtp and rtpmap in a potential limitations of using acap for fmtp and rtpmap in a potential
configuration are described in [SDPCapNeg]; for example they can be configuration are described in [RFC5939]; for example they can be
used only at the media level since they are media level attributes. used only at the media level since they are media level attributes.
The [SDPCapNeg] does not provide a way to exchange capabilities prior The [RFC5939] does not provide a way to exchange media-level
to the actual offer of one or more media streams. This section capabilities prior to the actual offer of one or more media streams.
provides an overview of extensions providing an SDP Media Capability This section provides an overview of extensions providing an SDP
negotiation solution offering more robust capabilities negotiation. Media Capability negotiation solution offering more robust
This is followed by definitions of new SDP attributes for the capabilities negotiation. This is followed by definitions of new SDP
solution and its associated updated offer/answer procedures [RFC3264] attributes for the solution and its associated updated offer/answer
procedures [RFC3264]
3.1. Requirements 3.1. Requirements
The capability negotiation extensions described herein are described The capability negotiation extensions described herein are described
as follows. as follows.
REQ-01: Support the specification of alternative (combinations of) REQ-01: Support the specification of alternative (combinations of)
media formats (codecs) in a single media block. media formats (codecs) in a single media block.
REQ-02: Support the specification of alternative media format REQ-02: Support the specification of alternative media format
skipping to change at page 7, line 9 skipping to change at page 7, line 9
for future negotiation. for future negotiation.
REQ-07: Provide reasonable efficiency in the expression of REQ-07: Provide reasonable efficiency in the expression of
alternative media formats and/or format parameters, especially in alternative media formats and/or format parameters, especially in
those cases in which many combinations of options are offered. those cases in which many combinations of options are offered.
REQ-08: Retain the extensibility of the base capability negotiation REQ-08: Retain the extensibility of the base capability negotiation
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 media formats. 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.
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. treated in this document. They may be considered in the future.
Three such extensions are: Three such extensions are:
skipping to change at page 7, line 43 skipping to change at page 7, line 43
level SDP line types in the same manner as already done for the level SDP line types in the same manner as already done for the
attribute type, with the exception of the media line type itself. attribute type, with the exception of the media line type itself.
The media line type is handled in a special way to permit compact The media line type is handled in a special way to permit compact
expression of media coding/format options. The lines types are expression of media coding/format options. The lines types are
bandwidth ("b="), information ("i="), connection data ("c="), and, bandwidth ("b="), information ("i="), connection data ("c="), and,
possibly, the deprecated encryption key ("k="). 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, acfg, and
extending the base attributes from [SDPCapNeg], and a use of the pcfg the new lcfg attributes extending the base attributes from [RFC5939],
attribute to return capability information in the SDP answer. and a use of the pcfg 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.
o A new media attribute ("a=mcap") defines media capabilities in the o A new media attribute ("a=mcap") defines media capabilities in the
form of a subtype (e.g. "PCMU"), and its encoding parameters form of a media subtype (e.g. "PCMU"), and its encoding
(e.g. "/8000/2"). Each resulting media format type/subtype parameters (e.g. "/8000/2"). Each resulting media format type/
capability has an associated handle called a media capability subtype capability has an associated handle called a media
number. The encoding parameters are as specified for the rtpmap capability number. The encoding parameters are as specified for
attribute defined in [RFC4566] the rtpmap attribute defined in [RFC4566], without the payload
type number part.
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 defined in
[RFC4585].
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 latent configurations for video even
though no video is currently offered. If both parties indicate though no video is currently offered. If the peer indicates
support for one or more latent configurations, the corresponding support for one or more of offered latent configurations, the
media stream(s) may be added via a new offer/answer exchange. corresponding 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 and their configurations
and/or latent configurations. as a list of potential and/or latent configurations.
New parameters are defined for the potential configuration (pcfg), New parameters are defined for the potential configuration (pcfg),
latent configuration (lcfg), and accepted configuration (acfg) latent configuration (lcfg), and accepted configuration (acfg)
attributes to associate the new attributes with particular attributes to associate the new attributes with particular
configurations. configurations.
o A new parameter type ("m=") is added to the potential o A new parameter type ("m=") is added to the potential
configuration ("a=pcfg:") attribute and the actual configuration configuration ("a=pcfg:") attribute and the actual configuration
("a=acfg:") attribute defined in [SDPCapNeg], and to the new ("a=acfg:") attribute defined in [RFC5939], and to the new latent
latent configuration ("a=lcfg:") attribute. This permits configuration ("a=lcfg:") attribute. This permits specification
specification of media capabilities (including their associated of media capabilities (including their associated parameters) and
parameters) and combinations thereof for the configuration. For combinations thereof for the configuration. For example, the
example, the "a=pcfg:" line might specify PCMU and telephone "a=pcfg:" line might specify PCMU and telephone events [RFC4733]
events or G.729B and telephone events as acceptable or G.729B and telephone events as acceptable configurations. The
configurations. The "a=acfg:" line in the answer would specify "a=acfg:" line in the answer would specify the configuration
the accepted choice. chosen.
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 type 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.
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).
o Replacement rules are defined for the conventional SDP equivalents o Replacement rules are defined for the conventional SDP equivalents
of the mfcap, mscap, and bcap capability attributes. This reduces of the mfcap and mscap capability attributes. This reduces the
the necessity to use the deletion qualifier in the pcfg a= necessity to use the deletion qualifier in the pcfg a= parameter
parameter in order to ignore rtpmap, fmtp, and certain other in order to ignore rtpmap, fmtp, and certain other attributes in
attributes in the base configuration. the base configuration.
o An argument concatenation rule is defined for mfcap attributes o An argument concatenation rule is defined for mfcap attributes
which refer to the same media capability number. This makes it which refer to the same media capability number. This makes it
convenient to combine format options concisely by associating convenient to combine format options concisely by associating
multiple mfcap lines with multiple media capabilities. multiple mfcap lines with multiple media capabilities.
This document extends the base protocol extensions to the offer/ This document extends the base protocol extensions to the offer/
answer model that allow for capabilities and potential configurations answer model that allow for capabilities and potential configurations
to be included in an offer. Media capabilities constitute to be included in an offer. Media capabilities constitute
capabilities that can be used in potential and latent configurations. capabilities that can be used in potential and latent configurations.
skipping to change at page 9, line 46 skipping to change at page 10, line 5
configuration(s) included in the "m=" line(s) and associated configuration(s) included in the "m=" line(s) and associated
parameters, latent configurations merely inform the other side of parameters, latent configurations merely inform the other side of
possible configurations supported by the entity. Those latent possible configurations supported by the entity. Those latent
configurations may be used to guide subsequent offer/answer configurations may be used to guide subsequent offer/answer
exchanges, but they are not part of the current offer/answer exchanges, but they are not part of the current offer/answer
exchange. exchange.
The mechanism is illustrated by the offer/answer exchange below, The mechanism is illustrated by the offer/answer exchange below,
where Alice sends an offer to Bob: where Alice sends an offer to Bob:
Alice Bob Alice Bob
| (1) Offer (SRTP and RTP) | | (1) Offer (SRTP and RTP) |
|--------------------------------->| |--------------------------------->|
| | | |
| (2) Answer (RTP) | | (2) Answer (RTP) |
|<---------------------------------| |<---------------------------------|
| | | |
Alice's offer includes RTP and SRTP as alternatives. RTP is the Alice's offer includes RTP and SRTP as alternatives. RTP is the
default, but SRTP is the preferred one (long lines are folded to fit default, but SRTP is the preferred one (long lines are folded to fit
the margins): the margins):
skipping to change at page 10, line 35 skipping to change at page 10, line 41
a=mfcap:1 annexb=no a=mfcap:1 annexb=no
a=mfcap:4 annexb=yes a=mfcap:4 annexb=yes
a=mfcap:5 0-11 a=mfcap:5 0-11
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 \ a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 \
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 m=4,5|1,5 t=1 a=1 pt=1:100,4:101,5:102 a=pcfg:1 m=4,5|1,5 t=1 a=1 pt=1:100,4:101,5:102
a=pcfg:2 m=2 t=1 a=1 pt=2:103 a=pcfg:2 m=2 t=1 a=1 pt=2:103
a=pcfg:3 m=4 t=2 pt=4:18 a=pcfg:3 m=4 t=2 pt=4:18
The required base and extensions are provided by the "a=creq" The required base and extensions are provided by the "a=creq"
attribute defined in [SDPCapNeg], with the option tag "med-v0", which attribute defined in [RFC5939], with the option tag "med-v0", which
indicates that the extension framework defined here, must be indicates that the extension framework defined here, must be
supported. The Base level support is implied since it is required supported. The Base level support is implied since it is required
for the extensions. for the extensions.
The "m=" line indicates that Alice is offering to use plain RTP with The "m=" line indicates that Alice is offering to use plain RTP with
PCMU or G.729B. The media line implicitly defines the default PCMU or G.729B. The media line implicitly defines the default
transport protocol (RTP/AVP in this case) and the default actual transport protocol (RTP/AVP in this case) and the default actual
configuration. configuration.
The "a=tcap:1" line, specified in the base protocol, defines The "a=tcap:1" line, specified in the base protocol, defines
transport protocol capabilities, in this case Secure RTP (SAVP transport protocol capabilities, in this case Secure RTP (SAVP
profile) as the first option and RTP (AVP profile) as the second profile) as the first option and RTP (AVP profile) as the second
option. option.
The "a=mcap:1,4" line defines two G.729 media format capabilities, The "a=mcap:1,4" line defines two G.729 media format capabilities,
numbered 1 and 4, and their encoding rate. The capabilities are of numbered 1 and 4, and their encoding rate. The capabilities are of
media type "audio" and subtype G729. Note that the media subtype is media type "audio" and subtype G729. Note that the media subtype is
explicitly specified here, rather than RTP payload type numbers. In explicitly specified here, rather than RTP payload type numbers.
this example, two G.729 subtype capabilities are defined. This This permits the assignment of payload type numbers in the media
permits the declaration of two sets of formatting parameters for stream configuration specification. In this example, two G.729
G.729. subtype capabilities are defined. This permits the declaration of
two sets of formatting parameters for G.729.
The "a=mcap:2" line defines a G.711 mu-law capability, numbered 2. The "a=mcap:2" line defines a G.711 mu-law capability, numbered 2.
The "a=mcap:5" line defines an audio telephone-event capability, The "a=mcap:5" line defines an audio telephone-event capability,
numbered 5. numbered 5.
The "a=mfcap:1" line specifies the fmtp formatting parameters for The "a=mfcap:1" line specifies the fmtp formatting parameters for
capability 1 (offerer will not accept G.729 Annex B packets). capability 1 (offerer will not accept G.729 Annex B packets).
The "a=mfcap:4" line specifies the fmtp formatting parameters for The "a=mfcap:4" line specifies the fmtp formatting parameters for
skipping to change at page 11, line 30 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, attribute capabilities and specified payload
Three explicit alternatives are provided; the lowest-numbered one is type number mappings. Three explicit alternatives are provided; the
the preferred one. The "a=pcfg:1 ..." line specifies media lowest-numbered one is the preferred one. The "a=pcfg:1 ..." line
capabilities 4 and 5, i.e., G.729B and DTMF, or media capability 1 specifies media capabilities 4 and 5, i.e., G.729B and DTMF, or media
and 5, i.e., G.729 and DTMF. Furthermore, it specifies transport capability 1 and 5, i.e., G.729 and DTMF. Furthermore, it specifies
protocol capability 1 (i.e. the RTP/SAVP profile - secure RTP), and transport protocol capability 1 (i.e. the RTP/SAVP profile - secure
the attribute capability 1, i.e. the crypto attribute provided. RTP), and the attribute capability 1, i.e. the crypto attribute
Lastly, it specifies a payload type number mapping for media provided. Lastly, it specifies a payload type number mapping for
capabilities 1, 4, and 5, thereby permitting the offerer to media capabilities 1, 4, and 5, thereby permitting the offerer to
distinguish between encrypted media and unencrypted media received distinguish between encrypted media and unencrypted media received
prior to receipt of the answer. prior to receipt of the answer.
Use of unique payload type numbers is not required; codecs such as Use of unique payload type numbers is not required; codecs such as
AMR-WB [RFC4867] have the potential for so many combinations of AMR-WB [RFC4867] have the potential for so many combinations of
options that it may be impractical to define unique payload type options that it may be impractical to define unique payload type
numbers for all supported combinations. If unique payload type numbers for all supported combinations. If unique payload type
numbers cannot be specified, then the offerer will be obliged to wait numbers cannot be specified, then the offerer will be obliged to wait
for the SDP answer before rendering received media. For SRTP using for the SDP answer before rendering received media. For SRTP using
SDES inline keying [RFC4568], the offerer will still need to receive SDES inline keying [RFC4568], the offerer will still need to receive
skipping to change at page 12, line 29 skipping to change at page 12, line 35
v=0 v=0
o=- 24351 621814 IN IP4 192.0.2.2 o=- 24351 621814 IN IP4 192.0.2.2
s= s=
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
t=0 0 t=0 0
a=csup:med-v0 a=csup:med-v0
m=audio 4567 RTP/AVP 18 m=audio 4567 RTP/AVP 18
a=rtpmap:18 G729/8000 a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes a=fmtp:18 annexb=yes
a=acfg:3 m=4 pt=4:18 a=acfg:3 m=4 t=2 pt=4:18
Bob includes the "a=csup" and "a=acfg" attributes in the answer to Bob includes the "a=csup" and "a=acfg" attributes in the answer to
inform Alice that he can support the med-v0 level of capability inform Alice that he can support the med-v0 level of capability
negotiations. Note that in this particular example, the answerer negotiations. Note that in this particular example, the answerer
supported the capability extensions defined here, however had he not, supported the capability extensions defined here, however had he not,
he would simply have processed the offer based on the offered PCMU he would simply have processed the offer based on the offered PCMU
and G.729 codecs under the RTP/AVP profile only. Consequently, the and G.729 codecs under the RTP/AVP profile only. Consequently, the
answer would have omitted the "a=csup" attribute line and chosen one answer would have omitted the "a=csup" attribute line and chosen one
or both of the PCMU and G.729 codecs instead. The answer carries the or both of the PCMU and G.729 codecs instead. The answer carries the
accepted configuration in the m line along with corresponding rtpmap accepted configuration in the m line along with corresponding rtpmap
skipping to change at page 13, line 10 skipping to change at page 13, line 16
In this section, we present the new attributes associated with In this section, we present the new attributes associated with
indicating the media capabilities for use by the SDP Capability indicating the media capabilities for use by the SDP Capability
negotiation. The approach taken is to keep things similar to the negotiation. The approach taken is to keep things similar to the
existing media capabilities defined by the existing media existing media capabilities defined by the existing media
descriptions ("m=" lines) and the associated "rtpmap" and "fmtp" descriptions ("m=" lines) and the associated "rtpmap" and "fmtp"
attributes. We use media subtypes and "media capability numbers" attributes. We use media subtypes and "media capability numbers"
instead of payload type numbers to link the relevant media capability instead of payload type numbers to link the relevant media capability
parameters. This permits the capabilities to be defined at the parameters. This permits the capabilities to be defined at the
session level and be used for multiple streams, if desired. Payload session level and be used for multiple streams, if desired. Payload
types are then specified at the media level (see Section types are then specified at the media level (see Section 3.3.4.2).
Section 3.3.4.2).
A media capability merely indicates possible support for the media A media capability merely indicates possible support for the media
type and media format(s) in question. In order to actually use a type and media format(s) in question. In order to actually use a
media capability in an offer/answer exchange, it must be referenced media capability in an offer/answer exchange, it must be referenced
in a potential configuration. in a potential configuration.
Media capabilities can be provided at the session-level and/or the Media capabilities can be provided at the session-level and/or the
media-level. Media capabilities provided at the session level may be media-level. Media capabilities provided at the session level may be
referenced in an lcfg attribute at the session level, or by any pcfg referenced in any pcfg or lcfg attribute at the media level
attribute at the media level (consistent with the media type), (consistent with the media type), whereas media capabilities provided
whereas media capabilities provided at the media level may be at the media level may be referenced only by the pcfg or lcfg
referenced by a pcfg or lcfg attribute within that media stream only. attribute within that media stream only. In either case, the scope
In either case, the scope of the <med-cap-num> is the entire session of the <med-cap-num> is the entire session description. This enables
description. This enables each media capability to be uniquely each media capability to be uniquely referenced across the entire
referenced across the entire session description (e.g. in a potential session description (e.g. in a potential configuration).
configuration).
3.3.1. The Media Encoding Capability Attribute 3.3.1. The Media Format Capability Attribute
Media subtypes can be expressed as media encoding capabilities by use Media subtypes can be expressed as media format capabilities by use
of the "a=mcap" attribute, which is formatted as follows: of the "a=mcap" attribute, which is formatted as follows:
a=mcap:<media cap num list> <encoding name>/<clock rate> a=mcap:<media-cap-num-list> <encoding-name>/<clock-rate>
[/<encoding parms>] [/<encoding-parms>]
where <med cap num list> is a (list of) media capability number(s) where <media-cap-num-list> is a (list of) media capability number(s)
used to number a media format capability, the <encoding name> is the used to number a media format capability, the <encoding name> is the
media subtype e.g. H263-1998 or PCMU, <clock rate> is the encoding media subtype e.g. H263-1998 or PCMU, <clock rate> is the encoding
rate, and <encoding parms> are the media encoding parameters for the rate, and <encoding parms> are the media encoding parameters for the
media subtype;. All media format capabilities in the list are media subtype;. All media format capabilities in the list are
assigned to the same media type/subtype. Each occurrence of the mcap assigned to the same media type/subtype. Each occurrence of the mcap
attribute MUST use unique values in its <med cap num list>; the media attribute MUST use unique values in its <media-cap-num-list>; the
capability numbers must be unique across the entire SDP session. In media capability numbers must be unique across the entire SDP
short, the mcap attribute defines media capabilities and associates session. In short, the mcap attribute defines media capabilities and
them with a media capability number in the same manner as the rtpmap associates them with a media capability number in the same manner as
attribute defines them and associates them with a payload type the rtpmap attribute defines them and associates them with a payload
number. type number. Additionally, the mcap attribute allows multiple
capability numbers to be defined for the media format in question.
This permits the media format to be associated with different media
parameters in different configurations.
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 encoding-name "/" clock-rate 1*WSP encoding-name "/" clock-rate
["/" encoding-parms] ["/" encoding-parms]
media-cap-num-list = media-cap-num *[COMMA media-cap-num] media-cap-num-list = media-cap-num-element
media-cap-num = 1*DIGIT *["," media-cap-num-element]
encoding-name = token ; Media Subtype name(PCMU, G729, etc.) media-cap-num-element = media-cap-num
clock-rate = 1*DIGIT / media-cap-num-range
media-cap-num-range = media-cap-num "-" media-cap-num
media-cap-num = 1*10(DIGIT)
encoding-name = token ; defined in RFC4566
clock-rate = 1*10(DIGIT)
encoding-parms = token encoding-parms = token
The encoding-name, clock-rate and encoding-params are as defined to The encoding-name, clock-rate and encoding-params are as defined to
appear in an rtpmap attribute for each media type/subtype. Thus, it appear in an rtpmap attribute for each media type/subtype. Thus, it
is easy to convert an mcap attribute line into one or more rtpmap is easy to convert an mcap attribute line into one or more rtpmap
attribute lines, once a payload type number is assigned to a media- attribute lines, once a payload type number is assigned to a media-
cap-num (see section Section 3.3.5). cap-num (see Section 3.3.5).
The "mcap" attribute can be provided at the session-level and/or the The "mcap" attribute can be provided at the session-level and/or the
media-level. There can be more than one mcap attribute at the media-level. There can be more than one mcap attribute at the
session or media level. Each media-cap-num must be unique within the session or media level. Each media-cap-num must be unique within the
entire SDP record; it is used to identify that media capability in entire SDP record; it is used to identify that media capability in
potential, latent and actual configurations, and in other attribute potential, latent and actual configurations, and in other attribute
lines as explained below. When used in a potential, latent or actual lines as explained below. When used in a potential, latent or actual
configuration it is, in effect, a media level attribute regardless if configuration it is, in effect, a media level attribute regardless if
it is specified at the session or media level. In other words, the it is specified at the session or media level. In other words, the
media capability applies to the specific media description associated media capability applies to the specific media description associated
with the configuration which invokes it. with the configuration which invokes it.
For example: For example:
v=0 v=0
a=mcap:1 L16/8000/1 a=mcap:1 L16/8000/1
a=mcap:2 L16/16000/2 a=mcap:2 L16/16000/2
a=mcap:3,4 H263-1998/90000 a=mcap:3,4 H263-1998/90000
m=audio 54320 RTP/AVP 0 m=audio 54320 RTP/AVP 0
a=pcfg:1 m=1|2, pt=1:99,2:98 a=pcfg:1 m=1|2, pt=1:99,2:98
m=video 66544 RTP/AVP 100 m=video 66544 RTP/AVP 100
a=rtpmap:100 H264/90000 a=rtpmap:100 H264/90000
a=pcfg:10 m=3 pt=3:101 a=pcfg:10 m=3 pt=3:101
3.3.2. The Media Format Parameter Capability Attribute 3.3.2. The Media Format Parameter Capability Attribute
This attribute is used to associate media-specific format parameters This attribute is used to associate media format specific format
with one or more media capabilities. The form of the attribute is: parameters with one or more media capabilities. The form of the
attribute is:
a=mfcap:<media-caps> <list of parameters> a=mfcap:<media-caps> <list of parameters>
where <media-caps> permits the parameter(s) to be associated with one where <media-caps> permits the list of parameters to be associated
or more media capabilities and the format parameters are specific to with one or more media capabilities and the format parameters are
the type of codec. The mfcap lines map to a single traditional SDP specific to the type of media format. The mfcap lines map to a
fmtp attribute line (one for each entry in <media-caps>) of the form single traditional SDP fmtp attribute line (one for each entry in
<media-caps>) of the form
a=fmtp:<fmt> <list of parameters> a=fmtp:<fmt> <list of parameters>
where <fmt> is the media format description defined in RFC 4566 where <fmt> is the media format description defined in RFC 4566
[RFC4566], as appropriate for the particular media stream. The mfcap [RFC4566], as appropriate for the particular media stream. The mfcap
attribute MUST be used to encode attributes for media capabilities, attribute MUST be used to encode attributes for media capabilities,
which would conventionally appear in an fmtp attribute. which would conventionally appear in an fmtp attribute. The existing
acap attribute MUST NOT be used to encode fmtp attributes.
The mfcap attribute adheres to RFC 4566[RFC4566] attribute production
rules with
media-format-capability = "a=mfcap:"<media-caps>
1*WSP <fmt-specific-param-list>
media-caps = "*" ; wildcard: all media caps
/ <media-cap-num-list> ; defined in Section 3.3.1 The mfcap attribute adheres to [RFC4566] attribute production rules
with
fmt-specific-param-list = text ; defined in RFC 4566 media-format-capability = "a=mfcap:" media-cap-num-list 1*WSP
fmt-specific-param-list
fmt-specific-param-list = text ; defined in RFC4566
3.3.2.1. Media Format Parameter Concatenation Rule 3.3.2.1. Media Format Parameter Concatenation Rule
The appearance of media subtypes with a large number of formatting The appearance of media subtypes with a large number of formatting
options (e.g., AMR-WB [RFC4867]) coupled with the restriction that options (e.g., AMR-WB [RFC4867]) coupled with the restriction that
only a single fmtp attribute can appear per media format, suggests only a single fmtp attribute can appear per media format, suggests
that it is useful to create a combining rule for mfcap parameters that it is useful to create a combining rule for mfcap parameters
which are associated with the same media capability number. which are associated with the same media capability number.
Therefore, different mfcap lines MAY include the same media-cap-num Therefore, different mfcap lines MAY include the same media-cap-num
in their media-cap-num-list. When a particular media capability is in their media-cap-num-list. When a particular media capability is
skipping to change at page 16, line 4 skipping to change at page 16, line 11
compact method to specify multiple combinations of format parameters compact method to specify multiple combinations of format parameters
when using codecs with multiple format options. Note that order- when using codecs with multiple format options. Note that order-
dependent parameters MAY be placed in a single mfcap line to avoid dependent parameters MAY be placed in a single mfcap line to avoid
possible problems with line rearrangement by a middlebox. possible problems with line rearrangement by a middlebox.
Format parameters are not parsed by SDP; their content is specific to Format parameters are not parsed by SDP; their content is specific to
the media type/subtype. When format parameters for a specific media the media type/subtype. When format parameters for a specific media
capability are combined from multiple a=mfcap lines which reference capability are combined from multiple a=mfcap lines which reference
that media capability, the format-specific parameters are that media capability, the format-specific parameters are
concatenated together and separated by "; " for construction of the concatenated together and separated by "; " for construction of the
corresponding format attribute (a=fmtp): corresponding format attribute (a=fmtp). The resulting format
attribute will look something like the following:
a=fmtp:<fmt> 1*WSP <fmt-specific-param-list> *(";" 1*WSP
<fmt-specfic-param-list>) ; a=fmtp:<fmt> <fmt-specific-param-list1>;
<fmt-specific-param-list2>;
...
where <fmt> depends on the transport protocol in the manner defined where <fmt> depends on the transport protocol in the manner defined
in RFC4566. SDP cannot assess the legality of the resulting in RFC4566. SDP cannot assess the legality of the resulting
parameter list in the "a=fmtp" line; the user must take care to parameter list in the "a=fmtp" line; the user must take care to
insure that legal parameter lists are generated. ensure that legal parameter lists are generated.
The "mfcap" attribute can be provided at the session-level and the The "mfcap" attribute can be provided at the session-level and the
media-level. There can be more than one mfcap attribute at the media-level. There can be more than one mfcap attribute at the
session or media level. The unique media-cap-num is used to session or media level. The unique media-cap-num is used to
associate the parameters with a media capability. associate the parameters with a media capability.
As a simple example, a G.729 capability is, by default, considered to As a simple example, a G.729 capability is, by default, considered to
support comfort noise as defined by Annex B. Capabilities for G.729 support comfort noise as defined by Annex B. Capabilities for G.729
with and without comfort noise support may thus be defined by: with and without comfort noise support may thus be defined by:
a=mcap:1,2 audio G729/8000 a=mcap:1,2 audio G729/8000
a=mfcap:2 annexb:no a=mfcap:2 annexb:no
Media format capability 1 supports G.729 with Annex B, whereas media Media format capability 1 supports G.729 with Annex B, whereas media
format capability 2 supports G.729 without Annex B. format capability 2 supports G.729 without Annex B.
Example for H.263 video: Example for H.263 video:
a=mcap:1 video H263-1998/90000 a=mcap:1 video H263-1998/90000
a=mcap:2 video H263-2000/90000 a=mcap:2 video H263-2000/90000
a=mfcap:1 CIF=4;QCIF=2;F=1;K=1 a=mfcap:1 CIF=4;QCIF=2;F=1;K=1
a=mfcap:2 profile=2;level=2.2 a=mfcap:2 profile=2;level=2.2
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; \ a=fmtp:98 mode-change-capability=1; \
max-red=220; mode-set=0,2,4,7 max-red=220; mode-set=0,2,4,7
and AMR codec #4 with payload type number 99,depicted by the and AMR codec #4 with payload type number 99,depicted by the
potential configuration: potential configuration:
skipping to change at page 17, line 43 skipping to change at page 18, line 6
be associated with media capability numbers via a new media-specific be associated with media capability numbers via a new media-specific
attribute, mscap, of the following form: attribute, mscap, of the following form:
a=mscap:<media caps> <att field> <att value> a=mscap:<media caps> <att field> <att value>
Where <media caps> is a (list of) media capability number(s), <att Where <media caps> is a (list of) media capability number(s), <att
field> is the attribute name, and <att value> is the value field for field> is the attribute name, and <att value> is the value field for
the named attribute. In ABNF, we have: the named attribute. In ABNF, we have:
media-specific-capability = "a=mscap:" media-specific-capability = "a=mscap:"
media-caps ; defined in 3. media-caps ; defined in 3.3.2
1*WSP att-field ; from RFC4566 1*WSP att-field ; from RFC4566
1*WSP att-value ; from RFC4566. 1*WSP att-value ; from RFC4566
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> <att value> ; <fmt> defined in [RFC4566] a=<att field>":"<fmt> <att value> ; <fmt> defined in [RFC4566]
A resulting attribute that is not a legal SDP attribute as specified A resulting attribute that is not a legal SDP attribute as specified
by RFC4566 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,
skipping to change at page 18, line 45 skipping to change at page 19, line 9
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. New Configuration Parameters 3.3.4. New Configuration Parameters
Along with the new attributes for media capabilities, new extension Along with the new attributes for media capabilities, new extension
parameters are defined for use in the potential configuration, the parameters are defined for use in the potential configuration, the
actual configuration, and the new latent configuration defined in actual configuration, and/or the new latent configuration defined in
Section Section 3.3.5. Section 3.3.5.
3.3.4.1. The Media Configuration Parameter (+m=) 3.3.4.1. The Media Configuration Parameter (m=)
The media configuration parameter is used to specify the media The media configuration parameter is used to specify the media
encoding(s) and related parameters for a configuration. Adhering to encoding(s) and related parameters for a potential, actual, or latent
the ABNF for extension-config-list in [SDPCapNeg] with configuration. Adhering to the ABNF for extension-config-list in
[RFC5939] with
ext-cap-name = "m" ext-cap-name = "m"
ext-cap-list = media-cap-num-list ext-cap-list = media-cap-num-list
[*(BAR media-cap-num-list)] [*(BAR media-cap-num-list)]
we have we have
media-config-list = ["+"]"m=" media-cap-num-list media-config-list = ["+"]"m=" media-cap-num-list
[*(BAR media-cap-num-list)] [*(BAR media-cap-num-list)]
; BAR is defined in [SDPCapNeg] ; BAR is defined in RFC5939
media-cap-num-list = media-cap-num *("," media-cap-num) ; media-cap-num-list is defined above
media-cap-num = 1*DIGIT ; defined in [RFC5234]
Alternative media configurations are separated by a vertical bar Alternative media configurations are separated by a vertical bar
("|"). The alternatives are ordered by preference, most-preferred ("|"). The alternatives are ordered by preference, most-preferred
first. When media capabilities are not included in a potential first. When media capabilities are not included in a potential
configuration at the media level, the media type and media format configuration at the media level, the media type and media format
from the associated "m=" line will be used. Note that the media from the associated "m=" line will be used. The use of the plus sign
configuration parameter MAY be specified with the plus sign ("+") to ("+") is described in RFC5939.
force the entire attribute line to be ignored if the parameter is not
recognized by the interpreter, although this is unnecessary if the
med-v0 level of support is specified in a creq attribute.
3.3.4.2. The Payload Type Number Mapping Parameter (pt=) 3.3.4.2. The Payload Type Number Mapping Parameter (pt=)
We define the payload type number mapping parameter, payload-number- The payload type number mapping parameter is used to specify the
config-list, in accordance with the extension-config-list format payload type number to be associated with each media type in a
defined in [SDPCapNeg]. In ABNF: potential, actual, or latent configuration. We define the payload
type number mapping parameter, payload-number-config-list, in
accordance with the extension-config-list format defined in
[RFC5939]. In ABNF:
payload-number-config-list = ["+"]"pt=" media-map-list payload-number-config-list = ["+"]"pt=" media-map-list
media-map-list = media-map *["," media-map] media-map-list = media-map *["," media-map]
media-map = media-cap-num ":" payload-type-number media-map = media-cap-num ":" payload-type-number
; media-cap-num is defined in section 3.3.1 ; media-cap-num is defined in 3.3.1
payload-type-number = 1*DIGIT / "*" ; RTP payload type number payload-type-number = 1*3(DIGIT) ; RTP payload type number
/ "*" ; dummy
The example in the section Section 3.3.7 shows how the parameters The example in Section 3.3.7 shows how the parameters from the mcap
from the mcap line are mapped to payload type numbers from the pcfg line are mapped to payload type numbers from the pcfg "pt" parameter.
"pt" parameter. The plus sign ("+") SHOULD be included in the The use of the plus sign ("+") is desribed in RFC5939.
parameter specification, if med-v0 level of support is not required,
because the entire attribute line in which it appears SHOULD be
ignored if the parameter is not recognized by the interpreter.
The "*" value is used in cases such as BFCP [RFC4583] in which the The "*" value for payload-type-number is used in cases such as BFCP
fmt list in the m-line is ignored. [RFC4583] in which the fmt list in the m-line is ignored.
A latent configuration represents a future capability, hence the pt= A latent configuration represents a future capability, hence the pt=
parameter is not directly meaningful in the lcfg attribute because no parameter is not directly meaningful in the lcfg attribute because no
actual media session is being offered or accepted; it is permitted in actual media session is being offered or accepted; it is permitted in
order to tie any payload type number parameters within attributes to order to tie any payload type number parameters within attributes to
the proper media format. A primary example is the case of format the proper media format. A primary example is the case of format
parameters for the RED payload, which are payload type numbers. parameters for the RED payload, which are payload type numbers.
Specific payload type numbers used in a latent configuration may be Specific payload type numbers used in a latent configuration may be
interpreted as suggestions to be used in any future offer based on interpreted as suggestions to be used in any future offer based on
the latent configuration, but they are not binding; the offerer the latent configuration, but they are not binding; the offerer
and/or answerer may use any payload type numbers each deems and/or answerer may use any payload type numbers each deems
appropriate. The use of explicit payload type numbers for latent appropriate. The use of explicit payload type numbers for latent
configurations can be avoided by use of the parameter substitution configurations can be avoided by use of the parameter substitution
rule of section Section 3.3.7 . Future extensions are also rule of Section 3.3.7 . Future extensions are also permitted.
permitted.
3.3.4.3. The Media Type Parameter 3.3.4.3. The Media Type Parameter
When a latent configuration is specified (always at the session When a latent configuration is specified (always at the session
level), indicating the ability to support an additional media stream, level), indicating the ability to support an additional media stream,
it is necessary to specify the media type (audio, video, etc.) as it is necessary to specify the media type (audio, video, etc.) as
well as the format and transport type. The media type parameter is well as the format and transport type. The media type parameter is
defined as defined in ABNF as
media-type = "mt=" 1*WSP media; media defined in RFC4566. media-type = ["+"] "mt=" media; media defined in RFC4566
At present, the media-type parameter is used only in the latent At present, the media-type parameter is used only in the latent
configuration attribute. The media format(s) and transport type(s) configuration attribute, and the use of the "+" prefix to specify
are specified using the media configuration parameter ("+m=") defined that the entire attribute line is to be ignored if the mt= parameter
above, and the transport parameter ("t=") defined in [SDPCapNeg], is not understood, is unnecessary. However, if the media-type
respectively. parameter is later added to an existing capability attribute such as
pcfg, then the "+" would be useful. The media format(s) and
transport type(s) are specified using the media configuration
parameter ("+m=") defined above, and the transport parameter ("t=")
defined in [RFC5939], respectively.
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 one or more offerer can supply its video capabilities by offering one or more
skipping to change at page 21, line 8 skipping to change at page 21, line 20
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. This choice has been made of its capabilities in the initial offer. This choice has been made
in order to keep the size of the answer more compact by not requiring in order to keep the size of the answer more compact by not requiring
acap, mcap, tcap, etc. lines in the answer. acap, mcap, tcap, etc. lines in the answer.
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 latent configuration
transport protocol(s) (t=) MUST be specified since there is no attribute combines the properties of a media line and a potential
corresponding m-line for defaults. In most cases, the media configuration. The media type (mt=) and the transport protocol(s)
configuration (m=) parameter must be present as well (see section (t=) MUST be specified since the latent configuration is independent
Section 4 for examples). The lcfg attribute is a session level of any media line present. In most cases, the media configuration
attribute, and all capability attributes referenced by lcfg attribute (m=) parameter MUST be present as well (see Section 4 for examples).
parameters must appear at the session level in the SDP record. The lcfg attribute is a media level attribute and, like a media line,
it ends the session level of the session description if it appears
before any media line.
Each media line in an SDP description represents an offered
simultaneous media stream, whereas each latent configuration
represents an additional stream which may be negotiated in a future
offer/answer exchange. Session capability attributes may be used to
determine whether a latent configuration may be used to form an offer
for an additional simultaneous stream or to reconfigure an existing
stream in a subsequent offer/answer exchange.
The latent configuration attribute is of the form: The latent configuration attribute is of the form:
a=lcfg:<config-number> <latent-cfg-list> a=lcfg:<config-number> <latent-cfg-list>
which adheres to the RFC4566 "attribute" production with att-field which adheres to the [RFC4566] "attribute" production with att-field
and att-value defined as: and att-value defined as:
att-field = "lcfg" att-field = "lcfg"
att-value = config-number 1*WSP lcfg-config-list att-value = config-number 1*WSP lcfg-cfg-list
config-number = 1*10(DIGIT) ; defined in [RFC5234] config-number = 1*10(DIGIT) ; defined in RFC5234
lcfg-config-list = media-type lcfg-cfg-list = media-type 1*WSP pot-cfg-list
1*WSP pot-config ; as defined in RFC5939
; as defined in [SDPCapNeg]
; and extended herein ; and extended herein
The media-type (mt=) parameter identifies the media type (audio, The media-type (mt=) parameter identifies the media type (audio,
video, etc.) to be associated with the latent media stream, and must video, etc.) to be associated with the latent media stream, and MUST
be present. The pot-config must contain a transport-protocol-config- be present. The pot-cfg-list MUST contain a transport-protocol-
list (t=) parameter and a media-config-list (m=) parameter. The pot- config-list (t=) parameter and a media-config-list (m=) parameter.
config list MUST NOT contain more than one instance of each type of The pot-cfg-list MUST NOT contain more than one instance of each type
parameter list. As specified in [SDPCapNeg], the use of the "+" of parameter list. As specified in [RFC5939], the use of the "+"
prefix with a parameter indicates that the entire configuration must prefix with a parameter indicates that the entire configuration MUST
be ignored if the parameter is not understood; otherwise, the be ignored if the parameter is not understood; otherwise, the
parameter itself may be ignored. parameter itself may be ignored.
Media stream payload numbers are not assigned by a latent Media stream payload numbers are not assigned by a latent
configuration. Assignment will take place if and when the configuration. Assignment will take place if and when the
corresponding stream is actually offered in a later exchange. The corresponding stream is actually offered via an m-line in a later
payload-number-config-list is included as a parameter to the lcfg exchange. The payload-number-config-list is included as a parameter
attribute in case it is necessary to tie payload numbers in attribute to the lcfg attribute in case it is necessary to tie payload numbers
capabilities to specific media capabilities. in attribute capabilities to specific media capabilities.
Each latent configuration MUST be specified at the session level; it If an lcfg attribute invokes an acap attribute that appears at the
represents an additional media stream to those in the media block(s} session level, then that attribute will be expected to appear at the
of the offer or answer. If an acap: attribute is declared at the session level of a subsequent offer when and if a corresponding media
session level for use in an lcfg line, it SHOULD NOT be used in a stream is offered. Otherwise, acap attributes which appear at the
pcfg line at the media level unless it is to become a session-level media level represent media-level attributes. Note, however, that
attribute in the answer if that potential configuration becomes the mcap, mfcap, mscap, tcap attributes may appear at the session level
actual configuration; mcap, mfcap, mscap, tcap attributes may appear because they always result in media-level attributes or m-line
at the session level because they always result in media-level parameters.
attributes or m-line parameters.
The configuration numbers for latent configurations do not imply a The configuration numbers for latent configurations do not imply a
preference; the offerer will imply a preference when actually preference; the offerer will imply a preference when actually
offering potential configurations derived from latent configurations offering potential configurations derived from latent configurations
negotiated earlier. Note however that the offerer of latent negotiated earlier. Note however that the offerer of latent
configurations MAY specify preferences for combinations of potential configurations MAY specify preferences for combinations of potential
and latent configurations by use of the sescap attribute defined in and latent configurations by use of the sescap attribute defined in
section Section 3.3.8. In order to permit intermixing of latent and Section 3.3.8. For example, if an SDP offer contains, say, an audio
stream with pcfg:1, and two latent video configurations, lcfg:2, and
lcfg:3, then a session with one audio stream and one video stream
could be specified by including "a=sescap:1 1,2|3". One audio stream
and two video streams could be specified by including "a=sescap:2
1,2,3" in the offer. In order to permit combinations of latent and
potential configurations in session capabilities, latent potential configurations in session capabilities, latent
configuration numbers MUST be different from those used for potential configuration numbers MUST be different from those used for potential
configurations. configurations. This restriction is especially important if the
offerer does not require cmed-v0 capability and the recipient of the
offer doesn't aupport it. If the lcfg attribute is not recognized,
the capability attributes intended to be associated with it may be
confused with those associated with a potential configuration of some
other media stream.
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
The present work requires new extensions (parameters) for the pcfg: The present work requires new extensions (parameters) for the pcfg:
attribute defined in the base protocol [SDPCapNeg] The parameters and attribute defined in the base protocol [RFC5939] The parameters and
their definitions are "borrowed" from the definitions provided for their definitions are "borrowed" from the definitions provided for
the latent configuration attribute in section Section 3.3.5. The the latent configuration attribute in Section 3.3.5. The expanded
expanded ABNF definition of the pcfg attribute is ABNF definition of the pcfg attribute is
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 / def in [SDPCapNeg] pot-config = / attribute-config-list / def in [RFC5939]
transport-protocol-config-list / ;defined in [SDPCapNeg] transport-protocol-config-list / ;defined in [RFC5939]
extension-config-list / ;[SDPCapNeg] extension-config-list / ;[RFC5939]
media-config-list / ; Section 3.3.4.1 media-config-list / ; Section 3.3.4.1
payload-number-config-list / ; Section 3.3.4.2 payload-number-config-list ; Section 3.3.4.2
Except for the extension-config-list, the pot-cfg-list MUST NOT Except for the extension-config-list, the pot-cfg-list MUST NOT
contain more than one instance of each parameter list. contain more than one instance of each parameter list.
3.3.6.1. Returning Capabilities in the Answer 3.3.6.1. Returning Capabilities in the Answer
Potential and/or latent configuration attributes may be returned Potential and/or latent configuration attributes may be returned
within the media block(s) of an answer SDP to indicate the ability of within an answer SDP to indicate the ability of the answerer to to
the answerer to to support alternative configurations of the support alternative configurations of the corresponding stream(s).
corresponding stream(s). For example, an offer may include multiple For example, an offer may include multiple potential configurations
potential configurations for a media stream and/or latent for a media stream and/or latent configurations for additional
configurations for additional streams; the corresponding answer will streams; the corresponding answer will indicate (via an acfg
indicate (via an acfg attribute) which configuration is accepted, but attribute) the configuration accepted and used to construct the base
it MAY also contain potential and/or latent configuration attributes, configuration for each active media stream in the reply, but the
with parameters, to indicate which other offered configurations would reply MAY also contain potential and/or latent configuration
be acceptable. This information is useful if it becomes desirable to attributes, with parameters, to indicate which other offered
reconfigure a media stream, e.g., to reduce resource consumption. configurations would be acceptable. This information is useful if it
becomes desirable to reconfigure a media stream, e.g., to reduce
resource consumption.
When potential and/or latent configurations are returned in an When potential and/or latent configurations are returned in an
answer, all numbering MUST refer to the configuration and capability answer, all numbering MUST refer to the configuration and capability
attribute numbering of the offer. The referenced capability attribute numbering of the offer. The offered capability attributes
attributes MUST NOT be returned in the answer. The parameter values need not be returned in the answer. The answer MAY include
of any returned pcfg or lcfg attributes MUST be a subset of those additional capability attributes and/or configuratons (with distinct
included in the offered configurations; values may be omitted only if numbering). The parameter values of any returned pcfg or lcfg
they were indicated as alternative sets, or optional, in the original attributes MUST be a subset of those included in the offered
offer. The parameter set indicated in the returned acfg attribute configurations or those added by the answerer; values may be omitted
need not be repeated in a returned pcfg attribute. The answerer may only if they were indicated as alternative sets, or optional, in the
return more than one pcfg attribute with the same configuration original offer. The parameter set indicated in the returned acfg
number if it is necessary to describe selected combinations of attribute need not be repeated in a returned pcfg attribute. The
optional or alternative parameters. answerer may return more than one pcfg attribute with the same
configuration number if it is necessary to describe selected
combinations of optional or alternative parameters.
Similarly, one or more session capability attributes (a=sescap) may Similarly, one or more session capability attributes (a=sescap) may
be returned to indicate which of the offered session capabilities is/ be returned to indicate which of the offered session capabilities is/
are supportable by the answerer (see section Section 3.3.8.) are supportable by the answerer (see Section 3.3.8.)
Note that the answerer MUST NOT return capabilities beyond those Note that, although the answerer MAY return capabilities beyond those
included by the offerer. For this reason, it seems advisable for the included by the offerer, these capabilities MUST NOT be used to form
offerer to include most, if not all, potential and latent any base level media description in the answer. For this reason, it
configurations in the initial offer. Additional capabilities MAY be seems advisable for the offerer to include most, if not all,
announced later by renegotiating the session in a second offer/answer potential and latent configurations it can support in the initial
exchange. offer. Either party MAY later announce additional capabilities 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 24, line 18 skipping to change at page 25, line 5
be used if the number of potential configurations exceeds the number be used if the number of potential configurations exceeds the number
of possible payload type numbers. of possible payload type numbers.
3.3.6.3. Processing of Media-Format-Related Conventional Attributes for 3.3.6.3. Processing of Media-Format-Related Conventional Attributes for
Potential Configurations Potential Configurations
In cases in which media capabilities negotiation is employed, SDP In cases in which media capabilities negotiation is employed, SDP
records are likely to contain conventional attributes such as rtpmap, records are likely to contain conventional attributes such as rtpmap,
fmtp, and other media-format-related lines, as well as capability fmtp, and other media-format-related lines, as well as capability
attributes such as mcap, mfcap, and mscap which map into those attributes such as mcap, mfcap, and mscap which map into those
conventional attributes. conventional attributes when invoked by a potential configuration.
In such cases, it MAY be appropriate to employ the a delete-
When one or more media capabilities (a=mcap) are invoked in a attributes option in the attribute configuration list parameter in
potential configuration via m= arguments, each capability is order to avoid the generation of conflicting fmtp attributes for a
associated with a payload type number by default or by a payload type particular configuration. Any media-specific attributes in the media
number argument (pt=). Special processing MUST be invoked on block which refer to payload type numbers not used by the potential
conventional attributes associated with that payload type number. If configuration MUST be ignored.
the media capability is associated with one or more mfcap attributes,
then any corresponding conventional fmtp attribute in the media block
MUST be ignored for that configuration. If no mfcap attributes are
specified, then the fmtp attribute line within the media block with
the matching payload type number, if any, will apply. Conventional
fmtp attributes with payload type numbers not referenced in the
configuration MUST also be ignored. Similarly, any other
conventional media-specific attributes (e.g., rtcp-fb) in the media
block with payload type number matching a mscap attribute will apply
unless there is an applicable mscap attribute for the same attribute
type (e.g., rtcp-fb), in which case all base level attributes of the
same type and payload type number will be ignored. Any media-
specific attributes in the media block which refer to payload type
numbers not used by the potential configuration will be ignored.
These rules are intended to avoid the need to duplicate attributes
and use the a=-m: form of invoking attributes in a potential
configuration just to replace an rtpmap or fmtp attribute.
For example: For example:
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.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-events/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 a=-m pt=1:0,2:18,3:100
a=pcfg:2
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:1 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, and
Intermixing of G.729, G.711, and "commercial" dtmf events is least the base media-level attributes are to be deleted. Intermixing of
preferred (the base configuration provided by the "m=" line, which G.729, G.711, and "commercial" dtmf events is least preferred (the
is, by default, the least preferred configuration). The rtpmap and base configuration provided by the "m=" line, which is, by default,
fmtp attributes of the base configuration are replaced by the mcap the least preferred configuration). The rtpmap and fmtp attributes
and mfcap attributes when invoked by the proposed configuration. of the base configuration are replaced by the mcap and mfcap
attributes when invoked by the proposed configuration.
If the preferred configuration is selected, the SDP answer will look If the preferred configuration is selected, the SDP answer will look
like like
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.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
a=csup:med-v0 a=csup:med-v0
m=audio 6543 RTP/AVP 18 100 m=audio 6543 RTP/AVP 18 100
a=rtpmap:100 telephone-events/8000 a=rtpmap:100 telephone-events/8000
a=fmtp:100 0-15 a=fmtp:100 0-15
a=pcfg:1 m=2,3|1,3 a=-m pt=1:0,2:18,3:100
a=pcfg:2
a=acfg:1 m=2,3 pt=1:0,2:18,3:100 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
skipping to change at page 26, line 16 skipping to change at page 26, line 38
a=pcfg:1 m=2,1 pt=2:98,1:0 a=pcfg:1 m=2,1 pt=2:98,1:0
The potential configuration is then equivalent to The potential configuration is then equivalent to
m=audio 45678 RTP/AVP 98 0 m=audio 45678 RTP/AVP 98 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:98 RED/8000 a=rtpmap:98 RED/8000
a=fmtp:98 0/0 a=fmtp:98 0/0
A more general mechanism is provided via the parameter substitution A more general mechanism is provided via the parameter substitution
rule: rule. When an mfcap, mscap, or acap attribute is processed, its
arguments will be scanned for a payload type number escape sequences
of the following form (in ABNF):
When an mfcap, mscap, or acap attribute is processed, its arguments ptn-esc = "%m=" media-cap-num "%" ; defined in 3.3.1
will be scanned for sequences of the following form: "%" *DIGIT "%"
If found, the digit string is interpreted as a media capability
number and the sequence is replaced by the payload type number
assigned to the media capability as specified by the pt= parameter in
the selected potential configuration. The sequence "%%" (null digit
string) is replaced by a single percent sign and processing continues
with the next character, if any.
For example, the above offer sequence could have been written as If the sequence is found, the sequence is replaced by the payload
type number assigned to the media capability number, as specified by
the pt= parameter in the selected potential configuration. The
sequence "%%" (null digit string) is replaced by a single percent
sign and processing continues with the next character, if any.
For example, the above offer sequence could have been written as
m=audio 45678 RTP/AVP 0 m=audio 45678 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap: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 %m=1%/%m=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.
useful for configurations in which the same mfcap attribute might be
used for different encodings, such as redundant G.711 or redundant
G.729 encodings.
3.3.8. The Session Capability Attribute 3.3.8. The Session Capability Attribute
The session capability attribute provides a means for the offerer The session capability attribute provides a means for the offerer
and/or the answerer to specify combinations of specific media stream and/or the answerer to specify combinations of specific media stream
configurations which it is willing and able to support. Each session configurations which it is willing and able to support. Each session
capability in an offer is expressed as a list of potential and/or capability in an offer or answer MAY be expressed as a list of
latent configurations; in an answer, the session capabilities refer required potential configurations, and MAY include a list of optional
to actual and/or latent media configurations. The session capability potential and/or latent configurations.
attribute is described by:
The choices of session capabilities may be based on processing load,
total bandwidth, or any other criteria of importance to the
communicating parties. If the answerer supports media capabilities
negotiation, and session configurations are offered, it MUST accept
one of the offered configurations, or it MUST refuse the session.
Therefore, if the offer includes any session capabilities, it SHOULD
include all the session capabilities the offerer is willing to
support.
The session capability attribute is described by:
"a=sescap:" <session num> <list of configs> "a=sescap:" <session num> <list of configs>
which corresponds to the standard attribute definition with which corresponds to the standard attribute definition with
att-field = "sescap" att-field = "sescap"
att-value = session-num 1*WSP list-of-configs att-value = session-num 1*WSP list-of-configs
session-num = 1*DIGIT ; defined in RFC5234 [1*WSP optional-configs]
list-of-configs = <alt-config> *["," <alt-config>] session-num = 1*DIGIT ; defined in RFC5234
alt-config = config-number *["|" config-number] list-of-configs = alt-config *["," alt-config]
; config-number defined in [SDPCapNeg] optional-configs = "[" list-of-configs "]"
alt-config = config-number *["|" config-number]
; config-number defined in RFC5939
The session-num identifies the session; a lower-number session is The session-num identifies the session; a lower-number session is
preferred over a higher-numbered session. Each alt-config list preferred over a higher-numbered session. Each alt-config list
specifies alternative media configurations within the session; specifies alternative media configurations within the session;
preference is based on config-num as specified in [SDPCapNeg]. Note preference is based on config-num as specified in [RFC5939]. Note
that the session preference order, when present, takes precedence that the session preference order, when present, takes precedence
over the individual media stream configuration preference order. over the individual media stream configuration preference order.
Use of session capability attributes requires that configuration Use of session capability attributes requires that configuration
numbers assigned to potential and latent configurations be unique numbers assigned to potential and latent configurations MUST be
across the entire session; [SDPCapNeg] requires only that pcfg unique across the entire session; [RFC5939] requires only that pcfg
configuration numbers be unique within a media description. configuration numbers be unique within a media description.
As an example, consider an endpoint that is capable of supporting an As an example, consider an endpoint that is capable of supporting an
audio stream with either one H.264 video stream or two H.263 video audio stream with either one H.264 video stream or two H.263 video
streams with a floor control stream. The SDP offer might look like streams with a floor control stream. The SDP offer might look like
the following: the following:
v=0 v=0
o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753849 IN IP4 192.0.2.1
s= s=
skipping to change at page 28, line 47 skipping to change at page 29, line 31
a=acfg:3 a=acfg: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 can include latent capabilities as well. Here's
a similar example in which the offerer wishes to initially establish a similar example in which the offerer wishes to initially establish
an audio stream, and prefers to later establish two video streams an audio stream, and prefers to later establish two video streams
with chair control. If the answerer doesn't understand Media CapNeg, with chair control. If the answerer doesn't understand Media CapNeg,
or cannot support the dual video streams or flow control, then it may or cannot support the dual video streams or flow control, then it may
support a single H.264 video stream. Note that establishment of the support a single H.264 video stream. Note that establishment of the
most favored configuration will require two offer/answer exchanges. most favored configuration will require two offer/answer exchanges.
h
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.1 c=IN IP4 192.0.2.1
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:32 content:main
a=lcfg:3 mt=video t=1 m=1 a=31,32 i=3
a=acap:41 label:13
a=acap:42 content:slides
a=lcfg:4 mt=video t=1 m=1 a=41,42 i=4
a=tcap:5 TCP/BFCP
a=mcap:2 *
a=acap:51 setup:passive
a=acap:52 connection:new
a=acap:53 floorid:1 m-stream:12 13
a=acap:54 floor-control:s-only
a=acap:55 confid:4321
a=acap:56 userid:1234
a=lcfg:5 mt=application m=2 t=2
m=audio 54322 RTP/AVP 0 m=audio 54322 RTP/AVP 0
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
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
a=lcfg:3 mt=video t=1 m=1 a=31,32 i=3
a=acap:31 label:12
a=acap:32 content:main
a=lcfg:4 mt=video t=1 m=1 a=41,42 i=4
a=acap:41 label:13
a=acap:42 content:slides
a=lcfg:5 mt=application m=51 t=51
a=tcap:51 TCP/BFCP
a=mcap:51 *
a=acap:51 setup:passive
a=acap:52 connection:new
a=acap:53 floorid:1 m-stream:12 13
a=acap:54 floor-control:s-only
a=acap:55 confid:4321
a=acap:56 userid:1234
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). If the answerer supports Media that establishes the streams). Note also that the three mcap, mfcap,
CapNeg, and supports the most desired configuration, it would return and tcap attributes used by lcfg:3 and lcfg:4 are included at the
the following SDP: session level so they may be referenced by both latent
configurations. As per Section 3.3, the media attributes generated
from the mcap, mfcap, and tcap attributes are always media-level
attributes. If the answerer 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
a=lcfg:4 mt=video t=1 m=1 a=41,42
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
a=lcfg:3 mt=video t=1 m=1 a=31,32
a=lcfg:4 mt=video t=1 m=1 a=41,42
a=lcfg:5 mt=application t=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
exchange to add the video and chair control streams. exchange to add the video and chair control streams.
The choices of session capabilities may be based on processing load,
total bandwidth, or any other criteria of importance to the
communicating parties. If the answerer supports media capabilities
negotiation, and session configurations are offered, it must accept
one of the offered configurations, or it must refuse the session.
Therefore, if the offer includes any session capabilities, it should
include all the session capabilities the offerer is willing to
support.
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 [RFC5939] 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 [RFC5939] 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, mscap, mfcap and mcap associated attributes). The attributes acap, mscap, mfcap and mcap
are designed to map somewhat straightforwardly into equivalent m= are designed to map somewhat straightforwardly into equivalent 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, along acfg attribute with appropriate parameters. The a=pcfg: lines, along
with the m= line itself, represent offered media configurations. The with the m= line itself, represent offered media configurations. The
a=lcfg: lines represent alternative capabilities for future use. a=lcfg: lines represent alternative capabilities for future use.
3.4.1. Generating the Initial Offer 3.4.1. Generating the Initial Offer
skipping to change at page 32, line 7 skipping to change at page 32, line 35
3.4.3. Offerer Processing of the Answer 3.4.3. Offerer Processing of the Answer
When the offerer receives the answer, it should make note of any When the offerer 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
specification [SDPCapNeg] requires the answerer to choose the highest specification [RFC5939] requires the answerer to choose the highest
preference configuration it can support, subject to local policies. preference configuration it can support, subject to local policies.
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
skipping to change at page 33, line 18 skipping to change at page 33, line 18
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
as specified by the media line is the same as the most preferred as specified by the media line is the same as the most preferred
configuration. Each configuration uses a different payload type configuration. Each configuration uses a different payload type
number so the offerer can interpret early media. number so the offerer can interpret early media.
1. v=0 v=0
2. o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753849 IN IP4 192.0.2.1
3. s= s=
4. c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
5. t=0 0 t=0 0
6. a=creq:med-v0 a=creq:med-v0
7. m=audio 54322 RTP/AVP 96 m=audio 54322 RTP/AVP 96
8. rtpmap:96 AMR-WB/16000/1 rtpmap:96 AMR-WB/16000/1
9. a=fmtp:96 mode-change-capability=1; max-red=220; \ a=fmtp:96 mode-change-capability=1; max-red=220; \
mode-set=0,2,4,7 mode-set=0,2,4,7
10. a=mcap:1,3,5 audio AMR-WB/16000/1 a=mcap:1,3,5 audio AMR-WB/16000/1
11. a=mcap:2,4,6 audio AMR/8000/1 a=mcap:2,4,6 audio AMR/8000/1
12. a=mfcap:1,2,3,4 mode-change-capability=1 a=mfcap:1,2,3,4 mode-change-capability=1
13. a=mfcap:5,6 mode-change-capability=2 a=mfcap:5,6 mode-change-capability=2
14. a=mfcap:1,2,3,5 max-red=220 a=mfcap:1,2,3,5 max-red=220
15. a=mfcap:3,4,5,6 octet-align=1 a=mfcap:3,4,5,6 octet-align=1
16. a=mfcap:1,3,5 mode-set=0,2,4,7 a=mfcap:1,3,5 mode-set=0,2,4,7
17. a=mfcap:2,4,6 mode-set=0,3,5,6 a=mfcap:2,4,6 mode-set=0,3,5,6
18. a=pcfg:1 m=1 pt=1:96 a=pcfg:1 m=1 pt=1:96
19. a=pcfg:2 m=2 pt=2:97 a=pcfg:2 m=2 pt=2:97
20. a=pcfg:3 m=3 pt=3:98 a=pcfg:3 m=3 pt=3:98
21. a=pcfg:4 m=4 pt=4:99 a=pcfg:4 m=4 pt=4:99
22. a=pcfg:5 m=5 pt=5:100 a=pcfg:5 m=5 pt=5:100
23. a=pcfg:6 m=6 pt=6:101 a=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 first mcap declaration and from the corresponding mfcap
lines 12, 14, and 16. The pcfg on line 18 could then have been attributes, and the pcfg:1 attribute line could have been simply
simply "pcfg:1". "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 37, line 5 skipping to change at page 37, line 5
4.3. Latent Media Streams 4.3. Latent Media Streams
Consider a case in which the offerer can support either G.711 mu-law, Consider a case in which the offerer can support either G.711 mu-law,
or G.729B, along with DTMF telephony events for the 12 common or G.729B, along with DTMF telephony events for the 12 common
touchtone signals, but is willing to support simple G.711 mu-law touchtone signals, but is willing to support simple G.711 mu-law
audio as a last resort. In addition, the offerer wishes to announce audio as a last resort. In addition, the offerer wishes to announce
its ability to support video in the future, but does not wish to its ability to support video in the future, but does not wish to
offer a video stream at present. The offer might look like the offer a video stream at present. The offer might look like the
following: following:
1. v=0 v=0
2. o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753849 IN IP4 192.0.2.1
3. s= s=
4. c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
5. t=0 0 t=0 0
6. a=creq:med-v0 a=creq:med-v0
7. a=mcap:10 H263-1998/90000 m=audio 23456 RTP/AVP 0
8. a=mcap:11 H264/90000 a=rtpmap:0 PCMU/8000
9. a=tcap:1 RTP/AVP a=mcap:1 PCMU/8000
10. a=lcfg:10 mt=video t=1 m=10|11 a=mcap:2 g729/8000
11. m=audio 23456 RTP/AVP 0 a=mcap:3 telephone-event/8000
12. a=rtpmap:0 PCMU/8000 a=mfcap:3 0-11
13. a=mcap:1 PCMU/8000 a=pcfg:1 m=1,3|2,3 pt=1:0,2:18,3:100 a=lcfg:10 mt=video t=1
14. a=mcap:2 g729/8000 m=10|11
15. a=mcap:3 telephone-event/8000 a=mcap:10 H263-1998/90000
16. a=mfcap:3 0-11 a=mcap:11 H264/90000
17. a=pcfg:1 m=1,3|2,3 pt=1:0,2:18,3:100 a=tcap:1 RTP/AVP
Lines 7-10 announce support for H.263 and H.264 video (H.263 The lcfg attribute line announces support for H.263 and H.264 video
preferred) for future reference. Lines 11 and 12 offer an audio (H.263 preferred) for future reference. The m-line and the rtpmap
stream and provide the lowest precedence configuration (PCMU without attribute offer an audio stream and provide the lowest precedence
any DTMF encoding). Lines 13-15 define the media capabilities to be configuration (PCMU without any DTMF encoding). The mcap lines
offered: PCMU, G729, and telephone-event. Line 16 provides the define the media capabilities (PCMU, G729, and telephone-event) to be
format parameters for telephone-events, specifying the 12 commercial offered in potential configurations. The mfcap attribute provides
DTMF 'digits'. Line 17 defines the most-preferred media the format parameters for telephone-events, specifying the 12
configuration as PCMU plus DTMF events and the next-most-preferred commercial DTMF 'digits'. The pcfg attribute line defines the most-
configuration as G.729B plus DTMF events. preferred media configuration as PCMU plus DTMF events and the next-
most-preferred configuration as G.729B plus DTMF events.
If the answerer is able to support all the potential configurations, If the answerer is able to support all the potential configurations,
and also support H.263 video (but not H.264), it would reply with an and also support H.263 video (but not H.264), it would reply with an
answer like: answer like:
1. v=0 v=0
2. o=- 24351 621814 IN IP4 192.0.2.2 o=- 24351 621814 IN IP4 192.0.2.2
3. s= s=
4. c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
5. t=0 0 t=0 0
6. a=csup:med-v0 a=csup:med-v0
7. a=lcfg:1 mt=video t=1 m=10 m=audio 54322 RTP/AVP 0 100
8. m=audio 54322 RTP/AVP 0 100 a=rtpmap:0 PCMU/8000
9. a=rtpmap:0 PCMU/8000 a=rtpmap:100 telephone-event/8000
10. a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-11
11. a=fmtp:100 0-11 a=acfg:1 m=1,3 pt=1:0,3:100
12. a=acfg:1 m=1,3 pt=1:0,3:100 a=pcfg:1 m=2,3 pt=2:18,3:100 a=lcfg:1 mt=video t=1 m=10
13. a=pcfg:1 m=2,3 pt=2:18,3:100
Line 7 announces the capability to support H.263 video at a later The lcfg attribute line announces the capability to support H.263
time. Lines 8-11 of the answer present the selected configuration video at a later time. The media line and subsequent rtpmap and fmtp
for the media stream. Line 12 identifies the potential configuration attribute lines present the selected configuration for the media
from which it was taken, and line 13 announces the potential stream. The acfg attribute line identifies the potential
capability to support G.729 with DTMF events as well. If, at some configuration from which it was taken, and the pcfg attribute line
later time, congestion becomes a problem in the network, either party announces the potential capability to support G.729 with DTMF events
may offer a reconfiguration of the media stream to use G.729 in order as well. If, at some later time, congestion becomes a problem in the
to reduce packet sizes. network, either party may, with expectation of success, offer a
reconfiguration of the media stream to use G.729 in order to reduce
packet sizes.
5. IANA Considerations 5. IANA Considerations
5.1. New SDP Attributes 5.1. New SDP Attributes
The IANA is hereby requested to register the following new SDP The IANA is hereby requested to register the following new SDP
attributes: attributes:
Attribute name: mcap Attribute name: mcap
Long form name: media capability Long form name: media 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 capability number(s) with Purpose: associate media capability number(s) with
media subtype and encoding parameters media subtype and encoding parameters
Appropriate Values: see Section Section 3.3.1 Appropriate Values: see Section 3.3.1
Attribute name: mfcap Attribute name: mfcap
Long form name: media format capability Long form name: media format 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 format attributes and Purpose: associate media format attributes and
parameters with media format capabilities parameters with media format capabilities
Appropriate Values: see Section 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 Section 3.3.3 Appropriate Values: see Section 3.3.3
Attribute name: lcfg Attribute name: lcfg
Long form name: latent configuration Long form name: latent configuration
Type of attribute: session-level Type of attribute: media-level
Subject to charset: no Subject to charset: no
Purpose: to announce supportable media configurations Purpose: to announce supportable media streams
without offering them for immediate use. without offering them for immediate use.
Appropriate Values: see Section 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
Type of attribute: session-level Type of attribute: session-level
Subject to charset: no Subject to charset: no
Purpose: to specify and prioritize acceptable Purpose: to specify and prioritize acceptable
combinations of media stream configurations. combinations of media stream configurations.
Appropriate Values: see Section Section 3.3.8 Appropriate Values: see Section 3.3.8
5.2. New SDP Option Tag 5.2. New SDP Option Tag
The IANA is hereby requested to add the new option tag "med-v0", The IANA is hereby requested to add the new option tag "med-v0",
defined in this document, to the SDP Capability Option Negotiation defined in this document, to the SDP Capability Option Negotiation
Capability registry created for [SDPCapNeg]. Capability registry created for [RFC5939].
5.3. New SDP Capability Negotiation Parameters 5.3. New SDP Capability Negotiation Parameters
The IANA is hereby requested to expand the SDP Capability Negotiation The IANA is hereby requested to expand the SDP Capability Negotiation
Potential Configuration Parameter Registry established by [SDPCapNeg] Potential Configuration Parameter Registry established by [RFC5939]
to become the SDP Capability Negotiation Configuration Parameter to become the SDP Capability Negotiation Configuration Parameter
Registry and to include parameters for the potential, actual and Registry and to include parameters for the potential, actual and
latent configuration attributes. The new parameters to be registered latent configuration attributes. The new parameters to be registered
are the "m" for "media", "pt" for "payload type number", and "mt" for are the "m" for "media", "pt" for "payload type number", and "mt" for
"media type" parameters. Note that the "mt" parameter is defined for "media type" parameters. Note that the "mt" parameter is defined for
use only in the latent configuration attribute. use only in the latent configuration attribute.
6. Security Considerations 6. Security Considerations
The security considertions of [SDPCapNeg] apply for this document. The security considerations of [RFC5939] apply for this document.
The addition of negotiable media encoding, bandwidth attributes, and The addition of negotiable media encoding, bandwidth attributes, and
connection data in this specification can cause problems for connection data in this specification can cause problems for
middleboxes which attempt to control bandwidth utilization, media middleboxes which attempt to control bandwidth utilization, media
flows, and/or processing resource consumption as part of network flows, and/or processing resource consumption as part of network
policy, but which do not understand the media capability negotiation policy, but which do not understand the media capability negotiation
feature. As for the initial CapNeg work, the SDP answer is feature. As for the initial CapNeg work, the SDP answer is
formulated in such a way that it always carries the selected media formulated in such a way that it always carries the selected media
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 09 7.1. Changes from version 10
o Defined the latent configuration attribute as a media-level
attribute because it specifies a possible future media stream.
Added text to clarify how to specify alternative configurations of
a single latent stream and/or multiple streams.
o Improved the definition of the session capability attribute to
permit both required configurations and optional configurations -
latent configurations cannot be required because they have not yet
been offered.
o Removed the special-case treatment of conflicts between base-level
fmtp attributes and fmtp attributes generated for a configuration
via invoked mcap and mfcap attributes.
o Removed reference to bandwidth capability (bcap) attribute.
o Changed various "must", etc., terms to normative terms ("MUST",
etc.) as appropriate, in Section 3.3.5Section 3.3.6.1
Section 3.3.6.3 and Section 3.3.8
o Attempted to clarify the substitution mechanism in Section 3.3.7
and improve its uniqueness.
o Made various editorial changes, including changing the title in
the header, and removing numbering from some SDP examples.
7.2. Changes from version 09
o Additional corrections to latent media stream example in o Additional corrections to latent media stream example in
Section 4.3 Section 4.3
o Fixed up attribute formatting examples and corresponding ABNF. o Fixed up attribute formatting examples and corresponding ABNF.
o Removed preference rule for latent configurations. o Removed preference rule for latent configurations.
o Various spelling and other editorial changes were made. o Various spelling and other editorial changes were made.
o updated crossreferences. o updated crossreferences.
7.2. Changes from version 08 7.3. Changes from version 08
The major change is in section Section 4.3, Latent Media Streams, The major change is in Section 4.3, Latent Media Streams, fixing the
fixing the syntax of the answer. All the other changes are syntax of the answer. All the other changes are editorial.
editorial.
7.3. Changes from version 04 7.4. Changes from version 04
o The definitions for bcap, ccap, icap, and kcap attributes have o The definitions for bcap, ccap, icap, and kcap attributes have
been removed, and are to be defined in another document. been removed, and are to be defined in another document.
o Corrected formatting of m= and p= configuration parameters to o Corrected formatting of m= and p= configuration parameters to
conform to extension-config-list form defined in [SDPCapNeg] conform to extension-config-list form defined in [RFC5939]
o Reorganized definitions of new parameters to make them easier to o Reorganized definitions of new parameters to make them easier to
find in document. find in document.
o Added ability to renegotiate capabilities when modifying the o Added ability to renegotiate capabilities when modifying the
session (Section Section 3.4.4). session (Section 3.4.4).
o Made various editorial changes, clarifications, and typo o Made various editorial changes, clarifications, and typo
corrections. corrections.
7.4. Changes from version 03 7.5. 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 43, line 27 skipping to change at page 44, 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.5. Changes from version 02 7.6. 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 44, line 9 skipping to change at page 44, 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.6. Changes from version 01 7.7. 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.7. Changes from version 00 7.8. 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
in particular provided useful comments and suggestions to either the in particular provided useful comments and suggestions to either the
document itself or the overall direction of the solution defined document itself or the overall direction of the solution defined
herein: Cullen Jennings, Matt Lepinski, Joerg Ott, Colin Perkins, and herein: Cullen Jennings, Matt Lepinski, Joerg Ott, Colin Perkins, and
Thomas Stach. Thomas Stach.
We thank Ingemar Johansson and Magnus Westerlund for examples that We thank Ingemar Johansson and Magnus Westerlund for examples that
stimulated this work. stimulated this work, and for critical reading of the document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
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] [RFC5939] Andreasen, F., "SDP Capability Negotiation", RFC 5939,
Andreasen, F., "SDP Capability Negotiation", September 2010.
draft-ietf-mmusic-sdp-capability-negotiation-09 (work in
progress), July 2008.
9.2. Informative References 9.2. Informative References
[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.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733,
December 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
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs", RFC 4867, April 2007. (AMR-WB) Audio Codecs", RFC 4867, April 2007.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
Authors' Addresses Authors' Addresses
 End of changes. 146 change blocks. 
466 lines changed or deleted 532 lines changed or added

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