Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6871

Session Description Protocol (SDP) Media Capabilities Negotiation

Pages: 55
Proposed Standard
Updates:  5939
Part 1 of 4 – Pages 1 to 13
None   None   Next

Top   ToC   RFC6871 - Page 1
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.
Top   ToC   RFC6871 - Page 2
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.
Top   ToC   RFC6871 - Page 3

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
Top   ToC   RFC6871 - Page 4

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.
Top   ToC   RFC6871 - Page 5
   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.
Top   ToC   RFC6871 - Page 6

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.
Top   ToC   RFC6871 - Page 7
   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.
Top   ToC   RFC6871 - Page 8
   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
Top   ToC   RFC6871 - Page 9
      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.
Top   ToC   RFC6871 - Page 10
   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
Top   ToC   RFC6871 - Page 11
   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)
Top   ToC   RFC6871 - Page 12
   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
Top   ToC   RFC6871 - Page 13
   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)

Next Section