Session Description Protocol (SDP) Media Capabilities Negotiation
updates
- rfc-5939 — Session Description Protocol (SDP) Capability Negotiation
Extracted elements (30)
A concatenation rule is defined for 'mfcap' parameters referencing the same media capability number: their parameter strings are joined with ';'. This is motivated by codecs such as AMR-WB that have a large number of formatting options, making it impractical to enumerate every combination explicitly on a single line.
Media format capabilities use subtypes (e.g., PCMU, G729) rather than RTP payload type numbers, deliberately deferring payload type assignment to the 'pt=' parameter in a 'pcfg' line. This allows the same media subtype capability to be referenced by multiple configurations with different payload type numbers, enabling the offerer to distinguish encrypted vs. unencrypted early media before receiving the answer.
The 'mt=' parameter is defined exclusively for 'lcfg' and not for 'pcfg' because a potential configuration's media type is implicitly determined by its enclosing 'm=' line, while a latent configuration exists independently of any current 'm=' line and therefore requires an explicit media type declaration.
Media capabilities provided at the session level may be referenced by any 'pcfg' or 'lcfg' attribute at the media level (consistent with media type), while capabilities at the media level may only be referenced within that media description's 'pcfg' or 'lcfg'. Regardless of where capabilities are defined, they always instantiate as media-level attributes.
The framework is designed so that each proposed configuration in an offer can be straightforwardly translated into a conventional SDP media block without capability negotiation attributes. Endpoints that do not understand 'med-v0' ignore the capability attributes and fall back to the base 'm=' line configuration, which should represent the minimum acceptable configuration.
'a=rmcap' MUST be used for RTP-based media formats, whereas 'a=omcap' MUST be used for non-RTP-based (other) media formats. Media capability numbers are shared between the two attributes and MUST be unique across the entire SDP session.
Each 'lcfg' attribute MUST be specified at the media level, MUST include a config-number unique in the entire SDP (not overlapping any 'pcfg' config-number), MUST include a media type ('mt='), and MUST reference a valid transport capability ('t='). The pot-cfg-list MUST NOT contain more than one instance of each parameter type.
Each 'pcfg' config-number MUST be unique in the entire SDP (extending RFC 5939, which only required uniqueness within a media description). Config-numbers MUST NOT overlap between potential and latent configurations, and MUST NOT contain leading zeroes.
For RTP-based media capabilities used in a potential configuration, payload type mappings MUST be provided via the 'pt=' parameter in the 'pcfg' attribute. Payload type escaping may be used in 'mfcap', 'mscap', and 'acap' attribute arguments via the '%m=<cap-num>%' substitution sequence.
If the answerer supports media capabilities negotiation and session configurations are offered via 'sescap', it MUST accept one of the offered configurations or MUST refuse the session. Therefore, if the offer includes any session capabilities, it SHOULD include all session capabilities the offerer is willing to support.
If the offerer requires the answerer to understand the media capability extensions, the offerer MUST include a 'creq' attribute containing the value 'med-v0'. If required only for specific media descriptions, the 'med-v0' value MUST be provided only in 'creq' attributes within those media descriptions.
Latent configurations returned in SDP answers MUST match offered latent configurations (or parameter subsets thereof); the answerer MUST NOT introduce new configuration numbers not present in the offer. All numbering in the answer MUST refer to the configuration and capability attribute numbering of the offer.
The 'mfcap' attribute MUST be used to encode format parameters for media capabilities that would conventionally appear in an 'fmtp' attribute. The existing 'acap' attribute MUST NOT be used to encode 'fmtp' attributes.
The 'mscap' parameter MUST NOT include an 'rtpmap' or 'fmtp' attribute (these are handled by 'rmcap' and 'mfcap' respectively). Additionally, session-level-only attributes MUST NOT be used in the 'mscap' parameter since 'mscap' always instantiates media-level attributes.
When a range of capability numbers is specified in 'rmcap', 'omcap', or 'mscap', the first (leftmost) capability number MUST be strictly smaller than the second (rightmost), i.e., the range must increase and cover at least two numbers. Leading zeroes are not permitted in any media capability number.
The 'a=mfcap' attribute associates media format parameters (conventionally carried in 'a=fmtp') with one or more media capability numbers. Its form is 'a=mfcap:<media-cap-num-list> <list of parameters>'; multiple mfcap lines referencing the same capability number have their parameter lists concatenated with ';' in document order.
The 'a=mscap' attribute associates non-'rtpmap'/non-'fmtp' media-specific attributes (e.g., 'rtcp-fb') with one or more media capability numbers. Its form is 'a=mscap:<media-caps-star> <att-field> <att-value>'; a wildcard '*' appended to a capability number causes the resulting SDP to use '*' instead of the assigned payload type.
The 'a=omcap' attribute defines non-RTP-based media format capabilities in the form of a format name only (e.g., T38), each assigned a media capability number shared with the 'rmcap' number space. This attribute is used for media formats such as T.38 or BFCP where RTP payload types do not apply.
The 'a=rmcap' attribute defines RTP-based media format capabilities in the form of a media subtype (e.g., PCMU, G729) and encoding parameters, assigning each a media capability number. Multiple capability numbers may be assigned to the same subtype to allow association with different parameter sets in different configurations.
The latent configuration attribute 'a=lcfg:<config-number> <lcfg-cfg-list>' declares media stream configurations that are supportable in a future offer/answer exchange but are not offered for immediate use. It is always a media-level attribute and combines properties of a media line and a potential configuration.
The media configuration parameter 'm=' is added to 'pcfg', 'acfg', and 'lcfg' attributes to specify which media format capabilities (by number) are used in that configuration; alternatives within the list are separated by '|' in preference order. When present, the referenced capabilities completely replace the format list in the 'm=' line.
The media type parameter 'mt=' specifies the media type (audio, video, application, etc.) for a latent configuration; it is currently defined only for the 'lcfg' attribute and MUST be present in every 'lcfg' attribute since latent configurations exist independently of any 'm=' line.
The payload type number mapping parameter 'pt=' is added to 'pcfg', 'acfg', and 'lcfg' to map RTP media capability numbers to actual RTP payload type numbers. Its ABNF is 'pt=<media-cap-num>:<payload-type-number>[,...]'; payload type numbers MUST NOT have leading zeroes.
The session capability attribute 'a=sescap:<session-num> <list-of-configs> [<optional-configs>]' is a session-level attribute that specifies acceptable combinations of simultaneous media stream configurations (referencing 'pcfg' and/or 'lcfg' numbers). Lower session-num values are more preferred, and session preference order takes precedence over individual 'pcfg' preference order.
A new 'SDP Capability Negotiation Configuration Parameters' registry is created (updating RFC 5939's IANA considerations) with Expert Review policy. Three new configuration parameters are registered: 'm=' (media capabilities), 'pt=' (payload type number mapping), and 'mt=' (media type for latent configurations).
Six new SDP attributes are registered with IANA: 'rmcap', 'omcap', 'mfcap', 'mscap', 'lcfg', and 'sescap', all defined in this document. Additionally, a new SDP capability negotiation option tag 'med-v0' is registered.
If a cryptographic attribute (e.g., SDES 'a=crypto:') is referenced by a latent configuration via an 'acap' attribute, the keying material MUST be included for formatting compliance but MUST NOT be a real value used for actual media exchange. The receiver of the 'lcfg' attribute MUST ignore those keying material values.
This document introduces no new security considerations beyond those in RFC 5939 and RFC 4566, except that implementations MUST take care that keying material appearing in latent configurations is not a real value used for actual media exchange, since it is visible in the SDP but the session it protects has not yet been established.
The 'a=rmcap' ABNF is: 'a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate>[/<encoding-parms>]'; 'a=omcap' is: 'a=omcap:<media-cap-num-list> <format-name>'. A media-cap-num-list is a comma-separated list of integers or hyphenated ranges; each media-cap-num is a non-zero decimal integer up to 10 digits.
The 'a=sescap' ABNF is: att-value = session-num 1*WSP list-of-configs [1*WSP optional-configs]; list-of-configs = alt-config *(',' alt-config); optional-configs = '[' list-of-configs ']'; alt-config = config-number *('|' config-number). Leading zeroes are not permitted in session-num or config-number.