tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5939

 
 
 

Session Description Protocol (SDP) Capability Negotiation

Part 2 of 4, p. 10 to 31
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 10 
3.2.  Solution Overview

   The solution consists of the following:

   o  Two new SDP attributes to support extensions to the framework
      itself as follows:

      o  A new attribute ("a=csup") that lists the supported base
         (optionally) and any supported extension options to the
         framework.

      o  A new attribute ("a=creq") that lists the extensions to the
         framework that are required to be supported by the entity
         receiving the SDP session description in order to do capability
         negotiation.

   o  Two new SDP attributes used to express capabilities as follows
      (additional attributes can be defined as extensions):

      o  A new attribute ("a=acap") that defines how to list an
         attribute name and its associated value (if any) as a
         capability.

      o  A new attribute ("a=tcap") that defines how to list transport
         protocols (e.g., "RTP/AVP") as capabilities.

   o  Two new SDP attributes to negotiate configurations as follows:

      o  A new attribute ("a=pcfg") that lists potential configurations
         supported.  This is done by reference to the capabilities from
         the SDP session description in question.  Extension
         capabilities can be defined and referenced in the potential
         configurations.  Alternative potential configurations have an
         explicit ordering associated with them.  Also, potential
         configurations are by default preferred over the actual
         configuration included in the "m=" line and its associated
         parameters.

         This preference order was chosen to provide maximum backwards
         compatibility for the capability negotiation framework and the
         possible values offered for a session.  For example, an entity
         that wants to establish a Secure RTP media stream but is
         willing to accept a plain RTP media stream (assumed to be the
         least common denominator for most endpoints), can offer plain
         RTP in the actual configuration and use the capability
         negotiation extensions to indicate the preference for Secure
         RTP.  Entities that do not support the capability negotiation
         extensions or Secure RTP will then default to plain RTP.

Top      Up      ToC       Page 11 
      o  A new attribute ("a=acfg") to be used in an answer SDP session
         description.  The attribute identifies a potential
         configuration from an offer SDP session description that was
         used as an actual configuration to form the answer SDP session
         description.  Extension capabilities can be included as well.

   o  Extensions to the offer/answer model that allow for capabilities
      and potential configurations to be included in an offer.
      Capabilities can be provided at the session level and the media
      level.  Potential configurations can be included only at the media
      level, where they 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.  The
      mechanisms defined in this document enable potential
      configurations to change the transport protocol, add new
      attributes, as well as remove all existing attributes from the
      actual configuration.  The answerer indicates which (if any) of
      the potential configurations it used to form the answer by
      including the actual configuration attribute ("a=acfg") in the
      answer.  Capabilities may be included in answers as well, where
      they can aid in guiding a subsequent new offer.

   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 (SRTP)                |
                  |<---------------------------------|
                  |                                  |
                  | (3) Offer (SRTP)                 |
                  |--------------------------------->|
                  |                                  |
                  | (4) Answer (SRTP)                |
                  |<---------------------------------|
                  |                                  |

Top      Up      ToC       Page 12 
   Alice's offer includes RTP and SRTP as alternatives, where RTP is the
   default (actual configuration), but SRTP is the preferred one
   (potential configuration):

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 53456 RTP/AVP 0 18
      a=tcap:1 RTP/SAVP
      a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
         inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
      a=pcfg:1 t=1 a=1

   The "m=" line indicates that Alice is offering to use plain RTP with
   PCMU or G.729.  The capabilities are provided by the "a=tcap" and
   "a=acap" attributes.  The transport capability attribute ("a=tcap")
   indicates that Secure RTP under the AVP profile ("RTP/SAVP") is
   supported with an associated transport capability handle of 1.  The
   "acap" attribute provides an attribute capability with a handle of 1.
   The attribute capability is a "crypto" attribute, which provides the
   keying material for SRTP using SDP security descriptions [RFC4568].
   The "a=pcfg" attribute provides the potential configuration included
   in the offer by reference to the capability parameters.  One
   alternative is provided; it has a configuration number of 1 and it
   consists of transport protocol capability 1 (i.e., the RTP/SAVP
   profile -- Secure RTP), and the attribute capability 1 (i.e., the
   "crypto" attribute provided).  Potential configurations are preferred
   over the actual configuration included in the offer SDP session
   description, and hence Alice is expressing a preference for using
   Secure RTP.

   Bob receives the SDP session description offer from Alice.  Bob
   supports SRTP and the SDP Capability Negotiation framework, and hence
   he accepts the (preferred) potential configuration for Secure RTP
   provided by Alice and generates the following answer SDP session
   description:

      v=0
      o=- 24351 621814 IN IP4 192.0.2.2
      s=
      c=IN IP4 192.0.2.2
      t=0 0
      m=audio 54568 RTP/SAVP 0 18
      a=crypto:1 AES_CM_128_HMAC_SHA1_80
            inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
      a=acfg:1 t=1 a=1

