draft-ietf-mmusic-sdp-media-capabilities-11.txt   draft-ietf-mmusic-sdp-media-capabilities-12.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: September 1, 2011 Gesher Erove Ltd Expires: May 3, 2012 Gesher Erove Ltd
F. Andreasen F. Andreasen
Cisco Systems Cisco Systems
February 28, 2011 October 31, 2011
SDP Media Mapabilities Negotiation SDP Media Mapabilities Negotiation
draft-ietf-mmusic-sdp-media-capabilities-11 draft-ietf-mmusic-sdp-media-capabilities-12
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. negotiate media types and their associated parameters.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 1, 2011. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
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 . . . . . . . . . . . . . . . . 13 3.3. New Capability Attributes . . . . . . . . . . . . . . . . 13
3.3.1. The Media Format Capability Attribute . . . . . . . . 13 3.3.1. The Media Format Capability Attributes . . . . . . . . 13
3.3.2. The Media Format Parameter Capability Attribute . . . 15 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 . . . . . . . 18
3.3.4. New Configuration Parameters . . . . . . . . . . . . . 19 3.3.4. New Configuration Parameters . . . . . . . . . . . . . 20
3.3.5. The Latent Configuration Attribute . . . . . . . . . . 20 3.3.5. The Latent Configuration Attribute . . . . . . . . . . 21
3.3.6. Enhanced Potential Configuration Attribute . . . . . . 23 3.3.6. Enhanced Potential Configuration Attribute . . . . . . 24
3.3.7. Substitution of Media Payload Type Numbers in 3.3.7. Substitution of Media Payload Type Numbers in
Capability Attribute Parameters . . . . . . . . . . . 26 Capability Attribute Parameters . . . . . . . . . . . 27
3.3.8. The Session Capability Attribute . . . . . . . . . . . 27 3.3.8. The Session Capability Attribute . . . . . . . . . . . 28
3.4. Offer/Answer Model Extensions . . . . . . . . . . . . . . 31 3.4. Offer/Answer Model Extensions . . . . . . . . . . . . . . 32
3.4.1. Generating the Initial Offer . . . . . . . . . . . . . 31 3.4.1. Generating the Initial Offer . . . . . . . . . . . . . 32
3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 32 3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 33
3.4.3. Offerer Processing of the Answer . . . . . . . . . . . 32 3.4.3. Offerer Processing of the Answer . . . . . . . . . . . 33
3.4.4. Modifying the Session . . . . . . . . . . . . . . . . 32 3.4.4. Modifying the Session . . . . . . . . . . . . . . . . 34
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1. Alternative Codecs . . . . . . . . . . . . . . . . . . . . 33 4.1. Alternative Codecs . . . . . . . . . . . . . . . . . . . . 35
4.2. Alternative Combinations of Codecs (Session 4.2. Alternative Combinations of Codecs (Session
Configurations) . . . . . . . . . . . . . . . . . . . . . 36 Configurations) . . . . . . . . . . . . . . . . . . . . . 38
4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 36 4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 38
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 39 5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 41
5.2. New SDP Option Tag . . . . . . . . . . . . . . . . . . . . 40 5.2. New SDP Option Tag . . . . . . . . . . . . . . . . . . . . 42
5.3. New SDP Capability Negotiation Parameters . . . . . . . . 40 5.3. New SDP Capability Negotiation Parameters . . . . . . . . 42
6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 6. Security Considerations . . . . . . . . . . . . . . . . . . . 43
7. Changes from previous versions . . . . . . . . . . . . . . . . 42 7. Changes from previous versions . . . . . . . . . . . . . . . . 44
7.1. Changes from version 10 . . . . . . . . . . . . . . . . . 42 7.1. Changes from version 11 . . . . . . . . . . . . . . . . . 44
7.2. Changes from version 09 . . . . . . . . . . . . . . . . . 42 7.2. Changes from version 10 . . . . . . . . . . . . . . . . . 44
7.3. Changes from version 08 . . . . . . . . . . . . . . . . . 42 7.3. Changes from version 09 . . . . . . . . . . . . . . . . . 44
7.4. Changes from version 04 . . . . . . . . . . . . . . . . . 43 7.4. Changes from version 08 . . . . . . . . . . . . . . . . . 45
7.5. Changes from version 03 . . . . . . . . . . . . . . . . . 43 7.5. Changes from version 04 . . . . . . . . . . . . . . . . . 45
7.6. Changes from version 02 . . . . . . . . . . . . . . . . . 44 7.6. Changes from version 03 . . . . . . . . . . . . . . . . . 45
7.7. Changes from version 01 . . . . . . . . . . . . . . . . . 44 7.7. Changes from version 02 . . . . . . . . . . . . . . . . . 46
7.8. Changes from version 00 . . . . . . . . . . . . . . . . . 44 7.8. Changes from version 01 . . . . . . . . . . . . . . . . . 46
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 7.9. Changes from version 00 . . . . . . . . . . . . . . . . . 47
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Normative References . . . . . . . . . . . . . . . . . . . 46 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.2. Informative References . . . . . . . . . . . . . . . . . . 46 9.1. Normative References . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 9.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
Session Description Protocol (SDP) capability negotiation [RFC5939] 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 [RFC5939] document lists some of the issues with the current SDP The [RFC5939] document lists some of the issues with the current SDP
capability negotiation process. An additional real life case is to capability negotiation process. An additional real life case is to
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[RFC5939], or any in this document, the base capability negotiation document[RFC5939],
future capability negotiation document. In an offer SDP, the base or any other capability negotiation document. In an offer SDP, the
configuration corresponds to the actual configuration as defined in base configuration corresponds to the actual configuration as defined
[RFC5939]. 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 [RFC5939] discusses the use of any SDP The SDP capability negotiation [RFC5939] discusses the use of any SDP
[RFC4566] attribute (a=) under the attribute capability "acap". The [RFC4566] attribute (a=) under the attribute capability "acap". 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 [RFC5939]; 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 [RFC5939] does not provide a way to exchange media-level The [RFC5939] does not provide a way to exchange media-level
capabilities prior to the actual offer of one or more media streams. capabilities prior to the actual offer of the associated media
This section provides an overview of extensions providing an SDP stream. This section provides an overview of extensions providing an
Media Capability negotiation solution offering more robust SDP Media Capability negotiation solution offering more robust
capabilities negotiation. This is followed by definitions of new SDP capabilities negotiation. This is followed by definitions of new SDP
attributes for the solution and its associated updated offer/answer attributes for the solution and its associated updated offer/answer
procedures [RFC3264] procedures [RFC3264]
3.1. Requirements 3.1. Requirements
The capability negotiation extensions described herein are described The capability negotiation extensions requirements considered herein
as follows. are 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
parameters for each media format. parameters for each media format.
REQ-03: Retain backward compatibility with conventional SDP. REQ-03: Retain backward compatibility with conventional SDP.
Ensure that each and every offered configuration can be easily Ensure that each and every offered configuration can be easily
translated into a corresponding SDP media block expressed with translated into a corresponding SDP media block expressed with
skipping to change at page 7, line 36 skipping to change at page 7, line 36
stream would use image/T38. stream would use image/T38.
FUT-02: Provide the ability to support multiple transport protocols FUT-02: Provide the ability to support multiple transport protocols
within an active media stream without reconfiguration. This is within an active media stream without reconfiguration. This is
not explicitly supported by conventional SDP. not explicitly supported by conventional SDP.
FUT-03: Provide capability negotiation attributes for all media- FUT-03: Provide capability negotiation attributes for all media-
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 line 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, acfg, and conventional SDP line types, new parameters for the pcfg, acfg, and
the new lcfg attributes extending the base attributes from [RFC5939], the new lcfg attributes extending the base attributes from [RFC5939],
and a use of the pcfg attribute to return capability information in and a use of the pcfg attribute to return capability information in
the SDP answer. the SDP answer.
Three new attributes are defined in a manner that can be related to Several 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=rmcap") defines RTP-based media
form of a media subtype (e.g. "PCMU"), and its encoding capabilities in the form of a media subtype (e.g. "PCMU"), and
parameters (e.g. "/8000/2"). Each resulting media format type/ its encoding parameters (e.g. "/8000/2"). Each resulting media
subtype capability has an associated handle called a media format type/subtype capability has an associated handle called a
capability number. The encoding parameters are as specified for media capability number. The encoding parameters are as specified
the rtpmap attribute defined in [RFC4566], without the payload for the rtpmap attribute defined in [RFC4566], without the payload
type number part. type number part.
o A new media attribute ("a=omcap") defines other (non RTP-based)
media capabilities in the form of a media subtype only (e.g.
"T38"). Each resulting media format type/subtype capability has
an associated handle called a media capability number.
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. Note that
media format parameters can be used with RTP and non-RTP based
media formats.
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 defined in than fmtp or rtpmap, for example, the rtcp-fb attribute defined in
[RFC4585]. [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 latent configurations for video even An example is the offer of latent configurations for video even
though no video is currently offered. If the peer indicates though no video is currently offered. If the peer indicates
support for one or more of offered latent configurations, the support for one or more offered latent configurations, the
corresponding media stream(s) may be added via a new offer/answer corresponding media stream(s) may be added via a new offer/answer
exchange. 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 and their configurations combination of simultaneous media streams and their configurations
as a list of potential 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
skipping to change at page 9, line 8 skipping to change at page 9, line 13
of media capabilities (including their associated parameters) and of media capabilities (including their associated parameters) and
combinations thereof for the configuration. For example, the combinations thereof for the configuration. For example, the
"a=pcfg:" line might specify PCMU and telephone events [RFC4733] "a=pcfg:" line might specify PCMU and telephone events [RFC4733]
or G.729B and telephone events as acceptable configurations. The or G.729B and telephone events as acceptable configurations. The
"a=acfg:" line in the answer would specify the configuration "a=acfg:" line in the answer would specify the configuration
chosen. 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 type numbers attributes. This parameter associates RTP payload type numbers
with the referenced media capabilities, and is appropriate only with the referenced RTP-based media capabilities, and is
when the transport protocol uses RTP. appropriate only 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 and mscap capability attributes. This reduces the of the mfcap and mscap capability attributes. This reduces the
necessity to use the deletion qualifier in the pcfg a= parameter necessity to use the deletion qualifier in the a=pcfg parameter in
in order to ignore rtpmap, fmtp, and certain other attributes in order to ignore rtpmap, fmtp, and certain other attributes in the
the base configuration. 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 10, line 28 skipping to change at page 10, line 31
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 m=audio 3456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP RTP/AVP a=tcap:1 RTP/SAVP RTP/AVP
a=rtpmap:0 PCMU/8000/1 a=rtpmap:0 PCMU/8000/1
a=rtpmap:18 G729/8000/1 a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=yes a=fmtp:18 annexb=yes
a=mcap:1,4 g729/8000/1 a=rmcap:1,4 g729/8000/1
a=mcap:2 PCMU/8000/1 a=rmcap:2 PCMU/8000/1
a=mcap:5 telephone-event/8000 a=rmcap:5 telephone-event/8000
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"
skipping to change at page 11, line 7 skipping to change at page 11, line 11
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=rmcap:1,4" line defines two G.729 RTP-based media format
numbered 1 and 4, and their encoding rate. The capabilities are of capabilities, numbered 1 and 4, and their encoding rate. The
media type "audio" and subtype G729. Note that the media subtype is capabilities are of media type "audio" and subtype G729. Note that
explicitly specified here, rather than RTP payload type numbers. the media subtype is explicitly specified here, rather than RTP
This permits the assignment of payload type numbers in the media payload type numbers. This permits the assignment of payload type
stream configuration specification. In this example, two G.729 numbers in the media stream configuration specification. In this
subtype capabilities are defined. This permits the declaration of example, two G.729 subtype capabilities are defined. This permits
two sets of formatting parameters for G.729. 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=rmcap:2" line defines a G.711 mu-law capability, numbered 2.
The "a=mcap:5" line defines an audio telephone-event capability, The "a=rmcap: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
capability 4 (offerer will accept G.729 Annex B packets). capability 4 (offerer will accept G.729 Annex B packets).
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,*,#).
skipping to change at page 11, line 44 skipping to change at page 11, line 48
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, attribute capabilities and specified payload transport capabilities, attribute capabilities and specified payload
type number mappings. Three explicit alternatives are provided; the type number mappings. Three explicit alternatives are provided; the
lowest-numbered one is the preferred one. The "a=pcfg:1 ..." line lowest-numbered one is the preferred one. The "a=pcfg:1 ..." line
specifies media capabilities 4 and 5, i.e., G.729B and DTMF, or media specifies media capabilities 4 and 5, i.e., G.729B and DTMF, or media
capability 1 and 5, i.e., G.729 and DTMF. Furthermore, it specifies capability 1 and 5, i.e., G.729 and DTMF. Furthermore, it specifies
transport protocol capability 1 (i.e. the RTP/SAVP profile - secure transport protocol capability 1 (i.e. the RTP/SAVP profile - secure
RTP), and the attribute capability 1, i.e. the crypto attribute RTP), and the attribute capability 1, i.e. the crypto attribute
provided. Lastly, it specifies a payload type number mapping for provided. Lastly, it specifies a payload type number mapping for
media capabilities 1, 4, and 5, thereby permitting the offerer to (RTP-based) media capabilities 1, 4, and 5, thereby permitting the
distinguish between encrypted media and unencrypted media received offerer to distinguish between encrypted media and unencrypted media
prior to receipt of the answer. received prior to receipt of the answer.
Use of unique payload type numbers is not required; codecs such as Use of unique payload type numbers in alternative configurations is
AMR-WB [RFC4867] have the potential for so many combinations of not required; codecs such as AMR-WB [RFC4867] have the potential for
options that it may be impractical to define unique payload type so many combinations of options that it may be impractical to define
numbers for all supported combinations. If unique payload type unique payload type numbers for all supported combinations. If
numbers cannot be specified, then the offerer will be obliged to wait unique payload type numbers cannot be specified, then the offerer
for the SDP answer before rendering received media. For SRTP using will be obliged to wait for the SDP answer before rendering received
SDES inline keying [RFC4568], the offerer will still need to receive media. For SRTP using SDES inline keying [RFC4568], the offerer will
the answer before being able to decrypt the stream. still need to receive the answer before being able to decrypt the
stream.
The second alternative ("a=pcfg:2 ...") specifies media capability 2, The second alternative ("a=pcfg:2 ...") specifies media capability 2,
i.e. PCMU, under the RTP/SAVP profile, with the same SRTP key i.e. PCMU, under the RTP/SAVP profile, with the same SRTP key
material. material.
The third alternative ("a=pcfg:3 ...") offers G.729B unsecured; it's The third alternative ("a=pcfg:3 ...") offers G.729B unsecured; its
only purpose in this example is to show a preference for G.729B over only purpose in this example is to show a preference for G.729B over
PCMU. PCMU.
The media line, with any qualifying attributes such as fmtp or The media line, with any qualifying attributes such as fmtp or
rtpmap, is itself considered a valid configuration; it is assumed to rtpmap, is itself considered a valid configuration; it is assumed to
be the lowest preference. be the lowest preference.
Bob receives the SDP offer from Alice. Bob supports G.729B, PCMU, Bob receives the SDP offer from Alice. Bob supports G.729B, PCMU,
and telephone events over RTP, but not SRTP, hence he accepts the and telephone events over RTP, but not SRTP, hence he accepts the
potential configuration 3 for RTP provided by Alice. Bob generates potential configuration 3 for RTP provided by Alice. Bob generates
the following answer: the following answer:
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 19x2.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 t=2 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
and/or fmtp parameters, as appropriate. rtpmap and/or fmtp parameters, as appropriate.
Note that per the base protocol, after the above, Alice MAY generate Note that per the base protocol, after the above, Alice MAY generate
a new offer with an actual configuration ("m=" line, etc.) a new offer with an actual configuration ("m=" line, etc.)
corresponding to the actual configuration referenced in Bob's answer corresponding to the actual configuration referenced in Bob's answer
(not shown here). (not shown here).
3.3. New Capability Attributes 3.3. New Capability Attributes
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" to
instead of payload type numbers to link the relevant media capability link the relevant media capability parameters. This permits the
parameters. This permits the capabilities to be defined at the capabilities to be defined at the session level and be used for
session level and be used for multiple streams, if desired. Payload multiple streams, if desired. For RTP-based media formats, payload
types are then specified at the media level (see Section 3.3.4.2). types are then specified at the media level (see 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 any pcfg or lcfg attribute at the media level referenced in any pcfg or lcfg attribute at the media level
(consistent with the media type), whereas media capabilities provided (consistent with the media type), whereas media capabilities provided
at the media level may be referenced only by the pcfg or lcfg at the media level may be referenced only by the pcfg or lcfg
attribute within that media stream only. In either case, the scope attribute within that media stream only. In either case, the scope
of the <med-cap-num> is the entire session description. This enables of the <med-cap-num> is the entire session description. This enables
each media capability to be uniquely referenced across the entire each media capability to be uniquely referenced across the entire
session description (e.g. in a potential configuration). session description (e.g. in a potential configuration).
3.3.1. The Media Format Capability Attribute 3.3.1. The Media Format Capability Attributes
Media subtypes can be expressed as media format 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=rmcap" and "a=omcap" attributes. The "a=rmcap" attribute
MUST be used for RTP-based media whereas the "a=omcap" attribute MUST
be used for non-RTP-based (other) media formats. The two attributes
are defined as follows:
a=mcap:<media-cap-num-list> <encoding-name>/<clock-rate> a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate>
[/<encoding-parms>] [/<encoding-parms>]
a=omcap:<media-cap-num-list> <format-name>
where <media-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
attribute MUST use unique values in its <media-cap-num-list>; the rmcap and omcap attribute MUST use unique values in their <media-cap-
media capability numbers must be unique across the entire SDP num-list>; the media capability numbers are shared between the two
session. In short, the mcap attribute defines media capabilities and attributes and the numbers MUST be unique across the entire SDP
associates them with a media capability number in the same manner as session. In short, the rmcap and omcap attributes define media
the rtpmap attribute defines them and associates them with a payload capabilities and associates them with a media capability number in
type number. Additionally, the mcap attribute allows multiple the same manner as the rtpmap attribute defines them and associates
capability numbers to be defined for the media format in question. them with a payload type number. Additionally, the attributes allow
This permits the media format to be associated with different media multiple capability numbers to be defined for the media format in
parameters in different configurations. 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 = rtp-mcap / non-rtp-mcap
1*WSP encoding-name "/" clock-rate
["/" encoding-parms] rtp-mcap = "a=rmcap:" media-cap-num-list
media-cap-num-list = media-cap-num-element 1*WSP encoding-name "/" clock-rate
*["," media-cap-num-element] ["/" encoding-parms]
media-cap-num-element = media-cap-num non-rtp-mcap = "a=omcap:" media-cap-num-list 1*WSP format-name
/ media-cap-num-range media-cap-num-list = media-cap-num-element
media-cap-num-range = media-cap-num "-" media-cap-num *["," media-cap-num-element]
media-cap-num = 1*10(DIGIT) media-cap-num-element = media-cap-num
encoding-name = token ; defined in RFC4566 / media-cap-num-range
clock-rate = 1*10(DIGIT) media-cap-num-range = media-cap-num "-" media-cap-num
encoding-parms = token media-cap-num = 1*10(DIGIT)
encoding-name = token ; defined in RFC4566
clock-rate = 1*10(DIGIT)
encoding-parms = token
format-name = token ;defined in RFC4566
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 rmcap 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 3.3.5). cap-num (see Section 3.3.5).
The "mcap" attribute can be provided at the session-level and/or the The format-name is a media format description for non-RTP based media
media-level. There can be more than one mcap attribute at the as defined for the <fmt> part of the media description ("m=" line) in
session or media level. Each media-cap-num must be unique within the [RFC4566]. In simple terms, it's the name of the media format, e.g.
entire SDP record; it is used to identify that media capability in "t38".
The "rmcap" and "omcap" attributes can be provided at the session-
level and/or the media-level. There can be more than one rmcap plus
one omcap attribute at the session or media level (i.e at most one of
each at the session-level and at most one of in each media
description). Each media-cap-num MUST be unique within the 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. Note that the media-cap-num values are
configuration it is, in effect, a media level attribute regardless if shared between the rmcap and omcap attributes, and hence the
it is specified at the session or media level. In other words, the uniqueness requirement applies to the union of them. When the media
media capability applies to the specific media description associated capabilities are used in a potential, latent or actual configuration,
with the configuration which invokes it. the media formats referred by those configurations apply at the media
level, irrespective of whether the media capabilities themselves were
specified at the session or media level. In other words, the media
capability applies to the specific media description associated with
the configuration which invokes it.
For example: For example:
v=0 v=0
a=mcap:1 L16/8000/1 a=rmcap:1 L16/8000/1
a=mcap:2 L16/16000/2 a=rmcap:2 L16/16000/2
a=mcap:3,4 H263-1998/90000 a=rmcap: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 format specific format This attribute is used to associate media format specific format
parameters with one or more media capabilities. The form of the parameters with one or more media capabilities. The form of the
skipping to change at page 15, line 34 skipping to change at page 16, line 12
which would conventionally appear in an fmtp attribute. The existing which would conventionally appear in an fmtp attribute. The existing
acap attribute MUST NOT be used to encode fmtp attributes. acap attribute MUST NOT be used to encode fmtp attributes.
The mfcap attribute adheres to [RFC4566] attribute production rules The mfcap attribute adheres to [RFC4566] attribute production rules
with with
media-format-capability = "a=mfcap:" media-cap-num-list 1*WSP media-format-capability = "a=mfcap:" media-cap-num-list 1*WSP
fmt-specific-param-list fmt-specific-param-list
fmt-specific-param-list = text ; defined in RFC4566 fmt-specific-param-list = text ; defined in RFC4566
Note that media format parameters can be used with RTP-based and non-
RTP based media formats.
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
selected for processing, the parameters from each mfcap line which selected for processing, the parameters from each mfcap line which
references the particular capability number in its media-cap-num-list references the particular capability number in its media-cap-num-list
are concatenated together via ";", in the order the mfcap attributes are concatenated together via ";", in the order the mfcap attributes
appear in the SDP record, to form the equivalent of a single fmtp appear in the SDP record, to form the equivalent of a single fmtp
attribute line. This permits one to define a separate mfcap line for attribute line. This permits one to define a separate mfcap line for
a single parameter and value that is to be applied to each media a single parameter and value that is to be applied to each media
capability designated in the media-cap-num-list. This provides a capability designated in the media-cap-num-list. This provides a
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 SHOULD 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). The resulting format corresponding format attribute (a=fmtp). The resulting format
attribute will look something like the following: attribute will look something like the following (without line
breaks):
a=fmtp:<fmt> <fmt-specific-param-list1>; a=fmtp:<fmt> <fmt-specific-param-list1>;
<fmt-specific-param-list2>; <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
ensure 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=rmcap: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=rmcap:1 video H263-1998/90000
a=mcap:2 video H263-2000/90000 a=rmcap: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=rmcap:1-3 AMR/8000/1
a=mcap:4-6 AMR-WB/16000/1 a=rmcap: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
skipping to change at page 17, line 44 skipping to change at page 18, line 26
the media capabilities specifications into one or more alternative the media capabilities specifications into one or more alternative
media stream specifications, one of which can be chosen for the media stream specifications, one of which can be chosen for the
answer. answer.
3.3.3. The Media-Specific Capability Attribute 3.3.3. The Media-Specific Capability Attribute
Media-specific attributes, beyond the rtpmap and fmtp attributes, may Media-specific attributes, beyond the rtpmap and fmtp attributes, may
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 star> <att field> <att value>
Where <media caps> is a (list of) media capability number(s), <att Where <media caps star> is a (list of) media capability number(s),
field> is the attribute name, and <att value> is the value field for <att field> is the attribute name, and <att value> is the value field
the named attribute. In ABNF, we have: for the named attribute. The media capability numbers may include a
wildcard ("*"), which will be used instead of any payload type
mappings. In ABNF, we have:
media-specific-capability = "a=mscap:" media-specific-capability = "a=mscap:"
media-caps ; defined in 3.3.2 media-caps-star
1*WSP att-field ; from RFC4566 1*WSP att-field ; from RFC4566
1*WSP att-value ; from RFC4566 1*WSP att-value ; from RFC4566
media-caps-star = media-cap-star-element
*["," media-cap-star-element]
media-cap-star-element = media-cap-num [wildcard]
/ media-cap-num-range [wildcard]
wildcard = "*"
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.
If a media capability number (or range) contains a wildcard character
at the end, any payload type mapping specified for that media
specific capability will be use the wildcard character instead of the
payload type.
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 (but different media capability numbers), one line per media
capability.
Multiple mscap lines may refer to the same media capability, but, Multiple mscap lines may refer to the same media capability, but,
unlike the mfcap attribute, no concatenation operation is defined. unlike the mfcap attribute, no concatenation operation is defined.
Hence, multiple mscap lines applied to the same media capability is Hence, multiple mscap lines applied to the same media capability is
equivalent to multiple lines of the specified attribute in a equivalent to multiple lines of the specified attribute in a
conventional media record. conventional media record.
Here is an example with the rtcp-fb attribute, modified from an Here is an example with the rtcp-fb attribute, modified from an
example in [RFC5104] (with the session-level and audio media example in [RFC5104] (with the session-level and audio media
omitted). If the offer contains a media block like the following, omitted). If the offer contains a media block like the following
(note the wildcard character),
m=video 51372 RTP/AVP 98 m=video 51372 RTP/AVP 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=tcap:1 RTP/AVPF a=tcap:1 RTP/AVPF
a=mcap:1 H263-1998/90000 a=rmcap:1 H263-1998/90000
a=mscap:1 rtcp-fb ccm tstr a=mscap:1 rtcp-fb ccm tstr
a=mscap:1 rtcp-fb ccm fir a=mscap:1 rtcp-fb ccm fir
a=mscap:* rtcp-fb ccm tmmbr smaxpr=120 a=mscap:1* rtcp-fb ccm tmmbr smaxpr=120
a=pcfg:1 t=1 m=1 pt=1:98 a=pcfg:1 t=1 m=1 pt=1:98
and if the proposed configuration is chosen, then the equivalent and if the proposed configuration is chosen, then the equivalent
media block would look like media block would look like
m=video 51372 RTP/AVPF 98 m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir a=rtcp-fb:98 ccm fir
a=rtcp-fb:* ccm tmmbr smaxpr=120 a=rtcp-fb:* ccm tmmbr smaxpr=120
skipping to change at page 19, line 28 skipping to change at page 20, line 28
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 RFC5939 ; BAR is defined in RFC5939
; media-cap-num-list is defined above ; media-cap-num-list is defined above
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. The use of the plus sign from the associated "m=" line will be used. The use of the plus sign
("+") is described in RFC5939. ("+") is described in RFC5939.
3.3.4.2. The Payload Type Number Mapping Parameter (pt=) 3.3.4.2. The Payload Type Number Mapping Parameter (pt=)
skipping to change at page 20, line 5 skipping to change at page 21, line 5
accordance with the extension-config-list format defined in accordance with the extension-config-list format defined in
[RFC5939]. In ABNF: [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 3.3.1 ; media-cap-num is defined in 3.3.1
payload-type-number = 1*3(DIGIT) ; RTP payload type number payload-type-number = 1*3(DIGIT) ; RTP payload type number
/ "*" ; dummy / "*" ; dummy
The example in Section 3.3.7 shows how the parameters from the mcap The example in Section 3.3.7 shows how the parameters from the rmcap
line are mapped to payload type numbers from the pcfg "pt" parameter. line are mapped to payload type numbers from the pcfg "pt" parameter.
The use of the plus sign ("+") is desribed in RFC5939. The use of the plus sign ("+") is desribed in RFC5939.
The "*" value for payload-type-number is used in cases such as BFCP The "*" value for payload-type-number is used in cases such as BFCP
[RFC4583] in which the 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 Redundant Audio Data (RED) payload, which are
Specific payload type numbers used in a latent configuration may be payload type numbers. Specific payload type numbers used in a latent
interpreted as suggestions to be used in any future offer based on configuration MAY be interpreted as suggestions to be used in any
the latent configuration, but they are not binding; the offerer future offer based on the latent configuration, but they are not
and/or answerer may use any payload type numbers each deems binding; the offerer and/or answerer may use any payload type numbers
appropriate. The use of explicit payload type numbers for latent each deems appropriate. The use of explicit payload type numbers for
configurations can be avoided by use of the parameter substitution latent configurations can be avoided by use of the parameter
rule of Section 3.3.7 . Future extensions are also permitted. substitution rule of Section 3.3.7 . Future extensions are also
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 media level),
level), indicating the ability to support an additional media stream, indicating the ability to support an additional media stream, it is
it is necessary to specify the media type (audio, video, etc.) as necessary to specify the media type (audio, video, etc.) as well as
well as the format and transport type. The media type parameter is the format and transport type. The media type parameter is defined
defined in ABNF as in ABNF as
media-type = ["+"] "mt=" 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, and the use of the "+" prefix to specify configuration attribute, and the use of the "+" prefix to specify
that the entire attribute line is to be ignored if the mt= parameter that the entire attribute line is to be ignored if the mt= parameter
is not understood, is unnecessary. However, if the media-type is not understood, is unnecessary. However, if the media-type
parameter is later added to an existing capability attribute such as parameter is later added to an existing capability attribute such as
pcfg, then the "+" would be useful. The media format(s) and pcfg, then the "+" would be useful. The media format(s) and
transport type(s) are specified using the media configuration transport type(s) are specified using the media configuration
skipping to change at page 21, line 16 skipping to change at page 22, line 17
latent video configurations along with the media stream for audio; latent video configurations along with the media stream for audio;
the responding party may indicate its ability and willingness to the responding party may indicate its ability and willingness to
support such a video session by returning a corresponding latent support such a video session by returning a corresponding latent
configuration. configuration.
Latent configurations returned in SDP answers must match offered Latent configurations returned in SDP answers must match offered
latent configurations (or parameter subsets thereof). Therefore, it latent configurations (or parameter subsets thereof). Therefore, it
is appropriate for the offering party to announce most, if not all, is appropriate for the offering party to announce most, if not all,
of its capabilities in the initial offer. 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, rmcap, 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 latent configuration the potential configuration attribute. The latent configuration
attribute combines the properties of a media line and a potential attribute combines the properties of a media line and a potential
configuration. The media type (mt=) and the transport protocol(s) configuration. The media type (mt=) and the transport protocol(s)
(t=) MUST be specified since the latent configuration is independent (t=) MUST be specified since the latent configuration is independent
of any media line present. In most cases, the media configuration of any media line present. In most cases, the media configuration
(m=) parameter MUST be present as well (see Section 4 for examples). (m=) parameter MUST be present as well (see Section 4 for examples).
The lcfg attribute is a media level attribute and, like a media line, The lcfg attribute is a media level attribute and, like a media line,
skipping to change at page 22, line 27 skipping to change at page 23, line 27
corresponding stream is actually offered via an m-line in a later corresponding stream is actually offered via an m-line in a later
exchange. The payload-number-config-list is included as a parameter exchange. The payload-number-config-list is included as a parameter
to the lcfg attribute in case it is necessary to tie payload numbers to the lcfg attribute in case it is necessary to tie payload numbers
in attribute capabilities to specific media capabilities. in attribute capabilities to specific media capabilities.
If an lcfg attribute invokes an acap attribute that appears at the If an lcfg attribute invokes an acap attribute that appears at the
session level, then that attribute will be expected to appear at the session level, then that attribute will be expected to appear at the
session level of a subsequent offer when and if a corresponding media session level of a subsequent offer when and if a corresponding media
stream is offered. Otherwise, acap attributes which appear at the stream is offered. Otherwise, acap attributes which appear at the
media level represent media-level attributes. Note, however, that media level represent media-level attributes. Note, however, that
mcap, mfcap, mscap, tcap attributes may appear at the session level rmcap, omcap, mfcap, mscap, and tcap attributes may appear at the
because they always result in media-level attributes or m-line session level because they always result in media-level attributes or
parameters. 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 3.3.8. For example, if an SDP offer contains, say, an audio 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 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 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 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 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 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. This restriction is especially important if the configurations. This restriction is especially important if the
offerer does not require cmed-v0 capability and the recipient of 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, offer doesn't support it. If the lcfg attribute is not recognized,
the capability attributes intended to be associated with it may be the capability attributes intended to be associated with it may be
confused with those associated with a potential configuration of some confused with those associated with a potential configuration of some
other media stream. 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 keying material required in the conventional
such as the SDES key/salt string, MUST be included in order to attribute, such as the SDES key/salt string, MUST be included in
satisfy formatting rules for the attribute. The actual value(s) of order to satisfy formatting rules for the attribute. The actual
the key material SHOULD be meaningless, and the receiver of the lcfg value(s) of the keying material SHOULD be meaningless, and the
attribute MUST ignore the values. receiver of the lcfg 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 [RFC5939] 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 3.3.5. The expanded the latent configuration attribute in Section 3.3.5. The 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 [RFC5939] pot-config = / attribute-config-list / ;def in [RFC5939]
transport-protocol-config-list / ;defined in [RFC5939] transport-protocol-config-list / ;defined in [RFC5939]
extension-config-list / ;[RFC5939] 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 an answer SDP to indicate the ability of the answerer to to within an answer SDP to indicate the ability of the answerer to
support alternative configurations of the corresponding stream(s). support alternative configurations of the corresponding stream(s).
For example, an offer may include multiple potential configurations For example, an offer may include multiple potential configurations
for a media stream and/or latent configurations for additional for a media stream and/or latent configurations for additional
streams; the corresponding answer will indicate (via an acfg streams; the corresponding answer will indicate (via an acfg
attribute) the configuration accepted and used to construct the base attribute) the configuration accepted and used to construct the base
configuration for each active media stream in the reply, but the configuration for each active media stream in the reply, but the
reply MAY also contain potential and/or latent configuration reply MAY also contain potential and/or latent configuration
attributes, with parameters, to indicate which other offered attributes, with parameters, to indicate which other offered
configurations would be acceptable. This information is useful if it configurations would be acceptable. This information is useful if it
becomes desirable to reconfigure a media stream, e.g., to reduce becomes desirable to reconfigure a media stream, e.g., to reduce
skipping to change at page 24, line 24 skipping to change at page 25, line 24
configuration number if it is necessary to describe selected configuration number if it is necessary to describe selected
combinations of optional or alternative parameters. 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 3.3.8.) are supportable by the answerer (see Section 3.3.8.)
Note that, although the answerer MAY return capabilities beyond those Note that, although the answerer MAY return capabilities beyond those
included by the offerer, these capabilities MUST NOT be used to form included by the offerer, these capabilities MUST NOT be used to form
any base level media description in the answer. For this reason, it any base level media description in the answer. For this reason, it
seems advisable for the offerer to include most, if not all, is advisable for the offerer to include most, if not all, potential
potential and latent configurations it can support in the initial and latent configurations it can support in the initial offer, unless
offer. Either party MAY later announce additional capabilities by the size of the resulting SDP is a concern. Either party MAY later
renegotiating the session in a second offer/answer exchange. 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 rmcap attributes are used in
potential configuration lines, and the transport protocol uses RTP, potential configuration lines, the transport protocol uses RTP and it
it is necessary to assign payload type numbers to them. In some is necessary to assign payload type numbers. In some cases, it is
cases, it is desirable to assign different payload type numbers to desirable to assign different payload type numbers to the same media
the same media capability when used in different potential capability when used in different potential configurations. One
configurations. One example is when configurations for AVP and SAVP example is when configurations for AVP and SAVP are offered: the
are offered: the offerer would like the answerer to use different offerer would like the answerer to use different payload type numbers
payload type numbers for encrypted and unencrypted media so that it for encrypted and unencrypted media so that it (the offerer) can
(the offerer) can decide whether or not to render early media which decide whether or not to render early media which arrives before the
arrives before the answer is received. This association of distinct answer is received. This association of distinct payload type
payload type number(s) with different transport protocols requires a number(s) with different transport protocols requires a separate pcfg
separate pcfg line for each protocol. Clearly, this technique cannot line for each protocol. Clearly, this technique cannot be used if
be used if the number of potential configurations exceeds the number the number of potential configurations exceeds the number of possible
of possible payload type numbers. 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 rmcap, omcap, mfcap, and mscap which map into
conventional attributes when invoked by a potential configuration. those conventional attributes when invoked by a potential
In such cases, it MAY be appropriate to employ the a delete- configuration. In such cases, it MAY be appropriate to employ the
attributes option in the attribute configuration list parameter in delete-attributes option [RFC5939] in the attribute configuration
order to avoid the generation of conflicting fmtp attributes for a list parameter in order to avoid the generation of conflicting fmtp
particular configuration. Any media-specific attributes in the media attributes for a particular configuration. Any media-specific
block which refer to payload type numbers not used by the potential attributes in the media block which refer to media formats not used
configuration MUST be ignored. by the potential configuration MUST be ignored.
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=rmcap:1 PCMU/8000
a=mcap:2 g729/8000 a=rmcap:2 g729/8000
a=mcap:3 telephone-events/8000 a=rmcap:3 telephone-events/8000
a=mfcap:3 0-15 a=mfcap:3 0-15
a=pcfg:1 m=2,3|1,3 a=-m 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 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:1 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, and dtmf events, second is G.711 mu-law with extended dtmf events, and
the base media-level attributes are to be deleted. Intermixing of the base media-level attributes are to be deleted. Intermixing of
G.729, G.711, and "commercial" dtmf events is least preferred (the G.729, G.711, and "commercial" dtmf events is least preferred (the
base configuration provided by the "m=" line, which is, by default, base configuration provided by the "m=" line, which is, by default,
the least preferred configuration). The rtpmap and fmtp attributes the least preferred configuration). The rtpmap and fmtp attributes
of the base configuration are replaced by the mcap and mfcap of the base configuration are replaced by the rmcap and mfcap
attributes when invoked by the proposed configuration. 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
types by means of the payload type number parameter (pt=) in the types by means of the payload type number parameter (pt=) in the
appropriate potential or latent configuration. For example, the appropriate potential or latent configuration. For example, the
following SDP fragment defines a potential configuration with following SDP fragment defines a potential configuration with
redundant G.711 mu-law: redundant G.711 mu-law:
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=rmcap:1 PCMU/8000
a=mcap:2 RED/8000 a=rmcap:2 RED/8000
a=mfcap:2 0/0 a=mfcap:2 0/0
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. When an mfcap, mscap, or acap attribute is processed, its rule. When an mfcap, mscap, or acap attribute is processed, its
arguments will be scanned for a payload type number escape sequences arguments will be scanned for a payload type number escape sequences
of the following form (in ABNF): of the following form (in ABNF):
ptn-esc = "%m=" media-cap-num "%" ; defined in 3.3.1 ptn-esc = "%m=" media-cap-num "%" ; defined in 3.3.1
If the sequence is found, the sequence is replaced by the payload If the sequence is found, the sequence is replaced by the payload
type number assigned to the media capability number, as specified by type number assigned to the media capability number, as specified by
the pt= parameter in the selected potential configuration. The the pt= parameter in the selected potential configuration; only
sequence "%%" (null digit string) is replaced by a single percent actual payload type numbers are supported - wildcards are excluded.
The sequence "%%" (null digit string) is replaced by a single percent
sign and processing continues with the next character, if any. sign and processing continues with the next character, if any.
For example, the above offer sequence could have been written as For example, the above offer sequence could have been written as
m=audio 45678 RTP/AVP 0 m=audio 45678 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=mcap:1 PCMU/8000 a=rmcap:1 PCMU/8000
a=mcap:2 RED/8000 a=rmcap:2 RED/8000
a=mfcap:2 %m=1%/%m=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. and the equivalent SDP is the same as above.
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
skipping to change at page 27, line 35 skipping to change at page 28, line 35
negotiation, and session configurations are offered, it MUST accept negotiation, and session configurations are offered, it MUST accept
one of the offered configurations, or it MUST refuse the session. one of the offered configurations, or it MUST refuse the session.
Therefore, if the offer includes any session capabilities, it SHOULD Therefore, if the offer includes any session capabilities, it SHOULD
include all the session capabilities the offerer is willing to include all the session capabilities the offerer is willing to
support. support.
The session capability attribute is described by: 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 value 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
[1*WSP optional-configs] [1*WSP optional-configs]
session-num = 1*DIGIT ; defined in RFC5234 session-num = 1*10(DIGIT) ; defined in RFC5234
list-of-configs = alt-config *["," alt-config] list-of-configs = alt-config *["," alt-config]
optional-configs = "[" list-of-configs "]" optional-configs = "[" list-of-configs "]"
alt-config = config-number *["|" config-number] alt-config = config-number *["|" config-number]
; config-number defined in RFC5939 ; 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 [RFC5939]. 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 MUST be numbers assigned to potential and latent configurations MUST be
unique across the entire session; [RFC5939] 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 (offering audio, two H.263 video streams and BFCP)- the
empty lines are added for readability only (not part of valid 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.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
a=creq:med-v0 a=creq:med-v0
a=sescap:2 1,2,3,5 a=sescap:2 1,2,3,5
a=sescap:1 1,4 a=sescap:1 1,4
m=audio 54322 RTP/AVP 0 m=audio 54322 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=pcfg:1 a=pcfg:1
m=video 22344 RTP/AVP 102 m=video 22344 RTP/AVP 102
a=rtpmap:102 H263-1998/90000 a=rtpmap:102 H263-1998/90000
a=fmtp:102 CIF=4;QCIF=2;F=1;K=1 a=fmtp:102 CIF=4;QCIF=2;F=1;K=1
i= main video stream i= main video stream
a=label:11 a=label:11
a=pcfg:2 a=pcfg:2
a=mcap:1 H264/90000 a=rmcap:1 H264/90000
a=mfcap:1 profile-level-id=42A01E; packetization-mode=2 a=mfcap:1 profile-level-id=42A01E; packetization-mode=2
a=acap:1 label:13 a=acap:1 label:13
a=pcfg:4 m=1 a=1 pt=1:104 a=pcfg:4 m=1 a=1 pt=1:104
m=video 33444 RTP/AVP 103 m=video 33444 RTP/AVP 103
a=rtpmap:103 H263-1998/90000 a=rtpmap:103 H263-1998/90000
a=fmtp:103 CIF=4;QCIF=2;F=1;K=1 a=fmtp:103 CIF=4;QCIF=2;F=1;K=1
i= secondary video (slides) i= secondary video (slides)
a=label:12 a=label:12
a=pcfg:3 a=pcfg:3
m=application 33002 TCP/BFCP * m=application 33002 TCP/BFCP *
a=setup:passive a=setup:passive
a=connection:new a=connection:new
a=floorid:1 m-stream:11 12 a=floorid:1 m-stream:11 12
a=floor-control:s-only a=floor-control:s-only
a=confid:4321 a=confid:4321
a=userid:1234 a=userid:1234
a=pcfg:5 a=pcfg:5
If the answerer understands MediaCapNeg, but cannot support the If the answerer understands MediaCapNeg, but cannot support the
skipping to change at page 28, line 52 skipping to change at page 30, line 8
m=application 33002 TCP/BFCP * m=application 33002 TCP/BFCP *
a=setup:passive a=setup:passive
a=connection:new a=connection:new
a=floorid:1 m-stream:11 12 a=floorid:1 m-stream:11 12
a=floor-control:s-only a=floor-control:s-only
a=confid:4321 a=confid:4321
a=userid:1234 a=userid:1234
a=pcfg:5 a=pcfg:5
If the answerer understands MediaCapNeg, but cannot support the If the answerer understands MediaCapNeg, but cannot support the
Binary Floor Control Protocol, then it would respond with: Binary Floor Control Protocol, then it would respond with (invalid
empty lines in SDP included again for readability):
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=cusp:med-v0 a=csup:med-v0
a=sescap:1 1,4 a=sescap:1 1,4
m=audio 23456 RTP/AVP 0 m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=acfg:1 a=acfg:1
m=video 41234 RTP/AVP 104 m=video 41234 RTP/AVP 104
a=rtpmap:100 H264/90000 a=rtpmap:100 H264/90000
a=fmtp:104 profile-level-id=42A01E; packetization-mode=2 a=fmtp:104 profile-level-id=42A01E; packetization-mode=2
a=acfg:4 m=1 a=1 pt=1:104 a=acfg:4 m=1 a=1 pt=1:104
a=pcfg:2
m=video 0 RTP/AVP 103 m=video 0 RTP/AVP 103
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 can include latent capabilities as well. Here's Session capabilities can include latent capabilities as well. Here's
skipping to change at page 29, line 39 skipping to change at page 30, line 48
H.264 or H.263. H.264 or H.263.
Session capabilities can 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=rmcap: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
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=lcfg:3 mt=video t=1 m=1 a=31,32 i=3
a=acap:31 label:12 a=acap:31 label:12
a=acap:32 content:main a=acap:32 content:main
a=lcfg:4 mt=video t=1 m=1 a=41,42 i=4 a=lcfg:4 mt=video t=1 m=1 a=41,42 i=4
a=acap:41 label:13 a=acap:41 label:13
a=acap:42 content:slides a=acap:42 content:slides
a=lcfg:5 mt=application m=51 t=51 a=lcfg:5 mt=application m=51 t=51
a=tcap:51 TCP/BFCP a=tcap:51 TCP/BFCP
a=mcap:51 * a=rmcap:51 *
a=acap:51 setup:passive a=acap:51 setup:passive
a=acap:52 connection:new a=acap:52 connection:new
a=acap:53 floorid:1 m-stream:12 13 a=acap:53 floorid:1 m-stream:12 13
a=acap:54 floor-control:s-only a=acap:54 floor-control:s-only
a=acap:55 confid:4321 a=acap:55 confid:4321
a=acap:56 userid:1234 a=acap:56 userid:1234
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). Note also that the three mcap, mfcap, that establishes the streams). Note also that the three rmcap,
and tcap attributes used by lcfg:3 and lcfg:4 are included at the mfcap, and tcap attributes used by lcfg:3 and lcfg:4 are included at
session level so they may be referenced by both latent the session level so they may be referenced by both latent
configurations. As per Section 3.3, the media attributes generated configurations. As per Section 3.3, the media attributes generated
from the mcap, mfcap, and tcap attributes are always media-level from the rmcap, mfcap, and tcap attributes are always media-level
attributes. If the answerer supports Media CapNeg, and supports the attributes. If the answerer supports Media CapNeg, and supports the
most desired configuration, it would return the following SDP: 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
skipping to change at page 31, line 20 skipping to change at page 32, line 30
a=lcfg:4 mt=video t=1 m=1 a=41,42 a=lcfg:4 mt=video t=1 m=1 a=41,42
a=lcfg:5 mt=application t=2 a=lcfg:5 mt=application t=2
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.
3.4. Offer/Answer Model Extensions 3.4. Offer/Answer Model Extensions
EDITOR'S NOTE: SECTION NEEDS MORE ELABORATE PROCEDURES
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 [RFC5939] 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 [RFC5939] 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 rmcap
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
When an endpoint generates an initial offer and wants to use the When an endpoint generates an initial offer and wants to use the
functionality described in the current document, it should identify functionality described in the current document, it should identify
and define the codecs it can support via mcap, mfcap and mscap and define the codecs it can support via rmcap, mfcap and mscap
attributes. The SDP media line(s) should be made up with the attributes. The SDP media line(s) should be made up with the
configuration to be used if the other party does not understand configuration to be used if the other party does not understand
capability negotiations (by default, this is the least preferred capability negotiations (by default, this is the least preferred
configuration). Typically, the media line configuration will contain configuration). Typically, the media line configuration will contain
the minimum acceptable capabilities. The offer MUST include the the minimum acceptable capabilities. The offer MUST include the
level of capability negotiation extensions needed to support this level of capability negotiation extensions needed to support this
functionality in a "creq" attribute. functionality in a "creq" attribute.
Preferred configurations for each media stream are identified Preferred configurations for each media stream are identified
following the media line. The present offer may also include latent following the media line. The present offer may also include latent
configuration (lcfg) attributes, at the session level, describing configuration (lcfg) attributes, at the media level, describing media
media streams and/or configurations the offerer is not now offering, streams and/or configurations the offerer is not now offering, but
but which it is willing to support in a future offer/answer exchange. which it is willing to support in a future offer/answer exchange. A
A simple example might be the inclusion of a latent video simple example might be the inclusion of a latent video configuration
configuration in an offer for an audio stream. in an offer for an audio stream.
3.4.2. Generating the Answer 3.4.2. Generating the Answer
When the answering party receives the offer and if it supports the When the answering party receives the offer and if it supports the
required capability negotiation extensions, it should select the required capability negotiation extensions, it should select the
most-preferred configuration it can support for each media stream, most-preferred configuration it can support for each media stream,
and build its answer accordingly. The configuration selected for and build its answer accordingly. The configuration selected for
each accepted media stream is placed into the answer as a media line each accepted media stream is placed into the answer as a media line
with associated parameters and attributes. If a proposed with associated parameters and attributes. If a proposed
configuration is chosen, the answer must include the supported configuration is chosen, the answer must include the supported
skipping to change at page 33, line 28 skipping to change at page 35, line 28
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 54322 RTP/AVP 96 m=audio 54322 RTP/AVP 96
rtpmap:96 AMR-WB/16000/1 rtpmap:96 AMR-WB/16000/1
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
a=mcap:1,3,5 audio AMR-WB/16000/1 a=rmcap:1,3,5 audio AMR-WB/16000/1
a=mcap:2,4,6 audio AMR/8000/1 a=rmcap:2,4,6 audio AMR/8000/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
a=pcfg:1 m=1 pt=1:96 a=pcfg:1 m=1 pt=1:96
a=pcfg:2 m=2 pt=2:97 a=pcfg:2 m=2 pt=2:97
a=pcfg:3 m=3 pt=3:98 a=pcfg:3 m=3 pt=3:98
a=pcfg:4 m=4 pt=4:99 a=pcfg:4 m=4 pt=4:99
a=pcfg:5 m=5 pt=5:100 a=pcfg:5 m=5 pt=5:100
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 first mcap declaration and from the corresponding mfcap from the first rmcap declaration and from the corresponding mfcap
attributes, and the pcfg:1 attribute line could have been simply attributes, and the pcfg:1 attribute line could have been 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
skipping to change at page 34, line 19 skipping to change at page 36, line 19
t=0 0 t=0 0
a=creq:med-v0 a=creq:med-v0
a=ice-pwd:speEc3QGZiNWpVLFJhQX a=ice-pwd:speEc3QGZiNWpVLFJhQX
m=video 49170 RTP/AVP 100 m=video 49170 RTP/AVP 100
c=IN IP4 192.0.2.56 c=IN IP4 192.0.2.56
a=maxprate:1000 a=maxprate:1000
a=rtcp:51540 a=rtcp:51540
a=sendonly a=sendonly
a=candidate 12345 1 UDP 9 192.0.2.56 49170 host a=candidate 12345 1 UDP 9 192.0.2.56 49170 host
a=candidate 23456 2 UDP 9 192.0.2.56 51540 host a=candidate 23456 2 UDP 9 192.0.2.56 51540 host
a=candidate 34567 1 UDP 7 10.0.0.1 41345 srflx raddr \ a=candidate 34567 1 UDP 7 198.51.100.1 41345 srflx raddr \
192.0.2.56 rport 49170 192.0.2.56 rport 49170
a=candidate 45678 2 UDP 7 10.0.0.1 52567 srflx raddr \ a=candidate 45678 2 UDP 7 198.51.100.1 52567 srflx raddr \
192.0.2.56 rport 51540 192.0.2.56 rport 51540
a=candidate 56789 1 UDP 3 192.0.2.100 49000 relay raddr \ a=candidate 56789 1 UDP 3 192.0.2.100 49000 relay raddr \
192.0.2.56 rport 49170 192.0.2.56 rport 49170
a=candidate 67890 2 UDP 3 192.0.2.100 49001 relay raddr \ a=candidate 67890 2 UDP 3 192.0.2.100 49001 relay raddr \
192.0.2.56 rport 51540 192.0.2.56 rport 51540
b=AS:10000 b=AS:10000
b=TIAS:10000000 b=TIAS:10000000
b=RR:4000 b=RR:4000
b=RS:3000 b=RS:3000
a=rtpmap:100 H264/90000 a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42A01E; packetization-mode=2; \ a=fmtp:100 profile-level-id=42A01E; packetization-mode=2; \
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==; \ sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==; \
sprop-interleaving-depth=45; sprop-deint-buf-req=64000; \ sprop-interleaving-depth=45; sprop-deint-buf-req=64000; \
sprop-init-buf-time=102478; deint-buf-cap=128000 sprop-init-buf-time=102478; deint-buf-cap=128000
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=mcap:1-3,7-9 H264/90000 a=rmcap:1-3,7-9 H264/90000
a=mcap:4-6 rtx/90000 a=rmcap:4-6 rtx/90000
a=mfcap:1-9 profile-level-id=42A01E a=mfcap:1-9 profile-level-id=42A01E
a=mfcap:1-9 aMljiA== a=mfcap:1-9 aMljiA==
a=mfcap:1,4,7 packetization-mode=0 a=mfcap:1,4,7 packetization-mode=0
a=mfcap:2,5,8 packetization-mode=1 a=mfcap:2,5,8 packetization-mode=1
a=mfcap:3,6,9 packetization-mode=2 a=mfcap:3,6,9 packetization-mode=2
a=mfcap:1-9 sprop-parameter-sets=Z0IACpZTBYmI a=mfcap:1-9 sprop-parameter-sets=Z0IACpZTBYmI
a=mfcap:1,7 sprop-interleaving-depth=45; \ a=mfcap:1,7 sprop-interleaving-depth=45; \
sprop-deint-buf-req=64000; sprop-init-buf-time=102478; \ sprop-deint-buf-req=64000; sprop-init-buf-time=102478; \
deint-buf-cap=128000 deint-buf-cap=128000
a=mfcap:4 apt=100 a=mfcap:4 apt=100
skipping to change at page 35, line 23 skipping to change at page 37, line 23
a=pcfg:8 t=3 m=2,4 pt=2:99,4:96 a=pcfg:8 t=3 m=2,4 pt=2:99,4:96
a=pcfg:9 t=3 m=3,6 pt=3:98,6:95 a=pcfg:9 t=3 m=3,6 pt=3:98,6:95
m=audio 49176 RTP/AVP 101 100 99 98 m=audio 49176 RTP/AVP 101 100 99 98
c=IN IP4 192.0.2.56 c=IN IP4 192.0.2.56
a=ptime:60 a=ptime:60
a=maxptime:200 a=maxptime:200
a=rtcp:51534 a=rtcp:51534
a=sendonly a=sendonly
a=candidate 12345 1 UDP 9 192.0.2.56 49176 host a=candidate 12345 1 UDP 9 192.0.2.56 49176 host
a=candidate 23456 2 UDP 9 192.0.2.56 51534 host a=candidate 23456 2 UDP 9 192.0.2.56 51534 host
a=candidate 34567 1 UDP 7 10.0.0.1 41348 srflx \ a=candidate 34567 1 UDP 7 198.51.100.1 41348 srflx \
raddr 192.0.2.56 rport 49176 raddr 192.0.2.56 rport 49176
a=candidate 45678 2 UDP 7 10.0.0.1 52569 srflx \ a=candidate 45678 2 UDP 7 198.51.100.1 52569 srflx \
raddr 192.0.2.56 rport 51534 raddr 192.0.2.56 rport 51534
a=candidate 56789 1 UDP 3 192.0.2.100 49002 relay \ a=candidate 56789 1 UDP 3 192.0.2.100 49002 relay \
raddr 192.0.2.56 rport 49176 raddr 192.0.2.56 rport 49176
a=candidate 67890 2 UDP 3 192.0.2.100 49003 relay \ a=candidate 67890 2 UDP 3 192.0.2.100 49003 relay \
raddr 192.0.2.56 rport 51534 raddr 192.0.2.56 rport 51534
b=AS:512 b=AS:512
b=TIAS:512000 b=TIAS:512000
b=RR:4000 b=RR:4000
b=RS:3000 b=RS:3000
a=maxprate:120 a=maxprate:120
a=rtpmap:98 AMR-WB/16000 a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1; mode-change-capability=2 a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 AMR-WB/16000 a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2 a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2
a=rtpmap:100 AMR-WB/16000/2 a=rtpmap:100 AMR-WB/16000/2
a=fmtp:100 octet-align=1; interleaving=30 a=fmtp:100 octet-align=1; interleaving=30
a=rtpmap:101 AMR-WB+/72000/2 a=rtpmap:101 AMR-WB+/72000/2
a=fmtp:101 interleaving=50; int-delay=160000; a=fmtp:101 interleaving=50; int-delay=160000;
a=mcap:14 ac3/48000/6 a=rmcap:14 ac3/48000/6
a=acap:23 crypto:1 AES_CM_128_HMAC_SHA1_80 \ a=acap:23 crypto:1 AES_CM_128_HMAC_SHA1_80 \
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
a=tcap:4 RTP/SAVP a=tcap:4 RTP/SAVP
a=pcfg:10 t=4 a=23 a=pcfg:10 t=4 a=23
a=pcfg:11 t=4 m=14 a=23 pt=14:102 a=pcfg:11 t=4 m=14 a=23 pt=14:102
This offer illustrates the advantage in compactness that arises if This offer illustrates the advantage in compactness that arises if
one can avoid deleting the base configuration attributes and one can avoid deleting the base configuration attributes and
recreating them in acap attributes for the potential configurations. recreating them in acap attributes for the potential configurations.
skipping to change at page 36, line 26 skipping to change at page 38, line 26
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 2,4 a=sescap:1 2,4
a=sescap:2 1,3 a=sescap:2 1,3
m=audio 54322 RTP/AVP 18 m=audio 54322 RTP/AVP 18
a=rtpmap:18 G729/8000 a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes a=fmtp:18 annexb=yes
a=mcap:1 PCMU/8000 a=rmcap:1 PCMU/8000
a=pcfg:1 m=1 pt=1:0 a=pcfg:1 m=1 pt=1:0
a=pcfg:2 a=pcfg:2
m=video 54344 RTP/AVP 100 m=video 54344 RTP/AVP 100
a=rtpmap:100 H263-1998/90000 a=rtpmap:100 H263-1998/90000
a=mcap:2 H264/90000 a=rmcap:2 H264/90000
a=mfcap:2 profile-level-id=42A01E; packetization-mode=2 a=mfcap:2 profile-level-id=42A01E; packetization-mode=2
a=pcfg:3 m=2 pt=2:101 a=pcfg:3 m=2 pt=2:101
a=pcfg:4 a=pcfg:4
Note that the preferred session configuration (and the default as Note that the preferred session configuration (and the default as
well) is G.729B with H.263. This overrides the individual media well) is G.729B with H.263. This overrides the individual media
stream preferences which are PCMU and H.264 by the potential stream preferences which are PCMU and H.264 by the potential
configuration numbering rule. configuration numbering rule.
4.3. Latent Media Streams 4.3. Latent Media Streams
skipping to change at page 37, line 13 skipping to change at page 39, line 13
following: 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=
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 23456 RTP/AVP 0 m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=mcap:1 PCMU/8000 a=rmcap:1 PCMU/8000
a=mcap:2 g729/8000 a=rmcap:2 g729/8000
a=mcap:3 telephone-event/8000 a=rmcap:3 telephone-event/8000
a=mfcap:3 0-11 a=mfcap:3 0-11
a=pcfg:1 m=1,3|2,3 pt=1:0,2:18,3:100 a=lcfg:10 mt=video t=1 a=pcfg:1 m=1,3|2,3 pt=1:0,2:18,3:100 a=lcfg:10 mt=video t=1
m=10|11 m=10|11
a=mcap:10 H263-1998/90000 a=rmcap:10 H263-1998/90000
a=mcap:11 H264/90000 a=rmcap:11 H264/90000
a=tcap:1 RTP/AVP a=tcap:1 RTP/AVP
The lcfg attribute line announces support for H.263 and H.264 video The lcfg attribute line announces support for H.263 and H.264 video
(H.263 preferred) for future reference. The m-line and the rtpmap (H.263 preferred) for future reference. The m-line and the rtpmap
attribute offer an audio stream and provide the lowest precedence attribute offer an audio stream and provide the lowest precedence
configuration (PCMU without any DTMF encoding). The mcap lines configuration (PCMU without any DTMF encoding). The rmcap lines
define the media capabilities (PCMU, G729, and telephone-event) to be define the media capabilities (PCMU, G729, and telephone-event) to be
offered in potential configurations. The mfcap attribute provides offered in potential configurations. The mfcap attribute provides
the format parameters for telephone-events, specifying the 12 the format parameters for telephone-events, specifying the 12
commercial DTMF 'digits'. The pcfg attribute line defines the most- commercial DTMF 'digits'. The pcfg attribute line defines the most-
preferred media configuration as PCMU plus DTMF events and the next- preferred media configuration as PCMU plus DTMF events and the next-
most-preferred configuration as G.729B plus DTMF events. 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:
skipping to change at page 39, line 12 skipping to change at page 41, line 12
reconfiguration of the media stream to use G.729 in order to reduce reconfiguration of the media stream to use G.729 in order to reduce
packet sizes. 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: rmcap
Long form name: media capability Long form name: RTP-based 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 RTP-based media capability number(s)
with
media subtype and encoding parameters
Appropriate Values: see Section 3.3.1
Attribute name: omcap
Long form name: Non RTP-based media capability
Type of attribute: session-level and media-level
Subject to charset: no
Purpose: associate non RTP-based media capability number(s)
with
media subtype and encoding parameters media subtype and encoding parameters
Appropriate Values: see 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 3.3.2 Appropriate Values: see Section 3.3.2
skipping to change at page 41, line 7 skipping to change at page 43, line 7
Potential Configuration Parameter Registry established by [RFC5939] 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
EDITOR'S NOTE: SECTION NEEDS TO BE EXPANDED
The security considerations of [RFC5939] 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 10 7.1. Changes from version 11
o Corrected several statements implying lcfg was a session-level
attribute.
o Added non-RTP based media format capabilities ("a=omcap") and
renamed "mcap" to "rmcap"
7.2. Changes from version 10
o Defined the latent configuration attribute as a media-level o Defined the latent configuration attribute as a media-level
attribute because it specifies a possible future media stream. attribute because it specifies a possible future media stream.
Added text to clarify how to specify alternative configurations of Added text to clarify how to specify alternative configurations of
a single latent stream and/or multiple streams. a single latent stream and/or multiple streams.
o Improved the definition of the session capability attribute to o Improved the definition of the session capability attribute to
permit both required configurations and optional configurations - permit both required configurations and optional configurations -
latent configurations cannot be required because they have not yet latent configurations cannot be required because they have not yet
been offered. been offered.
skipping to change at page 42, line 35 skipping to change at page 44, line 43
o Changed various "must", etc., terms to normative terms ("MUST", o Changed various "must", etc., terms to normative terms ("MUST",
etc.) as appropriate, in Section 3.3.5Section 3.3.6.1 etc.) as appropriate, in Section 3.3.5Section 3.3.6.1
Section 3.3.6.3 and Section 3.3.8 Section 3.3.6.3 and Section 3.3.8
o Attempted to clarify the substitution mechanism in Section 3.3.7 o Attempted to clarify the substitution mechanism in Section 3.3.7
and improve its uniqueness. and improve its uniqueness.
o Made various editorial changes, including changing the title in o Made various editorial changes, including changing the title in
the header, and removing numbering from some SDP examples. the header, and removing numbering from some SDP examples.
7.2. Changes from version 09 7.3. 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.3. Changes from version 08 7.4. Changes from version 08
The major change is in Section 4.3, Latent Media Streams, fixing the The major change is in Section 4.3, Latent Media Streams, fixing the
syntax of the answer. All the other changes are editorial. syntax of the answer. All the other changes are editorial.
7.4. Changes from version 04 7.5. 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 [RFC5939] 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 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.5. Changes from version 03 7.6. Changes from version 03
o A new session capability attribute (sescap) has been added to o A new session capability attribute (sescap) has been added to
permit specification of acceptable media stream combinations. permit specification of acceptable media stream combinations.
o Capability attribute definitions corresponding to the i, c, b, and o Capability attribute definitions corresponding to the i, c, b, and
k SDP line types have been added for completeness. k SDP line types have been added for completeness.
o Use of the pcfg: attribute in SDP answers has been included in o Use of the pcfg: attribute in SDP answers has been included in
order to conveniently return information in the answer about order to conveniently return information in the answer about
acceptable configurations in the media stream offer. acceptable configurations in the media stream offer.
skipping to change at page 44, line 8 skipping to change at page 46, line 17
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.6. Changes from version 02 7.7. 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 38 skipping to change at page 46, line 47
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.7. Changes from version 01 7.8. 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.8. Changes from version 00 7.9. Changes from version 00
The major changes include taking out the "mcap" and "cptmap" The major changes include taking out the "mcap" and "cptmap"
parameter. The mapping of payload type is now in the "pt" parameter parameter. The mapping of payload type is now in the "pt" parameter
of "pcfg". Media subtype need to explictly definesd in the "cmed" of "pcfg". Media subtype need to explictly definesd in the "cmed"
attribute if referenced in the "pcfg" attribute if referenced in the "pcfg"
8. Acknowledgements 8. Acknowledgements
This document is heavily influenced by the discussions and work done This document is heavily influenced by the discussions and work done
by the SDP Capability Negotiation Design team. The following people by the SDP Capability Negotiation Design team. The following people
skipping to change at page 47, line 25 skipping to change at page 50, line 25
Roni Even Roni Even
Gesher Erove Ltd Gesher Erove Ltd
14 David Hamelech 14 David Hamelech
Tel Aviv 64953 Tel Aviv 64953
Israel Israel
Email: ron.even.tlv@gmail.com Email: ron.even.tlv@gmail.com
Flemming Andreasen Flemming Andreasen
Cisco Systems Cisco Systems
Edison, NJ Iselin, NJ
USA USA
Email: fandreas@cisco.com Email: fandreas@cisco.com
 End of changes. 126 change blocks. 
271 lines changed or deleted 349 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/