Session Description Protocol (SDP) Capability Negotiation
updated by
- rfc-6871 — Session Description Protocol (SDP) Media Capabilities Negotiation
Extracted elements (28)
Capabilities and potential configurations are encoded as SDP attributes within a single SDP session description (rather than multiple SDP bodies in multipart MIME) for two reasons: multipart MIME support is not ubiquitous, and unknown SDP attributes are silently ignored by entities that do not support the framework, providing seamless backwards compatibility with RFC 3264.
Potential configurations are by default preferred over the actual configuration in the 'm=' line. This allows an offerer to place the least-common-denominator (e.g., plain RTP) in the actual configuration for backwards compatibility with legacy endpoints while expressing a preference for a more capable option (e.g., SRTP) as a potential configuration.
Transport protocol capabilities must be listed explicitly in 'a=tcap' even when the same protocol appears in the 'm=' line, to guard against intermediaries that rewrite 'm=' lines while passing unknown attributes through unchanged. An implicit capability tied to the 'm=' line could become inconsistent after such modification.
After a successful capability negotiation, the offerer SHOULD generate a new offer using the negotiated configuration as the actual configuration and without the capability negotiation extensions. This assists intermediaries that do not support the framework and that may have observed but not understood the negotiation.
Entities that do not support the SDP Capability Negotiation framework will ignore the new attributes ('a=csup', 'a=creq', 'a=acap', 'a=tcap', 'a=pcfg', 'a=acfg') and perform standard RFC 3264 offer/answer using only the actual configuration in the 'm=' line. This ensures introduction of the framework does not cause session failures with legacy endpoints.
Session-level attributes included in potential configurations remain 'active' across the entire session description even if only some media streams selected that configuration. This can cause undefined interactions when session-level attributes conflict across media streams; mechanisms with such potential interactions MUST NOT be used in security-critical contexts.
A media-level 'a=pcfg' attribute MUST NOT reference a media-level capability from a different media description; doing so invalidates that potential configuration. Potential configurations may reference session-level capabilities.
A recipient that does not support one or more required extensions listed in 'a=creq' MUST NOT perform SDP Capability Negotiation; it MUST instead proceed as if the capability negotiation attributes were absent. If the recipient is an answerer, it SHOULD include 'a=csup' in the answer listing the extensions it does support.
Attribute capabilities ('a=acap') MUST NOT embed any capability negotiation parameters including 'csup', 'creq', 'acap', 'tcap', 'pcfg', 'acfg', or any defined extensions. Violations render the attribute capability invalid.
If a session-level 'a=creq' attribute contains an option tag unsupported by the answerer, the answerer MUST NOT use any potential configuration attributes in any media description, and MUST continue with standard RFC 3264 procedures while including 'a=csup' listing the extensions it supports.
Once the offerer receives an answer indicating the selected configuration, incoming media MUST be processed in accordance with that actual selected configuration. Before the answer is received, media received per a potential configuration MAY be discarded.
Option tags used to identify SDP Capability Negotiation extensions MUST be registered with IANA per the procedures in Section 6.2. This applies to the base option tag 'cap-v0' and all extension option tags.
The answerer MUST perform capability negotiation using the most preferred valid potential configuration, subject to local policy. A potential configuration is valid only if its syntax is correct, its config-number is unique in the media description, and all referenced capabilities are valid and present at the correct scope level.
The base SDP Capability Negotiation framework REQUIRES that potential configurations not reference session-level attribute capabilities that contain media-level-only attributes. Using such a reference invalidates the potential configuration.
When a transport protocol capability is not included in a potential configuration, the transport protocol from the associated 'm=' line MUST be used. If a potential configuration needs to reference the 'm=' line's transport protocol as a capability, that transport protocol MUST be listed explicitly in a 'a=tcap' attribute.
The 'a=acap' attribute expresses a named SDP attribute and optional value as a numbered capability (handle 1 to 2^31-1). Session-level attributes may only appear as acap at session level; media-level attributes may appear at either level. Each att-cap-num MUST be unique across the entire session description.
The 'a=acfg' attribute appears in an answer to identify which potential configuration from the offer was selected, including the config-number and the specific capability references chosen. At most one 'a=acfg' is permitted per media description. Config-numbers and capability numbers in 'a=acfg' refer to the offer, not the answer.
The 'a=creq' attribute lists option tags for SDP Capability Negotiation extensions that MUST be supported by the recipient in order to properly process the capability negotiation. A recipient lacking support for a listed extension MUST ignore capability negotiation attributes and fall back to standard RFC 3264 procedures.
The 'a=csup' attribute lists the SDP Capability Negotiation extensions (identified by option tags) supported by the entity that generated the SDP session description. It may appear at session level (applies to entire description) or media level (applies only to that media description), with at most one occurrence at each level.
The 'a=pcfg' attribute declares a potential configuration at the media level, identified by a unique config-number (lower numbers indicate higher preference). It references attribute and transport capabilities using a compact syntax supporting alternatives (separated by '|'), mandatory vs. optional attribute capabilities, and optional deletion of existing attributes ('-m', '-s', '-ms').
The 'a=tcap' attribute lists one or more transport protocol names (e.g., 'RTP/SAVP') as numbered transport capabilities. Multiple protocols may be packed into a single 'a=tcap' line, with the first assigned trpr-cap-num and each subsequent one numbered sequentially. At most one 'a=tcap' is permitted at session level and one per media description.
RFC 5939 establishes a new 'SDP Capability Negotiation Potential Configuration Parameter' registry for extension configuration list names used in 'a=pcfg'. New parameters require IETF Review per Section 6.3.
RFC 5939 registers six new SDP attributes with IANA: 'csup', 'creq', 'acap', 'tcap', 'pcfg', and 'acfg', under the existing SDP Parameters registry.
When session-level attribute capabilities are referenced in media-level potential configurations, individual media streams may end up with inconsistent combinations of session-level attributes, leading to undefined behavior. If interaction between a session-level attribute and other attributes is possible, the entity generating the SDP SHOULD NOT assume well-defined operation at the receiver, making such mechanisms unsuitable for security-critical use.
The 'a=acap' attribute encodes as: att-cap-num (1–10 DIGIT, value 1–2^31-1) followed by one or more WSP and an SDP attribute in '<attribute>' or '<attribute>:<value>' form (no 'a=' prefix). No whitespace is permitted before att-cap-num.
The 'a=acfg' attribute encodes as: config-number (1–10 DIGIT) optionally followed by a space-separated sel-cfg-list. Selected attribute configs use 'a=[delete-attributes:]mo-att-cap-list'; selected transport configs use 't=trpr-cap-num'; selected extension configs use 'ext-cap-name=1*VCHAR'. No whitespace before config-number.
The 'a=pcfg' attribute encodes as: config-number (1–10 DIGIT) optionally followed by a pot-cfg-list of space-separated configurations. Attribute config lists use the form 'a=[delete-attributes:]mo-att-cap-list(|mo-att-cap-list)*'; transport config lists use 't=trpr-cap-num(|trpr-cap-num)*'; extension config lists use '[+]ext-cap-name=ext-cap-list'. No whitespace is permitted within config list productions.
The 'a=tcap' attribute encodes as: trpr-cap-num (1–10 DIGIT, value 1–2^31-1) followed by one or more WSP and a space-separated proto-list. No whitespace is permitted before trpr-cap-num.