Top      Up      ToC       Page 13 
   Bob includes the "a=acfg" attribute in the answer to inform Alice
   that he based his answer on an offer using potential configuration 1
   with transport protocol capability 1 and attribute capability 1 from
   the offer SDP session description (i.e., the RTP/SAVP profile using
   the keying material provided).  Bob also includes his keying material
   in a "crypto" attribute.  If Bob supported one or more extensions to
   the Capability Negotiation framework, he would have included option
   tags for those in the answer as well (in an "a=csup" attribute).

   When Alice receives Bob's answer, session negotiation has completed;
   however, Alice nevertheless generates a new offer using the
   negotiated configuration as the actual configuration.  This is done
   purely to assist any intermediaries that may reside between Alice and
   Bob but do not support the SDP Capability Negotiation framework, and
   hence may not understand the negotiation that just took place.

   Alice's updated offer includes only SRTP, and it is not using the SDP
   Capability Negotiation framework (Alice could have included the
   capabilities as well if she wanted):

      v=0
      o=- 25678 753850 IN IP4 192.0.2.1
      s=
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 53456 RTP/SAVP 0 18
      a=crypto:1 AES_CM_128_HMAC_SHA1_80
         inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4

   The "m=" line now indicates that Alice is offering to use Secure RTP
   with PCMU or G.729.  The "crypto" attribute, which provides the SRTP
   keying material, is included with the same value again.

   Bob receives the SDP session description offer from Alice, which he
   accepts, and then generates an answer to Alice:

      v=0
      o=- 24351 621815 IN IP4 192.0.2.2
      s=
      c=IN IP4 192.0.2.2
      t=0 0
      m=audio 54568 RTP/SAVP 0 18
      a=crypto:1 AES_CM_128_HMAC_SHA1_80
            inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4

   Bob includes the same "crypto" attribute as before, and the session
   proceeds without change.  Although Bob did not include any
   capabilities in his answer, he could have done so if he wanted.

Top      Up      ToC       Page 14 
   Note that in this particular example, the answerer supported the
   capability negotiation extensions defined here.  Had he not, he would
   simply have ignored the new attributes and accepted the (actual
   configuration) offer to use normal RTP.  In that case, the following
   answer would have been generated instead:

      v=0
      o=- 24351 621814 IN IP4 192.0.2.2
      s=
      c=IN IP4 192.0.2.2
      t=0 0
      m=audio 54568 RTP/AVP 0 18

3.3.  Version and Extension Indication Attributes

   In this section, we present the new attributes associated with
   indicating the SDP Capability Negotiation extensions supported and
   required.

3.3.1.  Supported Capability Negotiation Extensions Attribute

   The SDP Capability Negotiation solution allows for capability
   negotiation extensions to be defined.  Associated with each such
   extension is an option tag that identifies the extension in question.
   Option tags MUST be registered with IANA per the procedures defined
   in Section 6.2.

   The Supported Capability Negotiation Extensions attribute ("a=csup")
   contains a comma-separated list of option tags identifying the SDP
   Capability Negotiation extensions supported by the entity that
   generated the SDP session description.  The attribute can be provided
   at the session level and the media level, and it is defined as
   follows:

      a=csup: <option-tag-list>

   RFC 4566, Section 9, provides the ABNF [RFC5234] for SDP attributes.
   The "csup" attribute adheres to the RFC 4566 "attribute" production,
   with an att-value defined as follows:

      att-value         = option-tag-list
      option-tag-list   = option-tag *("," option-tag)
      option-tag        = token    ; defined in [RFC4566]

   A special base option tag with a value of "cap-v0" is defined for the
   basic SDP Capability Negotiation framework defined in this document.
   Entities can use this option tag with the "a=csup" attribute to

Top      Up      ToC       Page 15 
   indicate support for the SDP Capability Negotiation framework
   specified in this document.  Please note that white space is not
   allowed in this rule.

   The following examples illustrate use of the "a=csup" attribute with
   the "cap-v0" option tag and two hypothetical option tags, "foo" and
   "bar" (note the lack of white space):

      a=csup:cap-v0

      a=csup:foo

      a=csup:bar

      a=csup:cap-v0,foo,bar

   The "a=csup" attribute can be provided at the session and the media
   level.  When provided at the session level, it applies to the entire
   SDP session description.  When provided at the media level, it
   applies only to the media description in question (option tags
   provided at the session level apply as well).  There MUST NOT be more
   than one "a=csup" attribute at the session level and one at the media
   level (one per media description in the latter case).

   Whenever an entity that supports one or more extensions to the SDP
   Capability Negotiation framework generates an SDP session
   description, it SHOULD include the "a=csup" attribute with the option
   tags for the extensions it supports at the session and/or media
   level, unless those option tags are already provided in one or more
   "a=creq" attribute (see Section 3.3.2) at the relevant levels.
   Inclusion of the base option tag is OPTIONAL; support for the base
   framework can be inferred from presence of the "a=pcfg" attribute
   defined in Section 3.5.1.

   Use of the base option tag may still be useful in some scenarios,
   e.g., when using SIP OPTIONS [RFC3261] or generating an answer to an
   offer that did not use the SDP Capability Negotiation framework.

3.3.2.  Required Capability Negotiation Extensions Attribute

   The Required Capability Negotiation Extensions attribute ("a=creq")
   contains a comma-separated list of option tags (see Section 3.3.1)
   specifying the SDP Capability Negotiation extensions that MUST be
   supported by the entity receiving the SDP session description, in
   order for that entity to properly process the SDP Capability
   Negotiation attributes and associated procedures.  There is no need
   to include the base option tag ("cap-v0") with the "creq" attribute,

