Internet Engineering Task Force (IETF) R. Gilman
Request for Comments: 6871 Independent
Updates: 5939 R. Even
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 F. Andreasen
February 2013 Session Description Protocol (SDP) Media Capabilities Negotiation
Session Description Protocol (SDP) capability negotiation provides a
general framework for indicating and negotiating capabilities in SDP.
The base framework defines only capabilities for negotiating
transport protocols and attributes. This documents extends the
framework by defining media capabilities that can be used to
negotiate media types and their associated parameters.
This document updates the IANA Considerations of RFC 5939.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
Table of Contents
1. Introduction ....................................................42. Terminology .....................................................43. SDP Media Capabilities ..........................................63.1. Requirements ...............................................63.2. Solution Overview ..........................................73.3. New Capability Attributes .................................133.3.1. The Media Format Capability Attributes .............133.3.2. The Media Format Parameter Capability Attribute ....163.3.3. The Media-Specific Capability Attribute ............193.3.4. New Configuration Parameters .......................213.3.5. The Latent Configuration Attribute .................233.3.6. Enhanced Potential Configuration Attribute .........253.3.7. Substitution of Media Payload Type Numbers
in Capability ......................................293.3.8. The Session Capability Attribute ...................303.4. Offer/Answer Model Extensions .............................353.4.1. Generating the Initial Offer .......................353.4.2. Generating the Answer ..............................393.4.3. Offerer Processing of the Answer ...................433.4.4. Modifying the Session ..............................434. Examples .......................................................444.1. Alternative Codecs ........................................444.2. Alternative Combinations of Codecs (Session
Configurations) ...........................................474.3. Latent Media Streams ......................................475. IANA Considerations ............................................495.1. New SDP Attributes ........................................495.2. New SDP Capability Negotiation Option Tag .................505.3. SDP Capability Negotiation Configuration
Parameters Registry .......................................505.4. SDP Capability Negotiation Configuration Parameter
Registrations .............................................526. Security Considerations ........................................527. Acknowledgements ...............................................538. References .....................................................548.1. Normative References ......................................548.2. Informative References ....................................54
"Session Description Protocol (SDP) Capability Negotiation" [RFC5939]
provides a general framework for indicating and negotiating
capabilities in SDP [RFC4566]. The base framework defines only
capabilities for negotiating transport protocols and attributes.
RFC 5939 [RFC5939] lists some of the issues with the current SDP
capability negotiation process. An additional real-life problem is
to be able to offer one media stream (e.g., audio) but list the
capability to support another media stream (e.g., video) without
actually offering it concurrently.
In this document, we extend the framework by defining media
capabilities that can be used to indicate and negotiate media types
and their associated format parameters. This document also adds the
ability to declare support for media streams, the use of which can be
offered and negotiated later, and the ability to specify session
configurations as combinations of media stream configurations. The
definitions of new attributes for media capability negotiation are
chosen to make the translation from these attributes to
"conventional" SDP [RFC4566] media attributes as straightforward as
possible in order to simplify implementation. This goal is intended
to reduce processing in two ways: each proposed configuration in an
offer may be easily translated into a conventional SDP media stream
record for processing by the receiver and the construction of an
answer based on a selected proposed configuration would be
This document updates RFC 5939 [RFC5939] by updating the IANA
considerations. All other extensions defined in this document are
considered extensions above and beyond RFC 5939 [RFC5939].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations.
Actual Configuration: An actual configuration specifies which
combinations of SDP session parameters and media stream components
can be used in the current offer/answer exchange and with what
parameters. Use of an actual configuration does not require any
further negotiation in the offer/answer exchange. See RFC 5939
[RFC5939] for further details.
Base Attributes: Conventional SDP attributes appearing in the base
configuration of a media block.
Base Configuration: The media configuration represented by a media
block exclusive of all the capability negotiation attributes defined
in this document, the base capability negotiation document [RFC5939],
or any other capability negotiation document. In an offer SDP, the
base configuration corresponds to the actual configuration as defined
in RFC 5939 [RFC5939].
Conventional Attribute: Any SDP attribute other than those defined by
the series of capability negotiation specifications.
Conventional SDP: An SDP record devoid of capability negotiation
Media Format Capability: A media format, typically a media subtype
such as PCMU, H263-1998, or T38, expressed in the form of a
Media Format Parameter Capability: A media format parameter ("a=fmtp"
in conventional SDP) expressed in the form of a capability. The
media format parameter capability is associated with a media format
Media Capability: The combined set of capabilities associated with
expressing a media format and its relevant parameters (e.g., media
format parameters and media specific parameters).
Potential Configuration: A potential configuration indicates which
combinations of capabilities can be used for the session and its
associated media stream components. Potential configurations are not
ready for use; however, they are offered for potential use in the
current offer/answer exchange. They provide an alternative that may
be used instead of the actual configuration, subject to negotiation
in the current offer/answer exchange. See RFC 5939 [RFC5939] for
Latent Configuration: A latent configuration indicates which
combinations of capabilities could be used in a future negotiation
for the session and its associated media stream components. Latent
configurations are neither ready for use nor offered for actual or
potential use in the current offer/answer exchange. Latent
configurations merely inform the other side of possible
configurations supported by the entity. Those latent configurations
may be used to guide subsequent offer/answer exchanges, but they are
not offered for use as part of the current offer/answer exchange.
3. SDP Media Capabilities
The SDP capability negotiation [RFC5939] discusses the use of any SDP
[RFC4566] attribute (a=) under the attribute capability "acap". The
limitations of using "acap" for "fmtp" and "rtpmap" in a potential
configuration are described in RFC 5939 [RFC5939]; for example, they
can be used only at the media level since they are media-level
attributes. RFC 5939 [RFC5939] does not provide a way to exchange
media-level capabilities prior to the actual offer of the associated
media stream. This section provides an overview of extensions
providing an SDP media capability negotiation solution offering more
robust capabilities negotiation. This is followed by definitions of
new SDP attributes for the solution and its associated updated
offer/answer procedures [RFC3264].
The capability negotiation extensions requirements considered herein
are as follows.
REQ-01: Support the specification of alternative (combinations of)
media formats (codecs) in a single media block.
REQ-02: Support the specification of alternative media format
parameters for each media format.
REQ-03: Retain backward compatibility with conventional SDP. Ensure
that each and every offered configuration can be easily
translated into a corresponding SDP media block expressed
with conventional SDP lines.
REQ-04: Ensure that the scheme operates within the offer/answer
model in such a way that media formats and parameters can be
agreed upon with a single exchange.
REQ-05: Provide the ability to express offers in such a way that the
offerer can receive media as soon as the offer is sent.
(Note that the offerer may not be able to render received
media prior to exchange of keying material.)
REQ-06: Provide the ability to offer latent media configurations for
REQ-07: Provide reasonable efficiency in the expression of
alternative media formats and/or format parameters,
especially in those cases in which many combinations of
options are offered.
REQ-08: Retain the extensibility of the base capability negotiation
REQ-09: Provide the ability to specify acceptable combinations of
media streams and media formats. For example, offer a PCMU
audio stream with an H264 video stream or a G729 audio
stream with an H263 video stream. This ability would give
the offerer a means to limit processing requirements for
simultaneous streams. This would also permit an offer to
include the choice of an audio/T38 stream or an image/T38
stream, but not both.
Other possible extensions have been discussed, but have not been
treated in this document. They may be considered in the future.
Three such extensions are:
FUT-01: Provide the ability to mix, or change, media types within a
single media block. Conventional SDP does not support this
capability explicitly; the usual technique is to define a
media subtype that represents the actual format within the
nominal media type. For example, T.38 FAX as an alternative
to audio/PCMU within an audio stream is identified as
audio/T38; a separate FAX stream would use image/T38.
FUT-02: Provide the ability to support multiple transport protocols
within an active media stream without reconfiguration. This
is not explicitly supported by conventional SDP.
FUT-03: Provide capability negotiation attributes for all media-
level SDP line types in the same manner as already done for
the attribute type, with the exception of the media line
type itself. The media line type is handled in a special
way to permit compact expression of media coding/format
options. The line types are bandwidth ("b="), information
("i="), connection data ("c="), and, possibly, the
deprecated encryption key ("k=").
3.2. Solution Overview
The solution consists of new capability attributes corresponding to
conventional SDP line types, new parameters for the "pcfg", "acfg",
and the new "lcfg" attributes extending the base attributes from RFC
5939 [RFC5939], and a use of the "pcfg" attribute to return
capability information in the SDP answer.
Several new attributes are defined in a manner that can be related to
the capabilities specified in a media line, and its corresponding
"rtpmap" and "fmtp" attributes.
o A new attribute ("a=rmcap") defines RTP-based media format
capabilities in the form of a media subtype (e.g., "PCMU"), and
its encoding parameters (e.g., "/8000/2"). Each resulting media
format type/subtype capability has an associated handle called a
media capability number. The encoding parameters are as specified
for the "rtpmap" attribute defined in SDP [RFC4566], without the
payload type number part.
o A new attribute ("a=omcap") defines other (non-RTP-based) media
format 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
associated with one or more media format capabilities. The
"mfcap" attribute is used primarily to associate the media format
parameters normally carried in the "fmtp" attribute. Note that
media format parameters can be used with RTP and non-RTP-based
o A new attribute ("a=mscap") specifies media parameters associated
with one or more media format capabilities. The "mscap" attribute
is used to associate capabilities with attributes other than
"fmtp" or "rtpmap", for example, the "rtcp-fb" attribute defined
in RFC 4585 [RFC4585].
o A new attribute ("a=lcfg") specifies latent media stream
configurations when no corresponding media line ("m=") is offered.
An example is the offer of latent configurations for video even
though no video is currently offered. If the peer indicates
support for one or more offered latent configurations, the
corresponding media stream(s) may be added via a new offer/answer
o A new attribute ("a=sescap") is used to specify an acceptable
combination of simultaneous media streams and their configurations
as a list of potential and/or latent configurations.
New parameters are defined for the potential configuration ("pcfg"),
latent configuration ("lcfg"), and accepted configuration ("acfg")
attributes to associate the new attributes with particular
o A new parameter type ("m=") is added to the potential
configuration ("a=pcfg:") attribute and the actual configuration
("a=acfg:") attribute defined in RFC 5939 [RFC5939] and to the new
latent configuration ("a=lcfg:") attribute. This permits
specification of media capabilities (including their associated
parameters) and combinations thereof for the configuration. For
example, the "a=pcfg:" line might specify PCMU and telephone
events [RFC4733] or G.729B and telephone events as acceptable
configurations. The "a=acfg:" line in the answer would specify
the configuration chosen.
o A new parameter type ("pt=") is added to the potential
configuration, actual configuration, and latent configuration
attributes. This parameter associates RTP payload type numbers
with the referenced RTP-based media format capabilities and is
appropriate only when the transport protocol uses RTP.
o A new parameter type ("mt=") is used to specify the media type for
Special processing rules are defined for capability attribute
arguments in order to reduce the need to replicate essentially
identical attribute lines for the base configuration and potential
o A substitution rule is defined for any capability attribute to
permit the replacement of the (escaped) media capability number
with the media format identifier (e.g., the payload type number in
o Replacement rules are defined for the conventional SDP equivalents
of the "mfcap" and "mscap" capability attributes. This reduces
the necessity to use the deletion qualifier in the "a=pcfg"
parameter in order to ignore "rtpmap", "fmtp", and certain other
attributes in the base configuration.
o An argument concatenation rule is defined for "mfcap" attributes
that refer to the same media capability number. This makes it
convenient to combine format options concisely by associating
multiple mfcap lines with multiple media format capabilities.
This document extends the base protocol extensions to the
offer/answer model that allow for capabilities and potential
configurations to be included in an offer. Media capabilities
constitute capabilities that can be used in potential and latent
configurations. Whereas potential configurations constitute
alternative offers that may be accepted by the answerer instead of
the actual configuration(s) included in the "m=" line(s) and
associated parameters, latent configurations merely inform the other
side of possible configurations supported by the entity. Those
latent configurations may be used to guide subsequent offer/answer
exchanges, but they are not part of the current offer/answer
The mechanism is illustrated by the offer/answer exchange below,
where Alice sends an offer to Bob:
| (1) Offer (SRTP and RTP) |
| (2) Answer (RTP) |
Alice's offer includes RTP and Secure Real-time Transport Protocol
(SRTP) as alternatives. RTP is the default, but SRTP is the
preferred one (long lines are folded to fit the margins):
o=- 25678 753849 IN IP4 192.0.2.1
c=IN IP4 192.0.2.1
m=audio 3456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP RTP/AVP
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 \
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:3 m=4 t=2 pt=4:18
The required base and extensions are provided by the "a=creq"
attribute defined in RFC 5939 [RFC5939], with the option tag
"med-v0", which indicates that the extension framework defined here
must be supported. The base-level capability negotiation support
("cap-v0" [RFC5939]) is implied since it is required for the
The "m=" line indicates that Alice is offering to use plain RTP with
PCMU or G.729B. The media line implicitly defines the default
transport protocol (RTP/AVP in this case) and the default actual
The "a=tcap:1" line, specified in the SDP capability negotiation base
protocol [RFC5939], defines transport protocol capabilities, in this
case Secure RTP (SAVP profile) as the first option and RTP (AVP
profile) as the second option.
The "a=rmcap:1,4" line defines two G.729 RTP-based media format
capabilities, numbered 1 and 4, and their encoding rate. The
capabilities are of media type "audio" and subtype G729. Note that
the media subtype is explicitly specified here, rather than RTP
payload type numbers. This permits the assignment of payload type
numbers in the media stream configuration specification. In this
example, two G.729 subtype capabilities are defined. This permits
the declaration of two sets of formatting parameters for G.729.
The "a=rmcap:2" line defines a G.711 mu-law capability, numbered 2.
The "a=rmcap:5" line defines an audio telephone-event capability,
The "a=mfcap:1" line specifies the "fmtp" formatting parameters for
capability 1 (offerer will not accept G.729 Annex B packets).
The "a=mfcap:4" line specifies the "fmtp" formatting parameters for
capability 4 (offerer will accept G.729 Annex B packets).
The "a=mfcap:5" line specifies the "fmtp" formatting parameters for
capability 5 (the dual-tone multi-frequency (DTMF) touchtones
The "a=acap:1" line specified in the base protocol provides the
"crypto" attribute that provides the keying material for SRTP using
SDP security descriptions.
The "a=pcfg:" attributes provide the potential configurations
included in the offer by reference to the media capabilities,
transport capabilities, attribute capabilities, and specified payload
type number mappings. Three explicit alternatives are provided; the
lowest-numbered one is the preferred one. The "a=pcfg:1 ..." line
specifies media capabilities 4 and 5, i.e., G.729B and DTMF
(including their associated media format parameters), or media
capability 1 and 5, i.e., G.729 and DTMF (including their associated
media format parameters). Furthermore, it specifies transport
protocol capability 1 (i.e., the RTP/SAVP profile - secure RTP), and
the attribute capability 1, i.e., the "crypto" attribute provided.
Last, it specifies a payload type number mapping for (RTP-based)
media capabilities 1, 4, and 5, thereby permitting the offerer to
distinguish between encrypted media and unencrypted media received
prior to receipt of the answer.
Use of unique payload type numbers in alternative configurations is
not required; codecs such as Adaptive Multi-Rate Wideband (AMR-WB)
[RFC4867] have the potential for so many combinations of options that
it may be impractical to define unique payload type numbers for all
supported combinations. If unique payload type numbers cannot be
specified, then the offerer will be obliged to wait for the SDP
answer before rendering received media. For SRTP using Security
Descriptions (SDES) inline keying [RFC4568], the offerer will still
need to receive the answer before being able to decrypt the stream.
The second alternative ("a=pcfg:2 ...") specifies media capability 2,
i.e., PCMU, under the RTP/SAVP profile, with the same SRTP key
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
Per RFC 5939 [RFC5939], the media line, with any qualifying
attributes such as "fmtp" or "rtpmap", is itself considered a valid
configuration (the current actual configuration); it has the lowest
preference (per RFC 5939 [RFC5939]).
Bob receives the SDP offer from Alice. Bob supports G.729B, PCMU,
and telephone events over RTP, but not SRTP, hence he accepts the
potential configuration 3 for RTP provided by Alice. Bob generates
the following answer:
o=- 24351 621814 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
m=audio 4567 RTP/AVP 18
a=acfg:3 m=4 t=2 pt=4:18
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
negotiations. Note that in this particular example, the answerer
supported the capability extensions defined here; however, had he
not, he would simply have processed the offer based on the offered
PCMU and G.729 codecs under the RTP/AVP profile only. Consequently,
the 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 accepted configuration in the "m=" line along with corresponding
"rtpmap" and/or "fmtp" parameters, as appropriate.
Note that per the base protocol, after the above, Alice MAY generate
a new offer with an actual configuration ("m=" line, etc.)
corresponding to the actual configuration referenced in Bob's answer
(not shown here).