RFC 5939
Session Description Protocol (SDP) Capability Negotiation
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.
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) |
|<---------------------------------|
| |
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
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.
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
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,
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
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.
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
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.
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
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
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
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.
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 = "-"
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
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
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:
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.
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.
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>]
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 page on part 3)