Top      Up      ToC       Page 16 
   since any entity that supports the "creq" attribute in the first
   place also supports the base option tag.  Still, it is permissible to
   do so.

      Such functionality may be important if a future version of the
      Capability Negotiation framework were not backwards compatible.

   The attribute can be provided at the session level and the media
   level, and it is defined as follows:

      a=creq: <option-tag-list>

   The "creq" attribute adheres to the RFC 4566 "attribute" production,
   with an att-value defined as follows:

      att-value   = option-tag-list

   The following examples illustrate use of the "a=creq" attribute with
   the "cap-v0" base option tag and two hypothetical option tags, "foo"
   and "bar" (note the lack of white space):

      a=creq:cap-v0
      a=creq:foo

      a=creq:bar

      a=creq:cap-v0,foo,bar

   The "a=creq" attribute can be provided at the session and the media
   level.  When provided at the session level, it applies to the entire
   SDP session description.  When provided at the media level, it
   applies only to the media description in question (required option
   tags provided at the session level apply as well).  There MUST NOT be
   more than one "a=creq" attribute at the session level and one
   "a=creq" attribute at the media level (one per media description in
   the latter case).

   When an entity generates an SDP session description and it requires
   the recipient of that SDP session description to support one or more
   SDP Capability Negotiation extensions (except for the base) at the
   session or media level in order to properly process the SDP
   Capability Negotiation, the "a=creq" attribute MUST be included with
   option tags that identify the required extensions at the session
   and/or media level.  If support for an extension is needed only in
   one or more specific potential configurations, the potential
   configuration provides a way to indicate that instead (see Section
   3.5.1).  Support for the basic negotiation framework is implied by

Top      Up      ToC       Page 17 
   the presence of an "a=pcfg" attribute (see Section 3.5.1) and hence
   it is not required to include the "a=creq" attribute with the base
   option tag ("cap-v0").

   A recipient that receives an SDP session description and does not
   support one or more of the required extensions listed in a "creq"
   attribute MUST NOT perform the SDP Capability Negotiation defined in
   this document; instead the recipient MUST proceed as if the SDP
   Capability Negotiation attributes were not included in the first
   place, i.e., the capability negotiation attributes are ignored.  In
   that case, if the SDP session description recipient is an SDP
   answerer [RFC3264], the recipient SHOULD include a "csup" attribute
   in the resulting SDP session description answer listing the SDP
   Capability Negotiation extensions it actually supports.

      This ensures that introduction of the SDP Capability Negotiation
      mechanism by itself does not lead to session failures

   For non-supported extensions provided at the session level, this
   implies that SDP Capability Negotiation MUST NOT be performed at all.
   For non-supported extensions at the media level, this implies that
   SDP Capability Negotiation MUST NOT be performed for the media stream
   in question.

      An entity that does not support the SDP Capability Negotiation
      framework at all, will ignore these attributes (as well as the
      other SDP Capability Negotiation attributes) and not perform any
      SDP Capability Negotiation in the first place.

3.4.  Capability Attributes

   In this section, we present the new attributes associated with
   indicating the capabilities for use by the SDP Capability
   Negotiation.

3.4.1.  Attribute Capability Attribute

   Attributes and their associated values can be expressed as
   capabilities by use of a new attribute capability attribute
   ("a=acap"), which is defined as follows:

      a=acap: <att-cap-num> <att-par>

   where <att-cap-num> is an integer between 1 and 2^31-1 (both
   included) used to number the attribute capability and <att-par> is an
   attribute ("a=") in its "<attribute>" or "<attribute>:<value>" form,
   i.e., excluding the "a=" part (see [RFC4566]).  The attribute can be
   provided at the session level and the media level.

Top      Up      ToC       Page 18 
   The "acap" attribute adheres to the RFC 4566 "attribute" production,
   with an att-value defined as follows:

      att-value   = att-cap-num 1*WSP att-par
      att-cap-num = 1*10(DIGIT)  ;defined in [RFC5234]
      att-par     = attribute    ;defined in [RFC4566]

   Note that white space is not permitted before the att-cap-num.

   When the attribute capability contains a session-level attribute,
   that "acap" attribute can only be provided at the session level.
   Conversely, media-level attributes can be provided in attribute
   capabilities at either the media level or session level.  The base
   SDP Capability Negotiation framework however only defines procedures
   for use of media-level attribute capabilities at the media level.
   Implementations that conform only to the base framework MUST NOT
   generate media-level attribute capabilities at the session level;
   however, extensions may change this (see, e.g., [SDPMedCap] for one
   such extension) and hence all implementations MUST still be prepared
   to receive such capabilities (see Section 3.6.2 for processing
   rules).

   Each occurrence of the "acap" attribute in the entire session
   description MUST use a different value of <att-cap-num>.  Consecutive
   numbering of the <att-cap-num> values is not required.

      There is a need to be able to reference both session-level and
      media-level attributes in potential configurations at the media
      level, and this provides for a simple solution to avoiding overlap
      between the references (handles) to each attribute capability.

   The <att-cap-num> values provided are independent of similar
   <cap-num> values provided for other types of capabilities, i.e., they
   form a separate name-space for attribute capabilities.

   The following examples illustrate use of the "acap" attribute:

      a=acap:1 ptime:20

      a=acap:2 ptime:30

      a=acap:3 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA
      AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0
      JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO
      SrzKTAv9zV

      a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32
            inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32

