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 Negotiation Abstract 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).