RFC 6871
Session Description Protocol (SDP) Media Capabilities Negotiation
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 Cisco Systems February 2013 Session Description Protocol (SDP) Media Capabilities NegotiationAbstract
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 http://www.rfc-editor.org/info/rfc6871.
Copyright Notice 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 than English.
Table of Contents
1. Introduction ....................................................4 2. Terminology .....................................................4 3. SDP Media Capabilities ..........................................6 3.1. Requirements ...............................................6 3.2. Solution Overview ..........................................7 3.3. New Capability Attributes .................................13 3.3.1. The Media Format Capability Attributes .............13 3.3.2. The Media Format Parameter Capability Attribute ....16 3.3.3. The Media-Specific Capability Attribute ............19 3.3.4. New Configuration Parameters .......................21 3.3.5. The Latent Configuration Attribute .................23 3.3.6. Enhanced Potential Configuration Attribute .........25 3.3.7. Substitution of Media Payload Type Numbers in Capability ......................................29 3.3.8. The Session Capability Attribute ...................30 3.4. Offer/Answer Model Extensions .............................35 3.4.1. Generating the Initial Offer .......................35 3.4.2. Generating the Answer ..............................39 3.4.3. Offerer Processing of the Answer ...................43 3.4.4. Modifying the Session ..............................43 4. Examples .......................................................44 4.1. Alternative Codecs ........................................44 4.2. Alternative Combinations of Codecs (Session Configurations) ...........................................47 4.3. Latent Media Streams ......................................47 5. IANA Considerations ............................................49 5.1. New SDP Attributes ........................................49 5.2. New SDP Capability Negotiation Option Tag .................50 5.3. SDP Capability Negotiation Configuration Parameters Registry .......................................50 5.4. SDP Capability Negotiation Configuration Parameter Registrations .............................................52 6. Security Considerations ........................................52 7. Acknowledgements ...............................................53 8. References .....................................................54 8.1. Normative References ......................................54 8.2. Informative References ....................................54
1. Introduction
"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 straightforward. 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].2. Terminology
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 attributes. Media Format Capability: A media format, typically a media subtype such as PCMU, H263-1998, or T38, expressed in the form of a capability. 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 capability. 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 further details. 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].3.1. Requirements
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 future negotiation. 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
mechanism.
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
media formats.
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
exchange.
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
configurations.
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
latent configurations.
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
configurations.
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
audio/video profiles).
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
exchange.
The mechanism is illustrated by the offer/answer exchange below,
where Alice sends an offer to Bob:
Alice 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):
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
m=audio 3456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP RTP/AVP
a=rtpmap:0 PCMU/8000/1
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=yes
a=rmcap:1,4 G729/8000/1
a=rmcap:2 PCMU/8000/1
a=rmcap:5 telephone-event/8000
a=mfcap:1 annexb=no
a=mfcap:4 annexb=yes
a=mfcap:5 0-11
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_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: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
extensions.
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 configuration. 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, numbered 5. 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 0-9,*,#). 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 material. 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 PCMU. 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: v=0 o=- 24351 621814 IN IP4 192.0.2.2 s= c=IN IP4 192.0.2.2 t=0 0 a=csup:med-v0 m=audio 4567 RTP/AVP 18 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes 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).
(page 13 continued on part 2)