Top      Up      ToC       Page 19 
   The first two attribute capabilities provide attribute values for the
   ptime attribute.  The third provides SRTP parameters by using
   Multimedia Internet KEYing (MIKEY) [RFC3830] with the "key-mgmt"
   attribute [RFC4567].  The fourth provides SRTP parameters by use of
   security descriptions with the "crypto" attribute [RFC4568].  Note
   that the line-wrapping and new-lines in example three and four are
   provided for formatting reasons only -- they are not permitted in
   actual SDP session descriptions.

      Readers familiar with RFC 3407 may notice the similarity between
      the RFC 3407 "cpar" attribute and the above.  There are however a
      couple of important differences, notably that the "acap" attribute
      contains a handle that enables referencing it and it furthermore
      supports only attributes (the "cpar" attribute defined in RFC 3407
      supports bandwidth information as well).  The "acap" attribute
      also is not automatically associated with any particular
      capabilities.  See Section 3.14 for the relationship to RFC 3407.

   Attribute capabilities MUST NOT embed any capability negotiation
   parameters.  This restriction applies to all the capability
   negotiation parameters defined in this document ("csup", "creq",
   "acap", "tcap", "pcfg", and "acfg") as well as any capability
   negotiation extensions defined.  The following examples are thus
   invalid attribute capabilities and MUST NOT be used:

     a=acap:1 acap:2 foo:a       ;Not allowed to embed "acap"

     a=acap:2 a=pcfg:1 t=1 a=1   ;Not allowed to embed "pcfg"

   The reason for this restriction is to avoid overly complex processing
   rules resulting from the expansion of such capabilities into
   potential configurations (see Section 3.6.2 for further details).

3.4.2.  Transport Protocol Capability Attribute

   Transport protocols can be expressed as capabilities by use of a new
   Transport Protocol Capability attribute ("a=tcap") defined as
   follows:

      a=tcap: <trpr-cap-num> <proto-list>

   where <trpr-cap-num> is an integer between 1 and 2^31-1 (both
   included) used to number the transport address capability for later
   reference, and <proto-list> is one or more <proto>, separated by
   white space, as defined in the SDP "m=" line.  The attribute can be
   provided at the session level and the media level.

Top      Up      ToC       Page 20 
   The "tcap" attribute adheres to the RFC 4566 "attribute" production,
   with an att-value defined as follows:

      att-value      = trpr-cap-num 1*WSP proto-list
      trpr-cap-num   = 1*10(DIGIT)           ;defined in [RFC5234]
      proto-list     = proto *(1*WSP proto)  ;defined in [RFC4566]

   Note that white space is not permitted before the trpr-cap-num.

   The "tcap" attribute can be provided at the session level and the
   media level.  There MUST NOT be more than one "a=tcap" attribute at
   the session level and one at the media level (one per media
   description in the latter case).  Each occurrence of the "tcap"
   attribute in the entire session description MUST use a different
   value of <trpr-cap-num>.  When multiple <proto> values are provided,
   the first one is associated with the value <trpr-cap-num>, the second
   one with the value one higher, etc.  There MUST NOT be any capability
   number overlap between different "tcap" attributes in the entire SDP
   session description.  The <trpr-cap-num> values provided are
   independent of similar <cap-num> values provided for other capability
   attributes, i.e., they form a separate name-space for transport
   protocol capabilities.  Consecutive numbering of the <trpr-cap-num>
   values in different "tcap" attributes is not required.

   Below, we provide examples of the "a=tcap" attribute:

      a=tcap:1 RTP/AVP

      a=tcap:2 RTP/AVPF

      a=tcap:3 RTP/SAVP RTP/SAVPF

      a=tcap:5 UDP/TLS/RTP/SAVP

   The first one provides a capability for the "RTP/AVP" profile defined
   in [RFC3551] and the second one provides a capability for the RTP
   with RTCP-based feedback profile defined in [RFC4585].  The third one
   provides capabilities for the "RTP/SAVP" (transport capability number
   3) and "RTP/SAVPF" profiles (transport protocol capability number 4).
   The last one provides capabilities for "UDP/TLS/RTP/SAVP", i.e.,
   DTLS-SRTP [RFC5764] (transport capability number 5).

   The "tcap" attribute by itself can only specify transport protocols
   as defined by <proto> in [RFC4566]; however, full specification of a
   media stream requires further qualification of the transport protocol
   by one or more media format descriptions, which themselves often
   depend on the transport protocol.  As an example, [RFC3551] defines
   the "RTP/AVP" transport for use with audio and video codecs (media

Top      Up      ToC       Page 21 
   formats), whereas [RFC4145] defines the "TCP" transport, which, for
   example, may be used to negotiate T.38 fax ("image/t38"), etc.  In a
   non-SDP context, some media formats could be viewed as transports
   themselves (e.g., T.38); however, in the context of SDP and SDP
   Capability Negotiation, they are not.  If capability negotiation is
   required for such media formats, they MUST all either be valid under
   the transport protocol indicated in the "m=" line included for the
   media stream description, or a suitable extension must be used, e.g.,
   SDP Media Capabilities [SDPMedCap].

   The ability to use a particular transport protocol is inherently
   implied by including it in the "m=" line, regardless of whether or
   not it is provided in a "tcap" attribute.  However, if a potential
   configuration needs to reference that transport protocol as a
   capability, the transport protocol MUST be included explicitly in a
   "tcap" attribute.

      This may seem redundant (and indeed it is from the offerer's point
      of view), however it is done to protect against intermediaries
      (e.g., middleboxes) that may modify "m=" lines while passing
      unknown attributes through.  If an implicit transport capability
      were used instead (e.g., a reserved transport capability number
      could be used to refer to the transport protocol in the "m="
      line), and an intermediary were to modify the transport protocol
      in the "m=" line (e.g., to translate between plain RTP and Secure
      RTP), then the potential configuration referencing that implicit
      transport capability may no longer be correct.  With explicit
      capabilities, we avoid this pitfall; however, the potential
      configuration preference (see Section 3.5.1) may not reflect that
      of the intermediary (which some may view as a feature).

   Note that a transport protocol capability may be provided,
   irrespective of whether or not it is referenced in a potential
   configuration (just like any other capability).

3.4.3.  Extension Capability Attributes

   The SDP Capability Negotiation framework allows for new types of
   capabilities to be defined as extensions and used with the general
   capability negotiation framework.  The syntax and semantics of such
   new capability attributes are not defined here; however, in order to
   be used with potential configurations, they SHOULD allow for a
   numeric handle to be associated with each capability.  This handle
   can be used as a reference within the potential and actual
   configuration attributes (see Sections 3.5.1 and 3.5.2).  The
   definition of such extension capability attributes MUST also state
   whether they can be applied at the session level, media level, or

Top      Up      ToC       Page 22 
   both.  Note that extensions can have option tags defined for them,
   and option tags MUST be registered with the IANA in accordance with
   the procedures specified in Section 6.2.

   Extension capabilities SHOULD NOT embed any capability negotiation
   parameters.  This applies to all the capability negotiation
   parameters defined in this document as well as any extensions
   defined.  The reason for this restriction is to avoid overly complex
   processing rules resulting from the expansion of such capabilities
   into potential configurations (see Section 3.6.2 for further
   details).  If an extension does not follow the above "SHOULD NOT"
   recommendation, the extension MUST provide a careful analysis of why
   such behavior is both necessary and safe.

3.5.  Configuration Attributes

3.5.1.  Potential Configuration Attribute

   Potential configurations can be expressed by use of a new Potential
   Configuration Attribute ("a=pcfg") defined as follows:

      a=pcfg: <config-number> [<pot-cfg-list>]

   where <config-number> is an integer between 1 and 2^31-1 (both
   included).  The attribute can be provided only at the media level.

   The "pcfg" attribute adheres to the RFC 4566 "attribute" production,
   with an att-value defined as follows:

      att-value      = config-number [1*WSP pot-cfg-list]
      config-number  = 1*10(DIGIT)  ;defined in [RFC5234]
      pot-cfg-list   = pot-config *(1*WSP pot-config)
      pot-config     = attribute-config-list /
                       transport-protocol-config-list /
                       extension-config-list

   The missing productions are defined below.  Note that white space is
   not permitted before the config-number.

   The potential configuration attribute can be provided only at the
   media level and there can be multiple instances of it within a given
   media description.  The attribute includes a configuration number,
   which is an integer between 1 and 2^31-1 (both included).  The
   configuration number MUST be unique within the media description
   (i.e., it has only media-level scope).  The configuration number also
   indicates the relative preference of potential configurations; lower

Top      Up      ToC       Page 23 
   numbers are preferred over higher numbers.  Consecutive numbering of
   the configuration numbers in different "pcfg" attributes in a media
   description is not required.

   A potential configuration list is normally provided after the
   configuration number.  When the potential configuration list is
   omitted, the potential configuration equals the actual configuration.
   The potential configuration list contains one or more of attribute,
   transport, and extension configuration lists.  A potential
   configuration may for example include attribute capabilities and
   transport capabilities, transport capabilities only, or some other
   combination of capabilities.  If transport capabilities are not
   included in a potential configuration, the default transport for that
   media stream is used.

   The potential configuration lists generally reference one or more
   capabilities (extension configuration lists MAY use a different
   format).  Those capabilities are (conceptually) used to construct a
   new internal version of the SDP session description by use of purely
   syntactic add and (possibly) delete operations on the original SDP
   session description (actual configuration).  This provides an
   alternative potential configuration SDP session description that can
   be used by conventional SDP and offer/answer procedures if selected.

   This document defines attribute configuration lists and transport
   protocol configuration lists.  Each of these MUST NOT be present more
   than once in a particular potential configuration attribute.
   Attribute capabilities referenced by the attribute configuration list
   (if included) are added to the actual configuration, whereas a
   transport capability referenced by the transport protocol
   configuration list (if included) replaces the default transport
   protocol from the actual configuration.  Extension configuration
   lists can be included as well.  There can be more than one extension
   configuration list; however, each particular extension MUST NOT be
   present more than once in a given "a=pcfg" attribute.  Together, the
   various configuration lists define a potential configuration.

   There can be multiple potential configurations in a media
   description.  Each of these indicates not only a willingness, but in
   fact a desire to use the potential configuration.

Top      Up      ToC       Page 24 
   The example SDP session description below contains two potential
   configurations:

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 53456 RTP/AVP 0 18
      a=tcap:1 RTP/SAVP RTP/SAVPF
      a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
         inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
      a=pcfg:1 t=1 a=1
      a=pcfg:2 t=2 a=1

   Potential configuration 1 contains a transport protocol configuration
   list that references transport capability 1 ("RTP/SAVP") and an
   attribute configuration list that references attribute capability 1
   ("a=crypto:...").  Potential configuration 2 contains a transport
   protocol configuration list that references transport capability 2
   ("RTP/SAVPF") and an attribute configuration list that references
   attribute capability 1 ("a=crypto:...").

   Attribute capabilities are used in a potential configuration by use
   of the attribute-config-list parameter, which is defined by the
   following ABNF:

      attribute-config-list =  "a=" delete-attributes
      attribute-config-list =/ "a=" [delete-attributes ":"]
                        mo-att-cap-list *(BAR mo-att-cap-list)

      delete-attributes = DELETE ( "m" ; media attributes
                              / "s"    ; session attributes
                              / "ms" ) ; media and session attributes

      mo-att-cap-list   = mandatory-optional-att-cap-list /
                                    mandatory-att-cap-list /
                                       optional-att-cap-list

      mandatory-optional-att-cap-list  = mandatory-att-cap-list
                                             "," optional-att-cap-list
      mandatory-att-cap-list           = att-cap-list
      optional-att-cap-list            = "[" att-cap-list "]"

      att-cap-list      = att-cap-num *("," att-cap-num)
      att-cap-num       = 1*10(DIGIT)     ;defined in [RFC5234]
      BAR               = "|"
      DELETE            = "-"

Top      Up      ToC       Page 25 
   Note that white space is not permitted within the attribute-config-
   list rule.

   Each attribute configuration list can optionally begin with
   instructions for how to handle attributes that are part of the actual
   configuration SDP session description (i.e., the "a=" lines present
   in the original SDP session description).  By default, such
   attributes will remain as part of the potential configuration in
   question.  However, if delete-attributes indicates "-m", then all
   attribute lines within the media description in question will be
   deleted in the resulting potential configuration SDP session
   description (i.e., all "a=" lines under the "m=" line in question).
   If delete-attributes indicates "-s", then all attribute lines at the
   session level will be deleted (i.e., all "a=" lines before the first
   "m=" line).  If delete-attributes indicates "-ms", then all attribute
   lines within this media description ("m=" line) and all attribute
   lines at the session level will be deleted.

   The attribute capability list comes next (if included).  It contains
   one or more alternative lists of attribute capabilities.  The
   alternative attribute capability lists are separated by a vertical
   bar ("|"), and each list contains one or more attribute capabilities
   separated by commas (",").  The attribute capabilities are either
   mandatory or optional.  Mandatory attribute capabilities MUST be
   supported in order to use the potential configuration, whereas
   optional attribute capabilities MAY be supported in order to use the
   potential configuration.

   Within each attribute capability list, all the mandatory attribute
   capabilities (if any) are listed first, and all the optional
   attribute capabilities (if any) are listed last.  The optional
   attribute capabilities are contained within a pair of square brackets
   ("[" and "]").  Each attribute capability is merely an attribute
   capability number (att-cap-num) that identifies a particular
   attribute capability by referring to attribute capability numbers
   defined above and hence MUST be between 1 and 2^31-1 (both included).
   The following example illustrates the above:

      a=pcfg:1 a=-m:1,2,[3,4]|1,7,[5]

   where

   o  "a=-m:1,2,[3,4]|1,7,[5]" is the attribute configuration list

   o  "-m" indicates to delete all attributes from the media description
      of the actual configuration

Top      Up      ToC       Page 26 
   o  "1,2,[3,4]" and "1,7,[5]" are both attribute capability lists.
      The two lists are alternatives, since they are separated by a
      vertical bar above

   o  "1", "2", and "7" are mandatory attribute capabilities

   o  "3", "4", and "5" are optional attribute capabilities

   Note that in the example above, we have a single handle ("1") for the
   potential configuration(s), but there are actually two different
   potential configurations (separated by a vertical bar).  This is done
   for message size efficiency reasons, which is especially important
   when we add other types of capabilities to the potential
   configuration.  If there is a need to provide a unique handle for
   each, then separate "a=pcfg" attributes with different handles MUST
   be used instead.

   Each referenced attribute capability in the potential configuration
   will result in the corresponding attribute name and its associated
   value (contained inside the attribute capability) being added to the
   resulting potential configuration SDP session description.

   Alternative attribute capability lists are separated by a vertical
   bar ("|"), the scope of which extends to the next alternative (i.e.,
   "," has higher precedence than "|").  The alternatives are ordered by
   preference with the most preferred listed first.  In order for a
   recipient of the SDP session description (e.g., an answerer receiving
   this in an offer) to use this potential configuration, exactly one of
   the alternative lists MUST be selected in its entirety.  This
   requires that all mandatory attribute capabilities referenced by the
   potential configuration are supported with the attribute values
   provided.

   Transport protocol configuration lists are included in a potential
   configuration by use of the transport-protocol-config-list parameter,
   which is defined by the following ABNF:

      transport-protocol-config-list =
                           "t=" trpr-cap-num *(BAR trpr-cap-num)
      trpr-cap-num        = 1*10(DIGIT)   ; defined in [RFC5234]

   Note that white space is not permitted within this rule.

   The trpr-cap-num refers to transport protocol capability numbers
   defined above and hence MUST be between 1 and 2^31-1 (both included).
   Alternative transport protocol capabilities are separated by a
   vertical bar ("|").  The alternatives are ordered by preference with
   the most preferred listed first.  If there are no transport protocol

Top      Up      ToC       Page 27 
   capabilities included in a potential configuration at the media
   level, the transport protocol information from the associated "m="
   line MUST be used.  In order for a recipient of the SDP session
   description (e.g., an answerer receiving this in an offer) to use
   this potential configuration, exactly one of the alternatives MUST be
   selected.  This requires that the transport protocol in question is
   supported.

      In the presence of intermediaries (the existence of which may not
      be known), care should be taken with assuming that the transport
      protocol in the "m=" line will not be modified by an intermediary.
      Use of an explicit transport protocol capability will guard
      against capability negotiation implications of that.

   Extension capabilities can be included in a potential configuration
   as well by use of extension configuration lists.  Extension
   configuration lists MUST adhere to the following ABNF:

      extension-config-list   = ["+"] ext-cap-name "=" ext-cap-list
      ext-cap-name            = 1*(ALPHA / DIGIT)
      ext-cap-list            = 1*VCHAR   ; defined in [RFC5234]

   Note that white space is not permitted within this rule.

   The ext-cap-name refers to the name of the extension capability and
   the ext-cap-list is here merely defined as a sequence of visible
   characters.  The actual extension supported MUST refine both of these
   further.  For extension capabilities that merely need to be
   referenced by a capability number, it is RECOMMENDED to follow a
   structure similar to what has been specified above.  Unsupported or
   unknown potential extension configuration lists in a potential
   configuration attribute MUST be ignored, unless they are prefixed
   with the plus ("+") sign, which indicates that the extension is
   mandatory and MUST be supported in order to use that potential
   configuration.

      The "creq" attribute and its associated rules can be used to
      ensure that required extensions are supported in the first place.

   Extension configuration lists define new potential configuration
   parameters and hence they MUST be registered with IANA per the
   procedures defined in Section 6.3.

   Potential configuration attributes can be provided only at the media
   level; however, it is possible to reference capabilities provided at
   either the session or media level.  There are certain semantic rules
   and restrictions associated with this:

Top      Up      ToC       Page 28 
   A (media-level) potential configuration attribute in a given media
   description MUST NOT reference a media-level capability provided in a
   different media description; doing so invalidates that potential
   configuration (note that a potential configuration attribute can
   contain more than one potential configuration by use of
   alternatives).  A potential configuration attribute can however
   reference a session-level capability.  The semantics of doing so
   depends on the type of capability.  In the case of transport protocol
   capabilities, it has no particular implication.  In the case of
   attribute capabilities, however, it does.  More specifically, the
   attribute name and value (provided within that attribute capability)
   will be considered part of the resulting SDP for that particular
   configuration at the *session* level.  In other words, it will be
   as-if that attribute was provided with that value at the session
   level in the first place.  As a result, the base SDP Capability
   Negotiation framework REQUIRES that potential configurations do not
   reference any session-level attribute capabilities that contain
   media-level attributes (since that would place a media-level
   attribute at the session level).  Extensions may modify this
   behavior, as long as it is fully backwards compatible with the base
   specification.

   Individual media streams perform capability negotiation individually,
   and hence it is possible that one media stream (where the attribute
   was part of a potential configuration) chose a configuration without
   a session-level attribute that was chosen by another media stream.
   The session-level attribute however remains "active" and applies to
   the entire resulting potential configuration SDP session description.
   In theory, this is problematic if one or more session-level
   attributes either conflicts with or potentially interacts with
   another session-level or media-level attribute in an undefined
   manner.  In practice, such examples seem to be rare (at least with
   the SDP attributes that had been defined at time of publication of
   this document).

      A related set of problems can occur if we need coordination
      between session-level attributes from multiple media streams in
      order for a particular functionality to work.  The grouping
      framework [RFC5888] is an example of this.  If we use the SDP
      Capability Negotiation framework to select a session-level group
      attribute (provided as an attribute capability), and we require
      two media descriptions to do this consistently, we could have a
      problem.  The Forward Error Correction (FEC) grouping semantics
      [RFC4756] is one example where this in theory could cause
      problems, however in practice, it is unclear that there is a
      significant problem with the grouping semantics that had been
      defined at time of publication of this document.

Top      Up      ToC       Page 29 
   Resolving the above issues in general requires inter-media stream
   constraints and synchronized potential configuration processing; this
   would add considerable complexity to the overall solution.  In
   practice, with the SDP attributes defined at time of publication of
   this document, it does not seem to be a significant problem, and
   hence the base SDP Capability Negotiation solution does not provide a
   solution to this issue.  Instead, it is RECOMMENDED that use of
   session-level attributes in a potential configuration is avoided when
   possible, and when not, that such use is examined closely for any
   potential interaction issues.  If interaction is possible, the entity
   generating the SDP session description SHOULD NOT assume that well-
   defined operation will occur at the receiving entity.  This implies
   that mechanisms that might have such interactions cannot be used in
   security critical contexts.

   The session-level operation of extension capabilities is undefined.
   Consequently, each new session-level extension capability defined
   MUST specify the implication of making it part of a configuration at
   the media level.

   Below, we provide an example of the "a=pcfg" attribute in a complete
   media description in order to properly indicate the supporting
   attributes:

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 53456 RTP/AVPF 0 18
      a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
         inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
      a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF
      a=pcfg:1 t=4|3 a=1
      a=pcfg:8 t=1|2

   We have two potential configuration attributes listed here.  The
   first one (and most preferred, since its configuration number is "1")
   indicates that either of the profiles RTP/SAVPF or RTP/SAVP
   (specified by the transport protocol capability numbers 4 and 3) can
   be supported with attribute capability 1 (the "crypto" attribute);
   RTP/SAVPF is preferred over RTP/SAVP since its capability number (4)
   is listed first in the preferred potential configuration.  Note that
   although we have a single potential configuration attribute and
   associated handle, we have two potential configurations.

Top      Up      ToC       Page 30 
   The second potential configuration attribute indicates that the
   RTP/AVPF or RTP/AVP profiles can be used, with RTP/AVPF being the
   preferred one.  This non-secure RTP alternative is the less preferred
   one since its configuration number is "8".  Again, note that we have
   two potential configurations here and hence a total of four potential
   configurations in the SDP session description above.

3.5.2.  Actual Configuration Attribute

   The actual configuration attribute identifies which of the potential
   configurations from an offer SDP session description was selected and
   used as the actual configuration to generate an answer SDP session
   description.  This is done by including the configuration number and
   the configuration lists (if any) from the offer that were selected
   and used by the answerer in his offer/answer procedure as follows:

   o  A selected attribute configuration MUST include the delete-
      attributes and the known and supported parameters from the
      selected alternative mo-att-cap-list (i.e., containing all
      mandatory and all known and supported optional capability numbers
      from the potential configuration).  If delete-attributes were not
      included in the potential configuration, they will of course not
      be present here either.

   o  A selected transport protocol configuration MUST include the
      selected transport protocol capability number.

   o  A selected potential extension configuration MUST include the
      selected extension configuration parameters as specified for that
      particular extension.

   o  When a configuration list contains alternatives (separated by
      "|"), the selected configuration only MUST be provided.

   Note that the selected configuration number and all selected
   capability numbers used in the actual configuration attribute refer
   to those from the offer: not the answer.

      The answer may for example include capabilities as well to inform
      the offerer of the answerers capabilities above and beyond the
      negotiated configuration.  The actual configuration attribute does
      not refer to any of those answer capabilities though.

   The Actual Configuration Attribute ("a=acfg") is defined as follows:

      a=acfg: <config-number> [<sel-cfg-list>]

Top      Up      ToC       Page 31 
   where <config-number> is an integer between 1 and 2^31-1 (both
   included) that refers to the selected potential configuration.  The
   attribute can be provided only at the media level.

   The "acfg" attribute adheres to the RFC 4566 "attribute" production,
   with an att-value defined as follows:

      att-value      = config-number [1*WSP sel-cfg-list]
                        ;config-number defined in Section 3.5.1.
      sel-cfg-list   = sel-cfg *(1*WSP sel-cfg)
      sel-cfg        = sel-attribute-config /
                           sel-transport-protocol-config /
                           sel-extension-config

      sel-attribute-config =
               "a=" [delete-attributes ":"] mo-att-cap-list
                                    ; defined in Section 3.5.1.

      sel-transport-protocol-config =
               "t=" trpr-cap-num    ; defined in Section 3.5.1.

      sel-extension-config =
               ext-cap-name "=" 1*VCHAR   ; defined in Section 3.5.1.

   Note that white space is not permitted before the config-number.

   The actual configuration ("a=acfg") attribute can be provided only at
   the media level.  There MUST NOT be more than one occurrence of an
   actual configuration attribute within a given media description.

   Below, we provide an example of the "a=acfg" attribute (building on
   the previous example with the potential configuration attribute):

      v=0
      o=- 24351 621814 IN IP4 192.0.2.2
      s=
      c=IN IP4 192.0.2.2
      t=0 0
      m=audio 54568 RTP/SAVPF 0
      a=crypto:1 AES_CM_128_HMAC_SHA1_32
         inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
      a=acfg:1 t=4 a=1

   It indicates that the answerer used an offer consisting of potential
   configuration number 1 with transport protocol capability 4 from the
   offer (RTP/SAVPF) and attribute capability 1 (the "crypto"
   attribute).  The answerer includes his own "crypto" attribute as
   well.


Next RFC Part