RFC 5939
Session Description Protocol (SDP) Capability Negotiation
Part 1 of 19 💖
RFC 5939 at a Glance 🎀
- Title: Session Description Protocol (SDP) Capability Negotiation ✨
- Number: RFC 5939
- Stream: Internet Engineering Task Force (IETF) 🌸
- Author: F. Andreasen, Cisco Systems 👑
- Category: Standards Track 🔥
- Date: September 2010 🦋
- ISSN: 2070-1721 💜
- Obsoletes / Updates: The title block doesn't list anything this one obsoletes or updates 🙈
Abstract ✨
okay so SDP (the Session Description Protocol) was originally built to describe multimedia sessions for announcing them, inviting people to them, and starting them up 🎀. Capability indication and capability negotiation were never part of the plan, but SDP got so popular that it picked up a little bit of both over the years 💅. The big one is the offer/answer model from RFC 3264 🫶.
Here's the tea though. SDP can't negotiate alternative transport protocols (like RTP profiles) or attributes 😭. That makes it really hard to roll out new RTP profiles like Secure RTP or RTP with RTCP-based feedback, or to negotiate different security keying mechanisms, etc. It also causes problems for some kinds of media negotiation 💀.
So this document fixes that. It extends SDP with capability negotiation parameters and the offer/answer procedures that use them, all in a way that stays backwards compatible 🌈 ⭐.
The document defines a general SDP Capability Negotiation framework 🧚. It also explains how to treat attributes and transport protocols as capabilities and negotiate them with that framework 💖. Other kinds of capabilities, like media types and media formats, may be covered in other documents, so keep an eye out 👀.
Status of This Memo 📜
This is an Internet Standards Track document 🔥.
It's a product of the IETF and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more on Internet Standards, check out Section 2 of RFC 5741 🦋.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5939 💅.
Copyright Notice 💜
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🌸. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭. Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 🔥. The one exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌈.
Table of Contents 🦋
Here's the full roadmap so you can find your way around the rest of the parts ✨.
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................7
3. SDP Capability Negotiation Solution .............................7
3.1. SDP Capability Negotiation Model ...........................7
3.2. Solution Overview .........................................10
3.3. Version and Extension Indication Attributes ...............14
3.4. Capability Attributes .....................................17
3.5. Configuration Attributes ..................................22
3.6. Offer/Answer Model Extensions .............................32
3.7. Interactions with ICE .....................................45
3.8. Interactions with SIP Option Tags .........................47
3.9. Processing Media before Answer ............................48
3.10. Indicating Bandwidth Usage ...............................49
3.11. Dealing with Large Number of Potential Configurations ....50
3.12. SDP Capability Negotiation and Intermediaries ............51
3.13. Considerations for Specific Attribute Capabilities .......52
3.14. Relationship to RFC 3407 .................................54
4. Examples .......................................................54
4.1. Multiple Transport Protocols ..............................54
4.2. DTLS-SRTP or SRTP with Media-Level Security Descriptions...58
4.3. Best-Effort SRTP with Session-Level MIKEY and Media-Level
Security Descriptions .....................................61
4.4. SRTP with Session-Level MIKEY and Media-Level Security
Descriptions as Alternatives ..............................66
5. Security Considerations ........................................69
6. IANA Considerations ............................................72
6.1. New SDP Attributes ........................................72
6.2. New SDP Capability Negotiation Option Tag Registry ........73
6.3. New SDP Capability Negotiation Potential
Configuration Parameter Registry ..........................74
7. Acknowledgments ................................................74
8. References .....................................................75
8.1. Normative References ......................................75
8.2. Informative References ....................................751. Introduction ✨
Okay so, SDP (the Session Description Protocol) was originally built to describe multimedia sessions for session announcements, session invitations, and other forms of multimedia session initiation 💖. An SDP session description holds one or more media stream descriptions, and each one carries stuff like the IP address and port, the type of media stream (e.g., audio or video), the transport protocol (possibly with profile info, e.g., RTP/AVP or RTP/SAVP), the media formats (e.g., codecs), and various other session and media stream parameters that define the session 🎀.
Simply providing media stream descriptions is enough for a broadcast app, where the media stream parameters are fixed for everyone 📡. When someone wants to join, they grab the session announcement and use the media descriptions they're given. For example, they might join a multicast group and receive media packets in the encoding format that was specified. But if the participant doesn't support that media stream description, they can't receive the media at all 😭.
That kind of setup doesn't really work for multimedia session invitations, where two or more entities are trying to set up a media session using a set of media stream parameters that's acceptable to everyone 🫶. Two things have to happen here. First, each entity has to tell the other its receive address. Second, the entities have to agree on the media stream parameters to use for the session, e.g., transport protocols and codecs. To fix this, RFC 3264 [RFC3264] defined the offer/answer model. In that model, an offerer builds an offer SDP session description listing the media streams, codecs, and other SDP parameters it's willing to use. That offer goes to the answerer, who picks from the media streams, codecs, and other session description parameters on offer, then generates an answer session description with its own parameters based on those choices. The answer gets sent back to the offerer, which wraps up the session negotiation and lets the negotiated media streams get established 🦋.
Now, let's take a step back ✨. We can split things into three buckets: the capabilities each participant supports, the ways those capabilities can be supported, and the parameters that can actually get used for the session. More generally, we end up with the following:
- A set of capabilities for the session and its associated media stream components, supported by each side. Capability indications by themselves don't commit anyone to using those capabilities in the session.
Capabilities can, for example, be that the "RTP/SAVP" profile is supported, that the "PCMU" (Pulse Code Modulation mu-law) codec is supported, or that the "crypto" attribute is supported with a particular value.
- A set of potential configurations indicating which combinations of those capabilities can be used for the session and its associated media stream components. Potential configurations aren't ready to use yet 🙈. Instead, they're an alternative that may be used, subject to further negotiation.
A potential configuration can, for example, indicate that the "PCMU" codec and the "RTP/SAVP" transport protocol are not only supported (i.e., listed as capabilities), but are also offered for potential use in the session.
- An actual configuration for the session and its associated media stream components, specifying which combinations of session parameters and media stream components can be used right now, and with what parameters. Using an actual configuration doesn't need any further negotiation 💅.
An actual configuration can, for example, be that the "PCMU" codec and the "RTP/SAVP" transport protocol are offered for use right now.
- A negotiation process that takes the set of actual and potential configurations (combinations of capabilities) as input and produces the negotiated actual configurations as output 👑.
SDP by itself was only designed to provide one of these, namely listing the actual configurations. Over the years, though, people have stretched SDP way past its original scope 😅. The biggest example is the session negotiation semantics defined by the offer/answer model in RFC 3264. In that model, both the offer and the answer contain actual configurations, and separate capabilities and potential configurations aren't supported.
There are other relevant extensions too. RFC 3407 [RFC3407] defined simple capability declarations, which extend SDP with a simple and limited set of capability descriptions. RFC 5888 [RFC5888] defined grouping of media lines, which sets out how media lines in SDP can have semantics other than the traditional "simultaneous media streams" meaning, etc. 🌈
Each of these extensions was built to fix one specific limitation of SDP. Since SDP was already stretched beyond what it was meant for, a more comprehensive capability declaration and negotiation process was intentionally not defined 🙅♀️. Instead, work started on a "next generation" protocol for session description and capability negotiation [SDPng]. SDPng defined a comprehensive capability negotiation framework and protocol that wasn't bound by existing SDP constraints. The catch was that SDPng wasn't designed to be backwards compatible with existing SDP, so both sides had to support it, with a graceful fallback to legacy operation when needed. That, plus the lack of ubiquitous multipart MIME support in the protocols that carry SDP or SDPng, made migrating to SDPng really hard. In practice, SDPng never caught on, and as of the time this document was published, work on SDPng had stopped 🥀.
Real-time multimedia protocols like SIP, Real Time Streaming Protocol (RTSP), Megaco, and Media Gateway Control Protocol (MGCP) are all still using SDP. But SDP doesn't handle an increasingly important problem: negotiating one or more alternative transport protocols (e.g., RTP profiles) and their associated parameters (e.g., SDP attributes). That makes it hard to roll out new RTP profiles like Secure RTP (SRTP) [RFC3711], RTP with RTCP-based feedback [RFC4585], and so on 😤. The problem gets worse because RTP profiles are defined independently. When a new profile gets defined and N other profiles already exist, there may be a need to define N additional profiles, since profiles can't be combined automatically. For example, supporting plain and Secure RTP, with and without RTCP-based feedback, needs four separate profiles (and so four separate profile definitions): RTP/AVP [RFC3551], RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and RTP/SAVPF [RFC5124]. On top of the pressing profile negotiation problem, other real-life limitations have shown up too. For example, keying material and other parameters need to be negotiated with some transport protocols but not others. Similarly, some media formats and types of media streams need to negotiate a variety of different parameters 🧚.
The purpose of this document is to define a mechanism that lets SDP provide limited support for indicating capabilities and their associated potential configurations, and for negotiating the use of those potential configurations as actual configurations 🎯. It is not meant to be a full-fledged capability indication and negotiation mechanism along the lines of SDPng or ITU-T H.245. Instead, the focus is on a set of well-known real-life limitations. More specifically, the solution here provides a general SDP Capability Negotiation framework that's backwards compatible with existing SDP. It also defines exactly how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and formats) may be provided in other documents 🌸.
As mentioned above, SDP is used by several protocols, so the mechanism should be usable by all of them. One especially important protocol for this problem is the Session Initiation Protocol (SIP) [RFC3261]. SIP uses the offer/answer model [RFC3264] (which isn't specific to SIP) to negotiate sessions, so the mechanism defined here provides the offer/answer procedures to use for the capability negotiation framework 💜.
The rest of the document is laid out like this. In Section 3, we present the SDP Capability Negotiation solution, which consists of new SDP attributes and associated offer/answer procedures. In Section 4, we give examples showing how it's used. In Section 5, we cover the security considerations 🔐.
2. Conventions Used in This Document 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.
3. SDP Capability Negotiation Solution 🦋
In this section, we first walk through the conceptual model behind the SDP Capability Negotiation framework, then give an overview of the SDP Capability Negotiation solution 🧠. After that, we define the new SDP attributes for the solution and lay out its updated offer/answer procedures 💖.
3.1. SDP Capability Negotiation Model ✨
okay so our model is built on four concepts 💅:
- Capabilities
- Potential Configurations
- Actual Configurations
- Negotiation Process
these are all defined in Section 1, so bestie, scroll up if you forgot 🧚
Conceptually, we want to offer more than just the actual configuration SDP session description. That one is handled by the offer/answer model in [RFC3264] 🎀. We also want to send one or more alternative SDP session descriptions, which are called potential configurations 🦋. The answerer must choose either the actual configuration or one of the potential configurations, and then generate an answer SDP session description based on that choice. The offerer may need to do some processing on the answer, and that depends on which offer got picked (actual or potential) 🤔. So the answerer tells the offerer which configuration it went with. Here's how it plays out conceptually 💜:
Offerer Answerer
======= ========
1) Generate offer with actual
configuration and alternative
potential configurations
2) Send offer with all configurations
+------------+
| SDP o1 |
| (actual |
| config |
| |-+ Offer
+------------+ | -----> 3) Process offered configurations
| SDP o2 | in order of preference indicated
| (potential | 4) Generate answer based on chosen
| config 1) |-+ configuration (e.g., o2), and
+------------+ | inform offerer which one was
| SDP o3 | chosen
| (potential |
| config 2) |-+
+------------+ |
| SDP ... |
: :
+------------+
| SDP a1 |
Answer | (actual |
<----- | config,o2)|
| |
5) Process answer based on +------------+
the configuration that was
chosen (o2), as indicated in
the answerThe diagram above shows the big idea 🌈. The actual solution is a single SDP session description. It holds the actual configuration (just like normal SDP session descriptions and the offer/answer model in [RFC3264]), plus several new attributes and the procedures attached to them. Those attributes are what encode the capabilities and the potential configurations. So a more accurate picture of the actual offer SDP session description looks like this 👑:
+--------------------+
| SDP o1 |
| (actual |
| config |
| |
| +-------------+ |
| | capability 1| |
| | capability 2| |
| | ... | |
| +-------------+ | Offer
| | ----->
| +-------------+ |
| | potential | |
| | config 1 | |
| | potential | |
| | config 2 | |
| | ... | |
| +-------------+ |
| |
+--------------------+This structure exists for two reasons 🍓:
- Backwards compatibility: As noted above, support for multipart MIME is not ubiquitous. By encoding both the capabilities and the potential configurations in SDP attributes, we can fit everything into a single SDP session description, so we dodge any multipart MIME support issues 🙈. Also, since unknown SDP attributes are ignored by the SDP recipient, entities that don't support the framework just run the regular RFC 3264 offer/answer procedures. Seamless backwards compatibility, no cap ✨.
- Message size efficiency: When we have multiple media streams, and each one might use two or more different transport protocols with a bunch of different parameters, the number of potential configurations can get huge 😭. If every possible alternative were written out as a complete SDP session description in an offer, messages could get massive really fast. A more compact encoding keeps message sizes much more efficient 💅.
Next up, we get into the exact structure and the specific SDP parameters used to represent all of this 🦋.
3.2. Solution Overview ✨
okay bestie, the whole solution is basically a group project with a few moving parts 💅 here's the lineup:
- Two new SDP attributes to support extensions to the framework itself, as follows:
- A new attribute (
a=csup) that lists the supported base (optionally) and any supported extension options to the framework. 🎀 - 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. 🔒
- A new attribute (
- Two new SDP attributes used to express capabilities as follows (additional attributes can be defined as extensions): 🌸
- A new attribute (
a=acap) that defines how to list an attribute name and its associated value (if any) as a capability. - A new attribute (
a=tcap) that defines how to list transport protocols (e.g.,RTP/AVP) as capabilities.
- A new attribute (
- Two new SDP attributes to negotiate configurations as follows: 🦋
- 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 them=line and its associated parameters.
- A new attribute (
this preference order was chosen to give maximum backwards compatibility for the capability negotiation framework and the possible values offered for a session 🧚 for example, say an entity wants a Secure RTP media stream but is totally fine accepting plain RTP (the least common denominator for most endpoints). it can offer plain RTP in the actual configuration and use the capability negotiation extensions to signal that it prefers Secure RTP. entities that don't support the capability negotiation extensions or Secure RTP will just default to plain RTP 💜
- 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. ✨
- 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 easiest to see in this offer/answer exchange, 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. 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=1so the m= line says Alice is offering plain RTP with PCMU or G.729 🍓 the capabilities come from a=tcap and a=acap. the transport capability (a=tcap) says Secure RTP under the AVP profile (RTP/SAVP) is supported, with a transport capability handle of 1. the acap attribute gives an attribute capability with a handle of 1, and that one is a crypto attribute carrying the keying material for SRTP using SDP security descriptions [RFC4568]. then a=pcfg points at those capability parameters to describe the potential configuration. there is one alternative, configuration number 1, made of transport protocol capability 1 (the RTP/SAVP profile, aka Secure RTP) and attribute capability 1 (the crypto attribute). potential configurations beat the actual configuration in the offer, so Alice is basically saying "I'd really like Secure RTP, please" 🥹
Bob gets Alice's offer. Bob supports SRTP and the SDP Capability Negotiation framework, so he accepts the (preferred) potential configuration for Secure RTP and sends back this answer 💖
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=1Bob puts a=acfg in the answer to tell Alice he built his answer on potential configuration 1, using transport protocol capability 1 and attribute capability 1 from the offer (so the RTP/SAVP profile with the keying material provided). he also includes his own keying material in a crypto attribute 🔑 if Bob had supported any extensions to the Capability Negotiation framework, he would have put those option tags in the answer too (in an a=csup attribute) 🌈
once Alice gets Bob's answer, the session negotiation is technically done. BUT Alice still sends a brand new offer using the negotiated configuration as the actual configuration 🤔 she does this purely to help any intermediaries sitting between Alice and Bob that don't support the SDP Capability Negotiation framework. those middle boxes might not understand the negotiation that just happened, so this new offer keeps them in the loop 🧚♀️
Alice's updated offer includes only SRTP, and it doesn't use the SDP Capability Negotiation framework (she could have included the capabilities too 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:4now the m= line says Alice is offering Secure RTP with PCMU or G.729 🔒 the crypto attribute with the SRTP keying material shows up again with the same value.
Bob gets this offer, accepts it, and sends 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:4Bob includes the same crypto attribute as before, and the session just carries on without any changes ✨ Bob didn't put any capabilities in his answer, but he could have if he'd wanted to.
Quick note: in this example the answerer supported the capability negotiation extensions defined here. If he hadn't, he would have simply ignored the new attributes and accepted the offer's actual configuration to use normal RTP 🌸 in that case, this 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 183.3. Version and Extension Indication Attributes 🌟
in this section we introduce the new attributes used to indicate which SDP Capability Negotiation extensions are supported and which are required 🦋
3.3.1. Supported Capability Negotiation Extensions Attribute ✨
okay so the SDP Capability Negotiation solution lets people define new extensions 🦋 Each extension gets an option tag that identifies it, and option tags MUST be registered with IANA per the procedures in Section 6.2 💅
The Supported Capability Negotiation Extensions attribute ("a=csup") is a comma-separated list of option tags. It tells everyone which SDP Capability Negotiation extensions the entity that generated the SDP session description supports 🌸 It can live at the session level or the media level, and it looks like this:
a=csup: <option-tag-list>RFC 4566, Section 9, has the ABNF [RFC5234] for SDP attributes. The "csup" attribute follows the RFC 4566 "attribute" production, with an att-value that goes like this:
att-value = option-tag-list
option-tag-list = option-tag *("," option-tag)
option-tag = token ; defined in [RFC4566]There's a special base option tag called "cap-v0" 🎀 It's for the basic SDP Capability Negotiation framework in this document. Entities can use it with "a=csup" to say they support this framework. Also, white space is not allowed in this rule, so no sneaky spaces 🙅♀️
Here are some examples using "cap-v0" and two made-up option tags, "foo" and "bar" (see how there's no white space?) ✨
a=csup:cap-v0
a=csup:foo
a=csup:bar
a=csup:cap-v0,foo,barThe "a=csup" attribute can go at the session level and the media level. At session level it covers the whole SDP session description. At media level it only covers that one media description, though option tags from the session level still apply too 💜 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. The exception is when those option tags are already in one or more "a=creq" attributes (see Section 3.3.2) at the relevant levels 🫶 Including the base option tag is OPTIONAL. You can tell the base framework is supported just from the presence of the "a=pcfg" attribute defined in Section 3.5.1, so it's not a big deal 👑
Using the base option tag can still be handy in some situations, e.g., when using SIP OPTIONS [RFC3261] or when 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") is a comma-separated list of option tags (see Section 3.3.1). It names the SDP Capability Negotiation extensions that MUST be supported by the entity receiving the SDP session description, so that entity can actually process the SDP Capability Negotiation attributes and their procedures 😭 You don't need the base option tag ("cap-v0") in "creq", because anything that understands "creq" already knows the base tag. Still, it's totally allowed to include it 💅
Why does this matter? Well, it could be super important if a future version of the Capability Negotiation framework wasn't backwards compatible 💀
The attribute can go at the session level and the media level, and it's defined like this:
a=creq: <option-tag-list>The "creq" attribute follows the RFC 4566 "attribute" production, with this att-value:
att-value = option-tag-listExamples with the "cap-v0" base option tag and the made-up "foo" and "bar" tags (again, no white space) 🌈
a=creq:cap-v0
a=creq:foo
a=creq:bar
a=creq:cap-v0,foo,barThe "a=creq" attribute can go at the session level and the media level. Session level covers the whole SDP session description. Media level only covers that media description, though required option tags from the session level still apply too 🍓 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 needs the recipient 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 for those required extensions, at the session and/or media level. If an extension is only needed in one or more specific potential configurations, the potential configuration can say 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), so it is not required to include "a=creq" with the base option tag ("cap-v0") ✨
A recipient that gets an SDP session description and doesn't 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 act as if the SDP Capability Negotiation attributes weren't included at all, i.e., the capability negotiation attributes get ignored 🙈 In that case, if the recipient is an SDP answerer [RFC3264], it SHOULD include a "csup" attribute in the resulting SDP session description answer, listing the SDP Capability Negotiation extensions it actually supports 🫶
This makes sure that introducing the SDP Capability Negotiation mechanism by itself doesn't cause session failures 🥹
For unsupported extensions provided at the session level, this means SDP Capability Negotiation MUST NOT be performed at all. For unsupported extensions at the media level, it means SDP Capability Negotiation MUST NOT be performed for that media stream 🚫
If an entity doesn't support the SDP Capability Negotiation framework at all, it'll just ignore these attributes (along with the other SDP Capability Negotiation attributes) and won't do any SDP Capability Negotiation in the first place 💅
3.4. Capability Attributes 💜
In this section we introduce the new attributes used for indicating capabilities for SDP Capability Negotiation 🧚
3.4.1. Attribute Capability Attribute 🎀
Attributes and their values can be expressed as capabilities using a brand-new attribute capability attribute ("a=acap") 💖 It's defined like this:
a=acap: <att-cap-num> <att-par>Here, <att-cap-num> is an integer between 1 and 2^31-1 (both included) that numbers the attribute capability. <att-par> is an attribute ("a=") in its "<attribute>" or "<attribute>:<value>" form, which means without the "a=" part (see [RFC4566]). The attribute can go at the session level and the media level ✨
The "acap" attribute follows the RFC 4566 "attribute" production, with this att-value:
att-value = att-cap-num 1*WSP att-par
att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
att-par = attribute ;defined in [RFC4566]White space is not permitted before the att-cap-num, so don't sneak any in 🙅♀️
When an attribute capability contains a session-level attribute, that "acap" attribute can only be provided at the session level. The other way around, media-level attributes can be provided in attribute capabilities at either the media level or the session level. The base SDP Capability Negotiation framework only defines procedures for media-level attribute capabilities at the media level, though 🤔 Implementations that only conform to the base framework MUST NOT generate media-level attribute capabilities at the session level. Extensions can change that, though (see, e.g., [SDPMedCap] for one such extension), so all implementations MUST still be prepared to receive such capabilities (see Section 3.6.2 for processing rules) 🌸
Every 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 🦋
We need to be able to reference both session-level and media-level attributes in potential configurations at the media level. This gives us a simple way to avoid overlap between the references (handles) to each attribute capability 💅
The <att-cap-num> values are independent of the similar <cap-num> values used for other types of capabilities. In other words, they form a separate name-space for attribute capabilities 🧚
Here are some examples of the "acap" attribute in action 👑
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:32The first two attribute capabilities give attribute values for the ptime attribute. The third provides SRTP parameters using Multimedia Internet KEYing (MIKEY) [RFC3830] with the "key-mgmt" attribute [RFC4567]. The fourth provides SRTP parameters through security descriptions with the "crypto" attribute [RFC4568]. Heads up: the line-wrapping and new-lines in examples three and four are just for formatting. They're not allowed in real SDP session descriptions 🙈
If you know RFC 3407, you'll notice the "acap" attribute looks a lot like the RFC 3407 "cpar" attribute 👀 There are a couple of big differences, though. The "acap" attribute has a handle, so you can reference it, and it only supports attributes (the "cpar" attribute in RFC 3407 also handles bandwidth information). The "acap" attribute also isn't automatically tied to any particular capabilities. Check out Section 3.14 for how it relates to RFC 3407 💖
Attribute capabilities MUST NOT embed any capability negotiation parameters. This 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. These examples are invalid attribute capabilities, so they 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 from expanding these capabilities into potential configurations (see Section 3.6.2 for further details) 🌈
3.4.2. Transport Protocol Capability Attribute 🚚✨
okay so transport protocols can be expressed as capabilities too, bestie 🦋 with a brand new Transport Protocol Capability attribute, which is a=tcap (cute, right? 🎀). It looks like this:
a=tcap: <trpr-cap-num> <proto-list>where <trpr-cap-num> is an integer between 1 and 2^31-1 (both included) that numbers the transport address capability so you can reference it later 🔢, and <proto-list> is one or more <proto> values separated by white space, same as in the SDP "m=" line 💅. The attribute can be provided at the session level and the media level 🌸.
The "tcap" attribute follows the RFC 4566 "attribute" production, with an att-value that goes like this:
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]Also, white space is NOT allowed before the trpr-cap-num, so don't even try 🙈.
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 tied to the value <trpr-cap-num>, the second one to the value one higher, and so on 🪜. There MUST NOT be any capability number overlap between different "tcap" attributes in the entire SDP session description, no exceptions 💀. The <trpr-cap-num> values are independent of the similar <cap-num> values used for other capability attributes, which means they form their own separate name-space for transport protocol capabilities 🧚. Consecutive numbering of the <trpr-cap-num> values in different "tcap" attributes is not required, so you do you 🌈.
Here are some 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/SAVPThe first one gives you a capability for the "RTP/AVP" profile from [RFC3551], and the second one gives you a capability for RTP with RTCP-based feedback, from [RFC4585] 📻. The third one gives you capabilities for "RTP/SAVP" (transport capability number 3) and "RTP/SAVPF" (transport protocol capability number 4) 🎶. The last one gives you capabilities for "UDP/TLS/RTP/SAVP", which is DTLS-SRTP from [RFC5764] (transport capability number 5) 🔐.
The "tcap" attribute by itself can only specify transport protocols as defined by <proto> in [RFC4566]. A full specification of a media stream, though, needs the transport protocol to be further qualified by one or more media format descriptions, and those often depend on the transport protocol too 🧠. For 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"), and so on ☎️. In a non-SDP context, some media formats could be seen as transports themselves (e.g., T.38), but in the context of SDP and SDP Capability Negotiation, they are not 🙅♀️. If capability negotiation is needed for such media formats, they MUST all either be valid under the transport protocol indicated in the "m=" line for that 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, whether or not it also shows up in a "tcap" attribute 🫶. BUT, 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 honestly it is, from the offerer's point of view), but 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 lets new types of capabilities be defined as extensions and used with the general capability negotiation framework 🪄. The syntax and semantics of those new capability attributes are NOT defined here, but if they're going to be used with potential configurations, they SHOULD allow a numeric handle to be associated with each capability 🔢. That 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 an extension capability attribute MUST also state whether it can be applied at the session level, the media level, or both 🎯. Extensions can have option tags defined for them too, and option tags MUST be registered with the IANA following the procedures 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 to any extensions defined. The reason for this restriction is to avoid overly complex processing rules that would result from expanding 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 🧐. Be careful, bestie 😭.
3.5. Configuration Attributes 🎀💜
3.5.1. Potential Configuration Attribute 💜🔮
Potential configurations can be expressed with a new Potential Configuration Attribute, which is a=pcfg 🦄. It's defined like this:
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 follows 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-listThe missing productions are defined below. White space is NOT permitted before the config-number, so keep that in mind 🙈.
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 🪆. Each one 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 (it only has media-level scope) 🔒. The configuration number also tells you the relative preference of potential configurations, where lower numbers are preferred over higher numbers 📈. Consecutive numbering of the configuration numbers in different "pcfg" attributes in a media description is not required, so no stress 🌸.
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 build a new internal version of the SDP session description, using purely syntactic add and (possibly) delete operations on the original SDP session description (the actual configuration) 🛠️. The result is an alternative potential configuration SDP session description that can be used by conventional SDP and offer/answer procedures if it gets 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) get 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, but 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 them indicates not only a willingness, but in fact a desire, to use that potential configuration 💖.
The example SDP session description below has 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=1Potential configuration 1 has 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 has a transport protocol configuration list that references transport capability 2 ("RTP/SAVPF") and an attribute configuration list that references attribute capability 1 ("a=crypto:...") too 🔐✨.
Attribute capabilities are used in a potential configuration through 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 = "-"Okay, bestie, so this grammar is basically the blueprint for how the attribute list gets built 🧱✨ Quick heads up: white space is not allowed anywhere inside the attribute-config-list rule 🙅♀️ So no sneaky spaces, we don't do that here 💅
Every attribute configuration list can optionally start with instructions for what to do with attributes that are already in the actual configuration SDP session description 🎀 (aka the a= lines that were already in the original SDP). By default those attributes just stay as part of the potential configuration, no drama 🌸 But the delete instructions change that:
- If delete-attributes says
-m, then every attribute line inside the media description gets deleted in the resulting potential configuration SDP (so all thea=lines under thatm=line are gone 🗑️) - If it says
-s, then all the session-level attribute lines get deleted (everya=line before the firstm=line) 🧹 - If it says
-ms, then you delete both the attribute lines in that media description and the session-level ones 💀 total wipeout
Next up is the attribute capability list (if it's included) 📋 This bad boy holds one or more alternative lists of attribute capabilities. The alternative lists are split by a vertical bar (|), and inside each list the capabilities are split by commas (,) 🦋 Each attribute capability is either mandatory or optional. Mandatory ones MUST be supported before you can use the potential configuration 🔒, while optional ones MAY be supported to use it 🫶
Inside each list, all the mandatory ones go first and all the optional ones go last 🏁 Optional ones get wrapped in square brackets ([ and ]) 🎀 Each capability is just an attribute capability number (att-cap-num) that points at a specific attribute capability defined above, so it MUST be between 1 and 2^31-1 (both included) 🔢 Here's an example to make it click ✨
a=pcfg:1 a=-m:1,2,[3,4]|1,7,[5]Breaking it down 🍓
a=-m:1,2,[3,4]|1,7,[5]is the attribute configuration list-mmeans delete all attributes from the media description of the actual configuration1,2,[3,4]and1,7,[5]are both attribute capability lists. They're alternatives, since a vertical bar separates them 🥹1,2, and7are mandatory attribute capabilities3,4, and5are optional attribute capabilities
Now here's the plot twist 🌈 In that example we've got one handle (1) for the potential configuration, but there are actually two different potential configurations, split by that vertical bar. The reason is message size efficiency 📦 which matters a lot once we start adding other types of capabilities to the mix 😭 Now, if you really need a unique handle for each one, then you MUST use separate a=pcfg attributes with different handles instead 💅
Every attribute capability referenced in the potential configuration gets its attribute name and its value (the one inside the capability) added to the resulting potential configuration SDP session description ✨
Alternative attribute capability lists are separated by a vertical bar (|), and that bar's scope reaches all the way to the next alternative. (Basically , has higher precedence than | 🧠) The alternatives are ordered by preference, with the fave listed first 👑 For a recipient of the SDP session description (say, an answerer who got this in an offer) to use the potential configuration, exactly one of the alternative lists MUST be selected in its entirety 🎯 That means every mandatory attribute capability in the potential configuration has to be supported with the attribute values given. No cherry-picking, periodt 💅
Next, transport protocol configuration lists go into a potential configuration through the transport-protocol-config-list parameter 🚚 Here's its grammar:
transport-protocol-config-list =
"t=" trpr-cap-num *(BAR trpr-cap-num)
trpr-cap-num = 1*10(DIGIT) ; defined in [RFC5234]Yep, white space is not permitted in this rule either 🙅♀️ The trpr-cap-num points at the transport protocol capability numbers defined above, so it MUST be between 1 and 2^31-1 (both included) 🔢 Alternative transport protocol capabilities are split by a vertical bar (|), ordered by preference with the most preferred first 🥇 If a potential configuration has no transport protocol capabilities at the media level, then the transport protocol info from the associated m= line MUST be used 📻 And again, for a recipient to use the potential configuration, exactly one of the alternatives MUST be selected, which requires that the transport protocol in question is supported ✅
Heads up, babe: in the presence of intermediaries (which we may not even know are there 👀), be careful about assuming the transport protocol in the m= line won't get modified by one. Using an explicit transport protocol capability guards against the capability negotiation problems that could come from that 🛡️
Extension capabilities can also be included in a potential configuration, using extension configuration lists 🧚 These 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]White space is not permitted in this rule either, obviously 🫠 The ext-cap-name is the name of the extension capability, and ext-cap-list is just a sequence of visible characters. The actual extension that's supported MUST refine both of these further 🔍 For extension capabilities that only need to be referenced by a capability number, it is RECOMMENDED to follow a structure similar to what's specified above ✨
Here's the important bit 🚨 Unsupported or unknown potential extension configuration lists in a potential configuration attribute MUST be ignored, unless they start with a plus (+) sign. That plus sign says the extension is mandatory, so it MUST be supported to use that potential configuration 💪
Pro tip (this is a note, not a rule, so no cap): the creq attribute and its rules can be used to make sure required extensions are supported in the first place 🎀
Extension configuration lists define brand new potential configuration parameters, so they MUST be registered with IANA following the procedures in Section 6.3 📝 No going rogue, we register everything 💅
Potential configuration attributes can only be provided at the media level 🎯 But they can reference capabilities provided at either the session or media level 🙌 There are some semantic rules and restrictions that come with that, so let's get into it 🤓
A (media-level) potential configuration attribute in a given media description MUST NOT reference a media-level capability that's in a different media description 🚫 If it does, that potential configuration gets invalidated (and yes, one potential configuration attribute can hold more than one potential configuration through alternatives, so keep that in mind 🧠). It can, however, reference a session-level capability 🫶 What that means depends on the type of capability. For transport protocol capabilities, it doesn't really imply anything special 🤷♀️ For attribute capabilities, though, it totally does 👀 The attribute name and value (from inside that attribute capability) will count as part of the resulting SDP for that configuration at the session level 🎀 It's basically as if that attribute had been given at the session level in the first place 💖 Because of that, 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 drop a media-level attribute up at the session level 😭 Extensions can change this behavior, but only if they stay fully backwards compatible with the base spec ✨
Each media stream does its own capability negotiation, so one media stream might pick a configuration without a session-level attribute that another media stream picked 🙈 That session-level attribute still stays "active" though, and it applies to the entire resulting potential configuration SDP session description 🌸 In theory this can be a problem if one or more session-level attributes conflict with, or might interact in an undefined way with, another session-level or media-level attribute 💀 In practice, though, these examples seem pretty rare (at least with the SDP attributes that were defined when this document was published) 🍓
Related issue time 🫣 Problems can also pop up if we need coordination between session-level attributes from multiple media streams for a particular feature to work 🧩 The grouping framework [RFC5888] is a good example of this. If we use SDP Capability Negotiation to pick a session-level group attribute (provided as an attribute capability), and we need two media descriptions to do this consistently, things could go sideways 😬 The Forward Error Correction (FEC) grouping semantics [RFC4756] are one example where this could in theory cause problems, but in practice it's unclear whether there's a real problem with the grouping semantics defined when this document was published 🤷♀️
Fixing all of this in general would take inter-media stream constraints and synchronized potential configuration processing 😵💫 That would add a LOT of complexity to the overall solution 🫠 In practice, with the SDP attributes defined when this document was published, it doesn't seem to be a significant problem, so the base SDP Capability Negotiation solution doesn't actually try to solve this issue 🙅♀️ Instead, it is RECOMMENDED that session-level attributes are avoided in a potential configuration when possible 🌷 And when they can't be avoided, that use should be looked at 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 happen at the receiving entity 😳 That basically means mechanisms that might interact like this can't be used in security-critical contexts 🔐 Not worth the risk, bestie 💅
Last but not least, session-level operation of extension capabilities is undefined 🌫️ So each new session-level extension capability that gets defined MUST specify what it implies when it becomes part of a configuration at the media level 📝 Every extension has to spell out its own plot 🎬✨
Okay so the potential configuration example is literally giving 👑 two configs in one line, and we're about to see how the answerer picks one. Let's go 💅
Here's a full media description so you can see the a=pcfg attribute doing its thing:
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|2Two potential configuration attributes 🎀 The first one is the main character 👑 because its configuration number is "1", which makes it the most preferred. It says either RTP/SAVPF or RTP/SAVP (transport protocol capability numbers 4 and 3) can be used, paired with attribute capability 1, which is the "crypto" attribute. RTP/SAVPF wins over RTP/SAVP because its capability number (4) comes first in the preferred potential configuration. ngl this is the kind of ordering detail that matters. Also, even though there's only one potential configuration attribute and one handle, there are actually two potential configurations in there. Iykyk. ✨
The second potential configuration attribute says RTP/AVPF or RTP/AVP can be used, with RTP/AVPF as the favourite. This is the non-secure RTP option, and it's the less preferred one because its configuration number is "8" 🙈 Again, that's two potential configurations, so the whole SDP session description has four potential configurations total. Lowkey iconic. 🦋
3.5.2. Actual Configuration Attribute 🌸
The actual configuration attribute tells everyone which of the potential configurations from the offer got picked and used to build the answer. The answerer does this by including the configuration number plus whichever configuration lists from the offer it selected and used during its offer/answer procedure. The rules are:
- 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 weren't included in the potential configuration, they obviously won't show up here either. 💅
- A selected transport protocol configuration MUST include the selected transport protocol capability number. 🚀
- A selected potential extension configuration MUST include the selected extension configuration parameters, as specified for that particular extension. 🧚
- When a configuration list contains alternatives (separated by "|"), the selected configuration only MUST be provided. 🫶
Note that the selected configuration number and every selected capability number in the actual configuration attribute refer to the offer, not the answer. ⭐
The answer can also include its own capabilities to tell the offerer what the answerer supports beyond the negotiated configuration. The actual configuration attribute doesn't refer to any of those answer-side capabilities though, so don't mix them up! 💀
The Actual Configuration Attribute ("a=acfg") is defined like this:
a=acfg: <config-number> [<sel-cfg-list>]Here, <config-number> is an integer from 1 to 2^31-1 (both included) that points at the selected potential configuration. The attribute can only be provided at the media level. 🍓
The "acfg" attribute follows 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. Bestie, one is the limit, no exceptions. 🔥
Here's an example of the "a=acfg" attribute, building on the potential configuration example from before:
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=1This says the answerer used potential configuration number 1 from the offer, with transport protocol capability 4 (RTP/SAVPF) and attribute capability 1 (the "crypto" attribute). The answerer also includes its own "crypto" attribute. Main character energy 🌈
3.6. Offer/Answer Model Extensions ✨
In this section we extend the offer/answer model defined in [RFC3264] so that an offer can include potential configurations. These act as alternative offers the answerer is allowed to accept, instead of the actual configuration(s) in the "m=" line(s). 🦋
The procedures in the following subsections apply to both unicast and multicast streams. 💜
3.6.1. Generating the Initial Offer
okay bestie, so if an offerer wants to use SDP Capability Negotiation (the one defined in this doc) they MUST include the following in the offer: 🎀
- Zero or more attribute capability attributes. There MUST be an attribute capability attribute (
a=acap) as defined in Section 3.4.1 for each attribute name and associated value (if any) that needs to be flagged as a capability in the offer. Attribute capabilities can be included whether or not a potential configuration references them 💅
Session-level attributes and their values MUST be given in attribute capabilities only at the session level 🌸 Media-level attributes and their values, though, can be given in attribute capabilities at either the media level or the session level. Attributes that are allowed at either level can be given in attribute capabilities at either level too ✨
- Zero or more transport protocol capability attributes. There MUST be transport protocol capabilities as defined in Section 3.4.2 with values for each transport protocol that needs to be flagged as a capability in the offer 🦋
Transport protocol capabilities can be included whether or not a potential configuration references them. Transport protocols that apply to multiple media descriptions SHOULD be provided as transport protocol capabilities at the session level, whereas transport protocols that apply only to one specific media description (its m= line) SHOULD be provided as transport protocol capabilities inside that media description. Either way, there MUST NOT be more than a single a=tcap attribute at the session level, and a single a=tcap attribute in each media description 🙈
- Zero or more extension capability attributes. There MUST be one or more extension capability attributes (as outlined in Section 3.4.3) for each extension capability that is referenced by a potential configuration. Extension capability attributes that aren't referenced by a potential configuration can be provided as well 🧚
- Zero or more potential configuration attributes. There MUST be one or more potential configuration attributes (
a=pcfg), as defined in Section 3.5.1, in each media description where alternative potential configurations are to be negotiated. Each potential configuration attribute MUST follow the rules in Section 3.5.1 and the extra rules below 💜
If the offerer needs support for one or more extensions (besides the base protocol defined here), then the offerer MUST include one or more a=creq attributes as follows:
- If support for one or more capability negotiation extensions is required for the entire session description, then option tags for those extensions MUST be included in a single session-level
creqattribute 👑 - For each media description that requires support for one or more capability negotiation extensions not listed at the session level, a single
creqattribute containing all the required extensions for that media description MUST be included within the media description (in line with Section 3.3.2) 🔥
Note that extensions that only need to be supported by one particular potential configuration can use the "mandatory" extension prefix (+) inside that potential configuration (see Section 3.5.1). Lowkey a neat trick 🍓
The offerer SHOULD also include the following:
- A supported capability negotiation extension attribute (
a=csup) at the session level and/or media level, as defined in Section 3.3.2, for each capability negotiation extension the offerer supports and that isn't already included in a matchinga=creqattribute (i.e., at the session level, or in the same media description). Option tags in ana=csupattribute at the session level indicate extensions supported for the entire session description, whereas option tags in ana=csupattribute in a media description indicate extensions supported for only that media description 🌈
Capabilities in an offer just show what the offerer is capable of doing. They are NOT a commitment, or even a hint, that the offerer will use them 🫶 Potential configurations are different: each one is an alternative offer that the offerer would like to use. The answerer MUST use the potential configurations to negotiate and establish the session ⭐
The offerer MUST include one or more potential configuration attributes (a=pcfg) in each media description where the offerer wants to provide alternative offers (as potential configurations). Each potential configuration attribute in a given media description MUST contain a unique configuration number and zero, one or more potential configuration lists, as described in Section 3.5.1. Each potential configuration list MUST refer to capabilities that are provided at the session level or within that particular media description; otherwise, the potential configuration is considered invalid 😭 The base SDP Capability Negotiation framework REQUIRES that potential configurations not reference any session-level attribute capabilities that contain media-level-only attributes. However, extensions may change this behavior, as long as it stays fully backwards compatible with the base specification. Also, it is RECOMMENDED that potential configurations avoid session-level capabilities whenever possible; see Section 3.5.1 🧚
The current actual configuration is included in the m= line (as defined by [RFC3264]) and any associated parameters for the media description (e.g., attribute (a=) and bandwidth (b=) lines). Here's the tea: the actual configuration is by default the least-preferred configuration, so the answerer will try to negotiate use of one of the potential configurations instead 🙈 If the offerer wants a different preference for the actual configuration, the offerer MUST include a corresponding potential configuration with the relevant configuration number (which shows the relative preference between potential configurations). That corresponding potential configuration should simply duplicate the actual configuration 💅
This can be done implicitly (by not referencing any capabilities), or explicitly (by providing and using capabilities for the transport protocol and all the attributes that are part of the actual configuration). The explicit way may help detect intermediaries that modify the actual configuration but aren't SDP Capability Negotiation aware 🔍
Per [RFC3264], once the offerer generates the offer, they must be prepared to receive incoming media in line with that offer. That rule applies here too, but only for the actual configurations provided in the offer. Media received by the offerer according to one of the potential configurations MAY be discarded, until the offerer receives an answer saying what the actual selected configuration is. Once that answer comes in, incoming media MUST be processed in line with the actual selected configuration indicated and the answer received (provided the offer/answer exchange completed successfully) 🌸
This rule assumes the offerer can tell whether incoming media matches the actual configuration offered or one of the potential configurations instead. That may not always be possible 🥺 If the offerer wants to make sure they don't play out any garbage, the offerer SHOULD discard all media received before the answer SDP session description arrives. On the flip side, if the offerer wants to avoid clipping, they SHOULD try to play any incoming media as soon as it's received (with the risk of playing out garbage). Either way, this document places no requirements on the offerer to process and play media before the answer. For more details, see Section 3.9 💖
3.6.2. Generating the Answer
When receiving an offer, the answerer MUST check for a required capability negotiation extension attribute (a=creq) at the session level. If one is found, then capability negotiation MUST be performed. If none is found, then the answerer MUST check each offered media description for a required capability negotiation extension attribute (a=creq) and one or more potential configuration attributes (a=pcfg). Capability negotiation MUST be performed for each media description where either of those is present, following the procedures below 🎀
The answerer MUST first make sure it supports any required capability negotiation extensions:
- If a session-level
creqattribute is provided, and it contains an option tag the answerer doesn't support, then the answerer MUST NOT use any of the potential configuration attributes provided for any of the media descriptions. Instead, the normal offer/answer procedures MUST continue as per [RFC3264]. Furthermore, the answerer MUST include a session-level supported capability negotiation extensions attribute (a=csup) with option tags for the capability negotiation extensions the answerer supports 😱 - If a media-level
creqattribute is provided, and it contains an option tag the answerer doesn't support, then the answerer MUST NOT use any of the potential configuration attributes provided for that particular media description. Instead, the offer/answer procedures for that media description MUST continue as per [RFC3264] (SDP Capability Negotiation is still performed for other media descriptions in the SDP session description). Furthermore, the answerer MUST include a supported capability negotiation extensions attribute (a=csup) in that media description, with option tags for the capability negotiation extensions the answerer supports for that media description 🦋
Assuming all required capability negotiation extensions are supported, the answerer now carries on as follows ✨
For each media description where capability negotiation is to be performed (i.e., all required capability negotiation extensions are supported and at least one valid potential configuration attribute is present), the answerer MUST perform capability negotiation by using the most preferred potential configuration that is valid to the answerer, subject to any local policies. A potential configuration is valid to the answerer if:
- It follows the syntax and semantics provided in Section 3.5.1.
- It contains a configuration number that is unique within that media description.
- All attribute capabilities referenced by the potential configuration are themselves valid (as defined in Section 3.4.1), and each of them is provided either at the session level or within this particular media description.
For session-level attribute capabilities referenced, the attributes inside them MUST NOT be media-level-only attributes. The answerer can only determine this for attributes the answerer supports. If an attribute isn't supported, it will simply be ignored by the answerer and therefore won't make a potential configuration "invalid" 🌈
- okay so every transport protocol capability the potential configuration references has to be valid on its own (that's Section 3.4.2 🧚), AND each one has to be provided either at the session level or inside this particular media description 🎀
- every extension capability the potential configuration references AND the answerer supports has to be valid on its own (as that particular extension defines it), and each one has to be provided either at the session level or within this media description 🌸. Unknown or unsupported extension capabilities MUST be ignored, unless they're prefixed with the plus (
+) sign, which means the extension MUST be supported in order to use that potential configuration. If the extension isn't supported, that potential configuration is not valid to the answerer 💀
The most preferred valid potential configuration in a media description is the valid one with the lowest configuration number 👑. The answerer MUST now process the offer for that media stream based on the most preferred valid potential configuration 💖. Conceptually, the answerer builds an (internal) offer like this. First, all capability negotiation parameters are removed from the offer SDP session description, which leaves an offer SDP session description with the actual configuration, as if SDP Capability Negotiation was never done in the first place 🦋. Secondly, that actual configuration SDP session description gets modified for each offered media stream, based on the capability negotiation parameters that were originally included:
- If a transport protocol capability is included in the potential configuration, it replaces the transport protocol provided in the "m=" line for that media description 🍓.
- If attribute capabilities are present with a delete-attributes session indication (
-s) or media and session indication (-ms), then all session-level attributes from the actual configuration SDP session description MUST be deleted in the resulting potential configuration SDP session description, following the procedures in Section 3.5.1 🧹. If attribute capabilities are present with a delete-attributes media indication (-m) or media and session indication (-ms), then all attributes from the actual configuration SDP session description inside this media description MUST be deleted 🗑️. - If a session-level attribute capability is included, the attribute (and its associated value, if any) inside it MUST be added to the resulting SDP session description. All such added session-level attributes MUST be listed before the session-level attributes that were there initially. Furthermore, the added session-level attributes MUST be added in the order they were provided in the potential configuration (see also Section 3.5.1) 📋.
This lets attributes with implicit preference ordering get added in the order you actually want 💅. The "crypto" attribute [RFC4568] is one such example.
- If a media-level attribute capability is included, then the attribute (and its associated value, if any) MUST be added to the resulting SDP session description within the media description in question. All such added media-level attributes MUST be listed before the media-level attributes that were initially present in that media description. Furthermore, the added media-level attributes MUST be added in the order they were provided in the potential configuration (see also Section 3.5.1) ✨.
- If a supported extension capability is included, then it MUST be processed in accordance with the rules provided for that particular extension capability 🧩.
The above steps MUST be performed exactly once per potential configuration, i.e., there MUST NOT be any recursive processing of any additional capability negotiation parameters that may (illegally) have been nested inside capabilities themselves 🙅♀️. As an example of this, consider the (illegal) attribute capability:
a=acap:1 acap:2 foo:aAfter the above processing has been done, the resulting potential configuration SDP session description will contain the attribute capability:
a=acap:2 foo:aHowever, since we don't do any recursive processing of capability negotiation parameters, this second attribute capability will not be processed by the offer/answer procedure. Instead, it'll just show up as a (useless) attribute in the SDP session description, and further processing will ignore it 🫠.
Note that a transport protocol from the potential configuration replaces the transport protocol in the actual configuration, but an attribute capability from the potential configuration is simply added to the actual configuration 🤔. In some cases, this can leave one or more meaningless attributes in the resulting potential configuration SDP session description, or worse, ambiguous or potentially even illegal attributes 😱. Use of delete-attributes for the session- and/or media-level attributes MUST be done to avoid these scenarios 🛡️. Even so, it is RECOMMENDED that implementations ignore meaningless attributes that may result from potential configurations 🌈.
For example, say the actual configuration was using Secure RTP and included an "a=crypto" attribute for the SRTP keying material. If a potential configuration uses plain RTP, the "crypto" attribute becomes meaningless. The answerer may or may not ignore that meaningless attribute. The offerer can keep things working correctly by using delete-attributes to remove the "crypto" attribute (but then it'll need to provide attribute capabilities to rebuild the SDP session description with the necessary attributes deleted, e.g., rtpmaps) 🙈.
Also, while it's allowed to include media-level attribute capabilities at the session level, the base SDP Capability Negotiation framework defined here doesn't set any procedures for using them, so the answerer effectively ignores them 🫶.
Check Section 3.6.2.1 for examples of how the answerer might conceptually "see" the resulting offered alternative potential configurations 🔍.
The answerer MUST check that he supports all mandatory attribute capabilities from the potential configuration (if any), the transport protocol capability (if any) from the potential configuration, and all mandatory extension capabilities from the potential configuration (if any). If he doesn't, the answerer MUST proceed to the second most preferred valid potential configuration for the media description, and so on 🏃♀️.
- For attribute capabilities, support means the attribute name in the capability is supported, and it can (and will) be negotiated successfully in the offer/answer exchange with the value provided. That doesn't necessarily mean the value is supported in its entirety. For example, the "a=fmtp" parameter often comes with one or more values in a list, where the offerer and answerer negotiate use of some subset of the values provided. Other attributes may have mandatory and optional parts to their values; support for the mandatory part is all that's required here 🎯.
Heads up: whenever an "fmtp" or "rtpmap" parameter is provided as a mandatory attribute capability, the corresponding media format (codec) must be supported and its use must be negotiated successfully. If that's not what the offerer intends, the corresponding attribute capabilities must be listed as optional instead ⚠️.
- For transport protocol capabilities, support means the transport protocol in the capability is supported, and the transport protocol can (and will) be negotiated successfully in the offer/answer exchange 🚚.
- For extension capabilities, the extension MUST define the rules for when the extension capability is considered supported, and those rules MUST be satisfied 📜.
If the answerer has run out of potential configurations for the media description without finding one that's both valid and supported, then the answerer MUST process the offered media stream based on the actual configuration, plus any session-level attributes added by a valid and supported potential configuration from another media description in the offered SDP session description 🥹.
The above process treats potential configuration selection as a per-media-stream thing. Coordination between media streams is sometimes needed, though 🧵. First of all, session-level attributes added by a potential configuration for one media description MUST NOT cause any problems for potential configurations selected by other media descriptions in the offer SDP session description 🙅♀️. If those session-level attributes are mandatory, they MUST furthermore be supported by the session as a whole (i.e., all the media descriptions, if relevant) 🔒. As mentioned earlier, this adds complexity to the overall processing, so it is RECOMMENDED not to use session-level attribute capabilities in potential configurations unless it's absolutely necessary 😮💨.
Once the answerer has selected a valid and supported offered potential configuration for all of the media streams (or has fallen back to the actual configuration plus any added session attributes), the answerer MUST generate a valid virtual answer SDP session description based on the selected potential configuration SDP session description, as "seen" by the answerer using normal offer/answer rules (see Section 3.6.2.1 for examples) 🪄. The actual answer SDP session description is formed from that virtual answer SDP session description as follows: if the answerer selected one of the potential configurations in a media description, the answerer MUST include an actual configuration attribute (a=acfg) within that media description 🎉. The a=acfg attribute MUST identify the configuration number for the selected potential configuration, as well as the actual parameters that were used from that potential configuration. If the potential configuration included alternatives, only the selected alternatives MUST be included 🍒. Only the known and supported parameters will be included. Unknown or unsupported parameters MUST NOT be included in the actual configuration attribute 🚫. In the case of attribute capabilities, only the known and supported capabilities are included, and unknown or unsupported attribute capabilities MUST NOT be included 💜.
The answerer SHOULD also include a supported capability negotiation attribute (a=csup) at the session level, listing the option tags for extensions supported across media streams 💖. If the answerer supports extensions for only particular media descriptions, a supported capability negotiation attribute with those option tags SHOULD go inside each relevant media description ✨. The required capability negotiation attribute (a=creq) MUST NOT be used in an answer 🙅♀️, no exceptions.
The offerer's original actual configuration lives in the offer's media description m= line (and its parameters) 🎀. The answerer MAY send media to the offerer based on that actual configuration as soon as it gets the offer 🚀. But it MUST NOT send media based on that actual configuration if it picks an alternative potential configuration 🙅. If the answerer picks one of the potential configurations, it MAY start sending media right away based on that selection. The offerer MAY discard that media or play it out as garbage until it receives the answer 💀. For more considerations and possible alternatives outside the base SDP Capability Negotiation framework, see Section 3.9. 🦋
If the answerer picked a potential configuration instead of the actual configuration, it is RECOMMENDED that the answerer send back an answer SDP session description as soon as possible 🏃♀️💨. This keeps the risk of the offerer discarding or playing out the media as garbage really low. For SIP [RFC3261] without any extensions, this means that if the offer came in an INVITE message, the answer SDP session description should be provided in the first non-100 provisional response sent back. (Per RFC 3261, the answer would need to be repeated in the 200 response as well, unless a relevant extension such as [RFC3262] is being used 📞.)
3.6.2.1. Example Views of Potential Configurations 🔭
Okay, these examples show how the answerer can conceptually "see" a potential configuration 👀. Let's start with this offered SDP session description:
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tcap:1 RTP/SAVP RTP/AVP
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1|2
m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=pcfg:1 t=1 a=1|3This SDP session description offers an audio stream and a video stream 🎧📹. Each one can use plain RTP (the actual configuration) or Secure RTP (a potential configuration) 🔐. Two keying mechanisms are on the table too: session-level Key Management Extensions using MIKEY (attribute capability 1), and media-level SDP security descriptions (attribute capabilities 2 and 3) 🗝️. There are several potential configurations here, but below is the one the answerer "sees" when using potential configuration 1 for both audio and video, and attribute capability 1 (MIKEY) for both. We've removed all the capability negotiation attributes to keep it clean ✨:
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000Notice that the transport protocol in the media descriptions shows Secure RTP 🔥.
Next up is the offer the answerer "sees" when using potential configuration 1 for both audio and video, with attribute capabilities 2 and 3 (SDP security descriptions) for the audio and video streams respectively. Peep the order the resulting attributes show up in 👀:
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
m=audio 59000 RTP/SAVP 98
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtpmap:31 H261/90000Again, the transport protocol in the media descriptions shows Secure RTP 💜.
And finally, here's the offer the answerer "sees" when using potential configuration 1 with attribute capability 1 (MIKEY) for the audio stream, and potential configuration 1 with attribute capability 3 (SDP security descriptions) for the video stream 🧚:
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tool:foo
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtpmap:31 H261/900003.6.3. Offerer Processing of the Answer 🔍
When the offerer tried to use SDP Capability Negotiation in the offer, the offerer MUST check the answer for actual use of SDP Capability Negotiation 🕵️♀️.
For each media description where the offerer included a potential configuration attribute (a=pcfg), the offerer MUST first check that media description for a valid actual configuration attribute (a=acfg) 🎯. An actual configuration attribute is valid if:
- it refers to a potential configuration that was present in the corresponding offer, and
- it contains the actual parameters that were used from that potential configuration; if the potential configuration included alternatives, the selected alternatives only MUST be included. Note that the answer will include only parameters and attribute capabilities that are known and supported by the answerer, as described in Section 3.6.2. 🧐
If a valid actual configuration attribute isn't in a media description, the offerer MUST process the answer SDP session description for that media stream per the normal offer/answer rules defined in [RFC3264] 📜. But if a valid one is found, the offerer MUST instead process the answer like this:
- The actual configuration attribute tells you which of the potential configurations the answerer used to generate the answer for this media stream 🎀. That includes all the supported attribute capabilities and the transport capabilities referenced by the selected potential configuration, where the attribute capabilities have any associated delete-attributes included. Extension capabilities the answerer supports are included too ✨.
- The offerer MUST now process the answer following the rules in [RFC3264], except it has to be done as if the offer consisted of the selected potential configuration instead of the original actual configuration. That includes any transport protocol changes in the media (
m=) line(s), attributes added and deleted by the potential configuration at the media and session level, and any extensions used 🔄. If this derived answer isn't a valid answer to the potential configuration offer the answerer selected, the offerer MUST instead keep processing as it would for a regular offer/answer exchange, where the answer received doesn't follow the rules of [RFC3264] 🚨.
If the offer/answer exchange was successful, the answerer selected one of the potential configurations from the offer as the actual configuration, and the selected potential configuration differs from the actual configuration in the offer (the m=, a=, etc. lines), then the offerer SHOULD start another offer/answer exchange 🔁. This second exchange won't modify the session in any way 🙅. But it helps intermediaries (e.g., middleboxes) that look at the SDP session description but don't support the capability negotiation extensions understand the details of the media streams that were actually negotiated 🛡️. This new offer MUST contain the selected potential configuration as the actual configuration, i.e., with the actual configuration used in the m= line and any other relevant attributes, bandwidth parameters, etc. 💅
Heads up: per the normal offer/answer rules, this second exchange still needs to update the version number in the o= line (<sess-version> in [RFC4566]) 🔢. Attribute lines carrying keying material SHOULD repeat the keys from the previous offer, unless re-keying is necessary (for example, due to a previously forked SIP INVITE request) 🔑. For more considerations related to intermediaries, see Section 3.12. 🫶
3.6.4. Modifying the Session 🌸
Capabilities and potential configurations may be included in subsequent offers as defined in [RFC3264], Section 8 💫. The process is similar to what's described above, with the answer including an indication of the actual selected configuration the answerer used ✨.
If the answer indicates use of a potential configuration from the offer, then the guidelines in Section 3.6.3 for doing a second offer/answer exchange using that potential configuration as the actual configuration apply 🦋.
3.7. Interactions with ICE 💖
okay so Interactive Connectivity Establishment (ICE) [RFC5245] is how two endpoints check they can actually reach each other, by sending Session Traversal Utilities for NAT (STUN) messages directly between the media endpoints 📡. ngl the basic ICE spec is only defined for UDP-based connectivity, BUT it's built to be extended for other transport protocols, like TCP, which is being specified in [ICETCP] 🦋. ICE also adds a new a=candidate attribute that, among other things, lists the possible transport protocol(s) and gives each one a priority. The most preferred transport protocol that successfully verifies connectivity is the one that ends up getting used 👑.
So when you use ICE, the transport protocol that actually gets used can be different from the one in the m= line. Since both ICE and SDP Capability Negotiation can specify alternative transport protocols, they can interact in a way nobody intended when you use them together 🙈. Here's how we handle that 💅.
There are two basic scenarios to think about:
- A media stream can run over different transport protocols (e.g., UDP, TCP, or TCP/TLS), and the goal is just to use whichever one works, in the preference order that was specified ✨.
- A media stream can run over different transport protocols (e.g., UDP, TCP, or TCP/TLS), and the goal is to let the negotiation process decide which one to use (e.g., T.38 over TCP or UDP) 🎀.
For scenario 1, you should have ICE a=candidate attributes for UDP, TCP, and so on, but otherwise nothing special in the potential configuration attributes to signal that you want different transport protocols. ICE basically handles the capability negotiation you need, because the answerer picks something it supports and then the two sides use trial-and-error connectivity checks 🧚.
Scenario 2 doesn't need ICE at all. Instead, we just use transport protocol capabilities and potential configuration attributes to signal the outcome we want 💜.
The two scenarios can be mixed. For example, you could offer potential configuration alternatives where some only support one transport protocol (e.g., UDP) and others support several (e.g., UDP or TCP). In that case you need really tight control over which ICE candidates get used for a given configuration, but the actual configuration might want to use all of the ICE candidates 🌈. The fix is to define the ICE candidate attributes as attribute capabilities and include the relevant ones in the right potential configurations. So candidate attributes for UDP only go in potential configurations restricted to UDP, while candidate attributes for UDP, TCP, and TCP/TLS can go in potential configurations that can use all three ⭐. Also, using delete-attributes in a potential configuration can make sure ICE won't end up using a transport protocol that isn't wanted for that particular configuration 🔥.
SDP Capability Negotiation recommends a second offer/answer exchange when the negotiated actual configuration was one of the potential configurations from the offer (see Section 3.6.3) 🍓. ICE also needs a second offer/answer exchange if the chosen candidate isn't the same one as the one in the m/c-line from the offer. When ICE and capability negotiation are both in use, the two secondary offer/answer exchanges SHOULD be combined into a single one 🫶.
3.8. Interactions with SIP Option Tags 🎀
SIP [RFC3261] lets SIP extensions define a SIP option tag that identifies the extension. You can indicate support for one or more of these extensions with the SIP Supported header, and indicate that you require support for one or more of them with the SIP Require header 🧁. The a=csup and a=creq attributes from the SDP Capability Negotiation framework are similar, except that support for those two attributes by themselves can't be guaranteed, since they're specified as extensions to the SDP specification [RFC4566] itself 🙃.
SIP extensions with option tags can bring enhancements to SDP as well as SIP. SIP preconditions defined in [RFC3312] are an example 🦋. When you use SDP Capability Negotiation, some potential configurations might include certain SDP extensions while others don't. The whole point of SDP Capability Negotiation is to negotiate a session based on the features both sides support, so using the SIP Require header for those extensions may not give you the result you want. Say one potential configuration requires SIP preconditions support, another doesn't, and the answerer doesn't support preconditions. Using Require for preconditions would make the session fail, even though a valid, supported potential configuration was in the offer 😭.
You can usually fix this with mandatory and optional attribute capabilities in a potential configuration 💅. But sometimes the permitted SDP values are tied to the use of the SIP Require header. SIP preconditions [RFC3312] is one such case: a precondition with a "mandatory" strength-tag can only be used when a SIP Require header with the SIP option tag precondition is included. Future SIP extensions that want to use the SDP Capability Negotiation framework should avoid that kind of coupling 🚫.
3.9. Processing Media before Answer 🌸
The offer/answer model [RFC3264] requires an offerer to be able to receive media according to the offer before it receives the answer. SDP Capability Negotiation keeps that property, but only when the answerer picks the actual configuration. If a potential configuration gets chosen, the offerer might decide not to process any media it receives before the answer arrives, and that can lead to clipping 😬. So the SDP Capability Negotiation framework recommends sending back an answer SDP session description as soon as possible 🏃♀️.
A three-way handshake can fix this. For SIP, you could do that by defining a precondition [RFC3312] for capability negotiation, or by using an existing precondition that is known to generate a second offer/answer exchange before the session proceeds. Preconditions are often seen as complicated to implement, though, and they can add to session establishment delay by requiring an extra offer/answer exchange 🥲.
Another three-way handshake can be done with ICE [RFC5245]. When ICE is in use and the answerer receives a STUN Binding Request for any one of the accepted media streams from the offerer, the answerer knows the offer has received its answer 🎉. At that point the answerer knows the offerer can process incoming media according to the negotiated configuration, so it can start sending media without risking the offerer discarding it or playing garbage 🔊.
Please note that, despite all of the above, this document doesn't place any requirements on the offerer to process and play media before the answer. It just gives recommendations on how to make sure media that the answerer sends and the offerer receives before the answer can actually be rendered by the offerer 💜.
Some use cases don't need a three-way handshake. One example is when the offerer doesn't need information from the answer, such as keying material in the SDP session description, to process incoming media. The SDP Capability Negotiation framework doesn't define any such solutions, but extensions might 🧚. For instance, one technique proposed for best-effort SRTP in [BESRTP] is to give different RTP payload type mappings for different transport protocols used, outside of the actual configuration, while still letting the answerer use them. Exchange of keying material is still needed in that case (e.g., inband). The basic SDP Capability Negotiation framework defined here doesn't include the ability to do that, but extensions that enable it may be defined later ✨.
3.10. Indicating Bandwidth Usage 🍑
How much bandwidth a media stream uses depends on the negotiated codecs, the transport protocol, and other parameters. For example, Secure RTP [RFC3711] with integrity protection needs more bandwidth than plain RTP [RFC3551] 📶. SDP defines the bandwidth (b=) parameter to indicate the proposed bandwidth for the session or the media stream 📊.
In SDP as defined by [RFC4566], each media description contains one transport protocol and one or more codecs. When you specify the proposed bandwidth, the worst case has to be taken into account: use the highest-bandwidth codec provided, the transport protocol indicated, and the worst-case (bandwidth-wise) parameters that can be negotiated (e.g., a 32-bit Hashed Message Authentication Code (HMAC) or an 80-bit HMAC) 🧮.
The base SDP Capability Negotiation framework doesn't give you a way to negotiate bandwidth parameters, so the issue is still there 😵💫. It's potentially worse than with plain SDP per [RFC4566], because it's easier to negotiate additional codecs and it's also possible to negotiate different transport protocols. The recommended approach is the same as for plain SDP: the worst case, which now includes the potential configurations, needs to be taken into account when you specify the bandwidth parameters in the actual configuration. That can make the bandwidth value less accurate than it would be under [RFC4566], because the potential configurations may vary more in bandwidth use. Extensions can be defined to address this shortcoming 🔧.
Note that when you use RTP retransmission [RFC4588] with the RTCP-based feedback profile [RFC4585] (RTP/AVPF), the retransmitted packets count as part of the media stream bandwidth when you use synchronization source (SSRC) multiplexing 🔁. If a feedback-based protocol is offered as the actual configuration transport protocol, and a non-feedback-based protocol is offered as a potential configuration transport protocol and ends up being used, the actual bandwidth usage may be lower than the bandwidth value indicated in the offer. It can also go the other way around 🌈.
3.11. Dealing with Large Number of Potential Configurations
okay bestie, SDP Capability Negotiation is so fun, but it is SO easy to accidentally make a monster offer 💀. Look at this one:
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/SAVPF RTP/SAVP RTP/AVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=acap:2 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=acap:3 rtcp-fb:0 nack
a=pcfg:1 t=1 a=1,3|2,3
a=pcfg:2 t=2 a=1|2
a=pcfg:3 t=3 a=3That's 5 potential configurations on top of the actual configuration for a single media stream 😭. Add an extension capability with just two options for each and you double it to 10 💅. Do the same thing across two media streams and it doubles again to 20 🌀. Generating the offer is cheap and easy for the offerer, but the answering side might have a much harder time processing it 🥲. So it is RECOMMENDED that offerers do not create offers with an unnecessarily large number of potential configurations in them 🎀.
On the answering side, implementers MUST take care to avoid excessive memory and CPU consumption ⚠️. A naive implementation that generates every valid potential configuration SDP session description up front can run out of memory, especially if it supports a lot of endpoints 💀. A naive implementation that just does trial-and-error on each possible potential configuration, in the preference order given, can max out the CPU 🔥. A smarter move is to prune the search space first. You can throw out any offered potential configurations where the transport protocol indicated (if any) isn't supported, and/or where one or more mandatory attribute capabilities (if any) are either unsupported or not valid 🧹. Potential configurations with unsupported mandatory extension configurations in them can be tossed too 🗑️✨.
3.12. SDP Capability Negotiation and Intermediaries
okay so an intermediary is an entity sitting between SIP user agent A and SIP user agent B that has to process the SDP session descriptions exchanged between them so the session setup works the way it's supposed to 🦋. Think Session Border Controllers (SBCs) that do media relaying, or Proxy Call Session Control Functions (P-CSCFs) that authorize how much network bandwidth gets used 💜. These boxes don't always follow the "Internet" model or the SIP rules for proxies (which say they aren't supposed to peek into message bodies like SDP) 🙈. Still, they're a fact of life in some deployments, so they deserve some love and attention 🫶.
If an intermediary needs to understand the characteristics of the media sessions being negotiated (like how much bandwidth gets used or which transport protocol got negotiated), then using SDP Capability Negotiation can affect it 👀. For example, some intermediaries are known to reject answers where the transport protocol is different from the one in the offer, and using this framework with them can cause session failures 💀. Intermediaries that authorize network resources based on the negotiated media stream parameters get affected too. If they only look at the offer, they might authorize parameters based on a different transport protocol, different codecs, and so on, compared to what's actually negotiated 🌸. For these reasons, and others, it is RECOMMENDED that implementers of intermediaries add support for the SDP Capability Negotiation framework 💖.
The framework tries to help these intermediaries out by recommending a second offer/answer exchange once a potential configuration has been negotiated (see Section 3.6.3) ✨. But there are some limitations here, bestie 😩. First, although the second offer/answer exchange is RECOMMENDED, it is not required and so it might not happen at all 🤷♀️. Second, the intermediary might refuse the initial answer, for example because it thinks the transport protocol doesn't match 🚫. Third, the strategy isn't foolproof, because the offer/answer procedures [RFC3264] keep the original offer/answer exchange in effect when a later one fails 💔. Check out this example:
- The offerer generates an SDP session description offer where the actual configuration is a low-bandwidth setup (like plain RTP) and a potential configuration is a higher-bandwidth setup (like Secure RTP with integrity) 🔐.
- An intermediary (like an SBC or P-CSCF) that doesn't support SDP Capability Negotiation authorizes the session based on the actual configuration it sees in the SDP session description 👀.
- The answerer picks the higher-bandwidth potential configuration and generates an answer SDP session description based on that 🙌.
- The intermediary passes the answer SDP session description through 🚪.
- The offerer sees the accepted answer and generates an updated offer that puts the selected potential configuration in as the actual configuration. In other words, the higher-bandwidth configuration (which already got negotiated successfully) is now the actual configuration in the offer SDP session description 🎉.
- The intermediary sees the new offer, but it never authorized the higher-bandwidth configuration, so it generates a rejection message for the offerer 😭.
- The offerer receives the rejected offer 💀.
After step 7, per RFC 3264, the offer/answer exchange that completed in step 5 stays in effect 🥲. The intermediary might never have authorized the network resources it needs, so the media stream could have quality issues 📉. The fix is to upgrade the intermediary so it supports the SDP Capability Negotiation framework 🛠️✨.
3.13. Considerations for Specific Attribute Capabilities
3.13.1. The "rtpmap" and "fmtp" Attributes
so the base SDP Capability Negotiation framework defines transport capabilities and attribute capabilities 🎀. Media capabilities, which describe media formats and their parameters, aren't defined in this document, but the "rtpmap" and "fmtp" attributes can still be used as attribute capabilities 💜. Using them in a potential configuration takes a little bit of care though 👑.
The rtpmap parameter binds an RTP payload type to a media format (like a codec) 🎶. You can give rtpmaps for payload types that aren't in the corresponding "m=" line, but they don't do anything useful in normal offer/answer exchanges 😴. Only the media formats (like RTP payload types) listed in the "m=" line actually get offered. Putting rtpmap attributes for other payload types in a potential configuration doesn't change that, so they don't add any useful info there 🙃. They can still be useful as standalone capabilities (outside a potential configuration) to tell a peer about extra codecs you support 🌈.
It's also possible to give an "rtpmap" attribute capability where the payload type maps to a different codec than the actual configuration's "rtpmap" attribute for the media description. That's allowed as a way of indicating a capability 🍓. But if that capability is included in a potential configuration, then delete-attributes (see Section 3.5.1) MUST be used to make sure there aren't multiple "rtpmap" attributes for the same payload type in a given media description. That would not be allowed by SDP [RFC4566] 🚫.
Similar considerations and rules apply to the "fmtp" attribute. An "fmtp" attribute capability for a media format that isn't in the "m=" line is useless in a potential configuration (but it can still be useful as a capability all by itself) 🧚. An "fmtp" attribute capability in a potential configuration for a media format that already has an "fmtp" attribute in the actual configuration could lead to multiple fmtp format parameters for that media format, and SDP [RFC4566] doesn't allow that 💅. The delete-attributes MUST be used to make sure there aren't multiple "fmtp" attributes for a given media format in a media description 🫶.
Extensions to the base SDP Capability Negotiation framework may change the behavior described above 🔮.
3.13.2. Direction Attributes
SDP defines the "inactive", "sendonly", "recvonly", and "sendrecv" direction attributes 🧭. These can be applied at the session level or the media level. Either way, you can define attribute capabilities for these direction capabilities, and if a potential configuration uses one, the normal offer/answer procedures still apply 💫. For example, if an offered potential configuration includes the "sendonly" direction attribute and it gets selected as the actual configuration, then the answer MUST include a corresponding "recvonly" (or "inactive") attribute 🔁.
3.14. Relationship to RFC 3407
so RFC 3407 defines capability descriptions with limited ways to describe attributes, bandwidth parameters, transport protocols, and media formats 📝. But it doesn't define any negotiation procedures for actually using those capability descriptions 🤷♀️.
This document defines new attributes for describing attribute capabilities and transport capabilities. It also defines procedures for using those capabilities as part of an offer/answer exchange 🎀. Unlike RFC 3407, this document doesn't define bandwidth parameters, and it doesn't define how to express ranges of values 📏. Extensions to this document might be defined to fully cover everything RFC 3407 offers (like more general media capabilities) 🌱.
It is RECOMMENDED that implementations use the attributes and procedures defined in this document instead of the ones defined in [RFC3407] 💖. If you want capability description interoperability with legacy RFC 3407 implementations, implementations MAY include both RFC 3407 capability descriptions and the capabilities defined by this document 🦋. The offer/answer negotiation procedures defined in this document will not use the RFC 3407 capability descriptions 🙅♀️.
4. Examples
okay, this part is all about showing how to actually use SDP Capability Negotiation, and the examples are coming up next 🌸✨.
4.1. Multiple Transport Protocols ✨
okay so this example is giving "pick your fighter" 💅 It shows how SDP Capability Negotiation lets you choose one transport protocol out of a few options. Alice starts with plain RTP (RTP/AVP) as her actual configuration, because that's the least-common-denominator option everyone understands. Then she lists the fancier transport protocols as potential configurations she could switch to 🦋
Here's the offer/answer exchange between Alice and Bob:
Alice Bob
| (1) Offer (RTP/[S]AVP[F]) |
|--------------------------------->|
| |
| (2) Answer (RTP/AVPF) |
|<---------------------------------|
| |
| (3) Offer (RTP/AVPF) |
|--------------------------------->|
| |
| (4) Answer (RTP/AVPF) |
|<---------------------------------|
| |Alice's offer includes four alternatives: plain RTP (RTP/AVP), RTP with RTCP-based feedback (RTP/AVPF), Secure RTP (RTP/SAVP), and Secure RTP with RTCP-based feedback (RTP/SAVPF) 🔐 Plain RTP is the default, and the other three are the alternatives, listed in order of preference: RTP/SAVPF, then RTP/SAVP, then RTP/AVPF. Here's her offer:
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/SAVPF RTP/SAVP RTP/AVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=acap:2 rtcp-fb:0 nack
a=pcfg:1 t=1 a=1,[2]
a=pcfg:2 t=2 a=1
a=pcfg:3 t=3 a=[2]The m= line says Alice is offering plain RTP with PCMU or G.729 🎶 The capabilities come from the a=tcap and a=acap attributes. The tcap attribute tells us that Secure RTP with RTCP-based feedback (RTP/SAVPF), Secure RTP (RTP/SAVP), and RTP with RTCP-based feedback are all supported. The first acap attribute is attribute capability 1, and it's a crypto attribute carrying the keying material for SRTP, using SDP security descriptions [RFC4568] 🗝️ The second acap attribute is attribute capability 2, an rtcp-fb attribute. The RTCP-based feedback profiles use it to say that payload type 0 (PCMU) supports the feedback type "nack" 🙌 The a=pcfg attributes then pull these capabilities together into potential configurations by referring to them by handle. There are three of them:
- Potential configuration 1 is the most preferred one. It uses transport protocol capability 1 (RTP/SAVPF) and attribute capabilities 1 (the
cryptoattribute) and 2 (thertcp-fbattribute). Support for the first attribute capability is mandatory, but support for the second is optional. 🫶 - Potential configuration 2 is the second most preferred. It uses transport protocol capability 2 (RTP/SAVP) and the mandatory attribute capability 1 (the
cryptoattribute). 🔥 - Potential configuration 3 is the least preferred potential configuration. It's technically the second least preferred overall, because the actual configuration from the
m=line always ranks last 💀 It uses transport protocol capability 3 (RTP/AVPF) and the optional attribute capability 2 (thertcp-fbattribute).
Now Bob gets Alice's offer. Bob doesn't support any Secure RTP profiles 😭 But he does support plain RTP and RTP with RTCP-based feedback, plus the SDP Capability Negotiation extensions. So he picks the potential configuration for RTP with RTCP-based feedback that Alice provided. His answer looks like this:
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/AVPF 0 18
a=rtcp-fb:0 nack
a=acfg:1 t=3 a=[2]Bob includes the a=acfg attribute to tell Alice which configuration he based his answer on. In this case it was the offer's potential configuration with transport protocol capability 3 and optional attribute capability 2. In other words, it's the RTP/AVPF profile using the rtcp-fb value Alice provided 🎀 Bob also includes an rtcp-fb attribute with the value "nack" for RTP payload type 0.
Once Alice gets Bob's answer, the session negotiation is technically complete. But Alice chooses to send a brand new offer using the actual configuration anyway 🧚 She does this purely to help any intermediaries sitting between her and Bob. Those intermediaries don't support the SDP Capability Negotiation framework, so they might not understand the negotiation that just happened. Her updated offer looks like this:
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/AVPF 0 18
a=rtcp-fb:0 nackThis offer includes only RTP/AVPF and doesn't use the SDP Capability Negotiation framework at all. Alice could have added the capabilities back in if she'd wanted to 🌸 The m= line now says Alice is offering RTP with RTCP-based feedback, using PCMU or G.729. The rtcp-fb attribute gives the feedback type "nack" for payload type 0 once again, but this time as part of the actual configuration.
Bob gets this offer and accepts it. Then he sends Alice an answer:
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/AVPF 0 18
a=rtcp-fb:0 nackBob includes the same rtcp-fb attribute as before, and the session carries on without any changes ✨ Bob didn't include any capabilities in this answer, but he could have if he'd wanted to.
Quick aside: in this example the answerer supported the SDP Capability Negotiation framework, so he understood the new attributes and procedures defined here. If he hadn't, he would have simply ignored the new attributes he got in step 1 and accepted the offer to use normal RTP instead. In that case, the answer generated in step 2 would have looked like this:
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 184.2. DTLS-SRTP or SRTP with Media-Level Security Descriptions ✨
okay bestie, this one is giving "pick your fave" energy 🦋 It shows how the SDP Capability Negotiation framework can negotiate SRTP using either SDP security descriptions or DTLS-SRTP. Alice wants a Secure RTP audio stream but is totally fine with plain RTP too. Her fave key management protocol is DTLS-SRTP, but she also supports SDP security descriptions 💜 (and [RFC5763] has more DTLS-SRTP examples if you want extra content 🌸).
Here's the offer/answer exchange, where Alice sends an offer to Bob 👀
Alice Bob
| (1) Offer (RTP/[S]AVP,SDES | DTLS-SRTP)|
|--------------------------------------->|
| |
|<--------- DTLS-SRTP handshake -------->|
| |
| (2) Answer (DTLS-SRTP) |
|<---------------------------------------|
| |
| (3) Offer (DTLS-SRTP) |
|--------------------------------------->|
| |
| (4) Answer (DTLS-SRTP) |
|<---------------------------------------|
| |Alice's offer has an audio stream that offers plain RTP and Secure RTP as alternatives 💅 For the Secure RTP option, it can be set up using either DTLS-SRTP or SDP security descriptions:
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 setup:actpass
a=acap:2 fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tcap:1 UDP/TLS/RTP/SAVP RTP/SAVP
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1,2
a=pcfg:2 t=2 a=3So the first (and preferred) potential configuration uses transport capability 1 (UDP/TLS/RTP/SAVP), which is DTLS-SRTP, plus attribute capabilities 1 and 2 (active/passive mode and certificate fingerprint). Both of those must be supported to pick this one 🔥 The second (and less preferred) potential configuration uses transport capability 2 (RTP/SAVP) and mandatory attribute capability 3, which is the SDP security description 🎀
Bob gets Alice's SDP offer, sees that she prefers DTLS-SRTP, and goes with it 🧚 Now he starts the DTLS-SRTP handshake to set up the DTLS-SRTP session (see [RFC5764] for the details).
Bob also sends Alice an answer like this:
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=1 a=1,2For the audio stream, Bob accepted DTLS-SRTP, so the profile in the "m=" line is "UDP/TLS/RTP/SAVP" ✨ He also includes a "setup:active" attribute to say he's the active endpoint for the DTLS-SRTP session, plus the fingerprint for his certificate 🌈 And his "acfg" attribute shows that he picked potential configuration 1 from Alice's offer 👑
When Alice gets Bob's answer, negotiation is technically complete (and she can check the DTLS handshake against Bob's certificate fingerprint in the answer) 🙈 BUT she still chooses to send a brand new offer with the actual configuration. She does this purely to help any intermediaries sitting between Alice and Bob that don't support the capability negotiation extensions, since they might not understand the negotiation that just happened 🫶
Alice's updated offer has only DTLS-SRTP for the audio stream, and it doesn't use the SDP Capability Negotiation framework at all (she could have included the capabilities too if she wanted 💖):
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
m=audio 59000 UDP/TLS/RTP/AVP 98
a=rtpmap:98 AMR/8000The "m=" line for the audio stream now says Alice is offering DTLS-SRTP in active/passive mode, using the certificate fingerprint she included 🦋
Bob gets this SDP offer, accepts it, and then whips up an answer for Alice 💅
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=1 a=1,2Bob includes the same "setup:active" and fingerprint attributes as before, so the session just keeps going with no changes 🌸 Bob didn't put any capabilities in his answer, but he could have if he'd wanted to ✨
Quick note: in this example the answerer supported the capability extensions, but if he hadn't, he would have just ignored the new attributes from step 1 and accepted the offer to use normal RTP 👀 In that case, this answer would have been generated in step 2 instead:
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/AVP 98
a=rtpmap:98 AMR/8000And finally, if Bob had gone with SDP security descriptions instead of DTLS-SRTP, this is the answer that would have been generated 🔐
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:2 t=2 a=34.3. Best-Effort SRTP with Session-Level MIKEY and Media-Level Security Descriptions ✨
okay bestie, this one is giving "offer everything and let the other side pick" energy 💅 It shows how to use the SDP Capability Negotiation extensions to support so-called Best-Effort Secure RTP, plus alternative keying mechanisms, specifically MIKEY [RFC3830] and SDP security descriptions. Alice wants an audio and video session. She prefers session-level MIKEY as her key management protocol, but she supports SDP security descriptions as well 🔐
The offer/answer exchange goes like this, with Alice sending an offer to Bob:
Alice Bob
| (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) |
|--------------------------------------->|
| |
| (2) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
| (3) Offer (RTP/SAVP, SDES) |
|--------------------------------------->|
| |
| (4) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |Alice's offer includes an audio and a video stream. For audio, she offers plain RTP and Secure RTP as alternatives. For video, she offers plain RTP, RTP with RTCP-based feedback, Secure RTP, and Secure RTP with RTCP-based feedback as alternatives 🎬
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=2 a=1|2
m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 rtcp-fb:* nack
a=pcfg:1 t=1 a=1,4|3,4
a=pcfg:2 t=2 a=1|3
a=pcfg:3 t=3 a=4The potential configuration for the audio stream uses transport capability 2 (RTP/SAVP) and either attribute capability 1 (session-level MIKEY as the keying mechanism) or 2 (SDP security descriptions as the keying mechanism). Support for either of these attribute capabilities is mandatory. There are three potential configurations for the video stream:
- The first configuration, with configuration number 1, uses transport capability 1 (RTP/SAVPF) with either attribute capabilities 1 and 4 (session-level MIKEY and the "rtcp-fb" attribute) or attribute capabilities 3 and 4 (SDP security descriptions and the "rtcp-fb" attribute). In this example, the offerer insists not only on the keying mechanism being supported, but also on the "rtcp-fb" attribute being supported with the value indicated. Consequently, all the attribute capabilities are marked as mandatory in this potential configuration. 🔒
- The second configuration, with configuration number 2, uses transport capability 2 (RTP/SAVP) and either attribute capability 1 (session-level MIKEY) or attribute capability 3 (SDP security descriptions). Both attribute capabilities are mandatory in this configuration.
- The third configuration, with configuration number 3, uses transport capability 3 (RTP/AVPF) and mandatory attribute capability 4 (the "rtcp-fb" attribute).
Bob receives the SDP session description offer from Alice. He supports Secure RTP, Secure RTP with RTCP-based feedback, and the SDP Capability Negotiation extensions. He also supports SDP security descriptions, but not MIKEY, so he generates the following answer 🙌
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 t=2 a=2
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=rtcp-fb:* nack
a=acfg:1 t=1 a=3,4For the audio stream, Bob accepted Secure RTP, so the profile in the "m=" line is "RTP/SAVP". He also includes a "crypto" attribute with his own keying material, and an "acfg" attribute identifying actual configuration 1 for the audio media stream from the offer. That uses transport capability 2 (RTP/SAVP) and attribute capability 2 (the "crypto" attribute from the offer). For the video stream, Bob accepted Secure RTP with RTCP-based feedback, so the profile in the "m=" line is "RTP/SAVPF". He also includes a "crypto" attribute with his own keying material, and an "acfg" attribute identifying actual configuration 1 for the video stream from the offer. That uses transport capability 1 (RTP/SAVPF) and attribute capabilities 3 (the "crypto" attribute from the offer) and 4 (the "rtcp-fb" attribute from the offer). 🎉
When Alice receives Bob's answer, session negotiation has completed. However, Alice still chooses to generate a new offer using the actual configuration. This is done purely to assist any intermediaries that may reside between Alice and Bob but do not support the capability negotiation extensions, and hence may not understand the negotiation that just took place 🧚
Alice's updated offer includes only SRTP for the audio stream SRTP with RTCP-based feedback for the video stream, and it is not using the SDP Capability Negotiation framework (Alice could have included the capabilities as well is she wanted):
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=video 52000 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtcp-fb:* nackThe "m=" line for the audio stream now indicates that Alice is offering Secure RTP with PCMU or G.729. The "m=" line for the video stream indicates that Alice is offering Secure RTP with RTCP-based feedback and H.261. Each media stream includes a "crypto" attribute with the SRTP keying material, again with the same value.
Bob receives the SDP session description offer from Alice, accepts it, and then generates an answer to Alice 🌸
v=0
o=- 24351 621815 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=rtcp-fb:* nackBob includes the same "crypto" attribute as before, and the session proceeds without change. Although Bob didn't 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 extensions defined here. Had he not, the answerer would simply have ignored the new attributes received in step 1 and accepted the offer to use normal RTP. In that case, the following answer would have been generated in step 2 instead 🦋
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/AVP 98
a=rtpmap:98 AMR/8000
m=video 55468 RTP/AVP 31
a=rtpmap:31 H261/90000
a=rtcp-fb:* nackFinally, if Bob had chosen session-level MIKEY instead of SDP security descriptions, the following answer would have been generated 🔑
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO...
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=2 a=1
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=rtcp-fb:* nack
a=acfg:1 t=1 a=1,4It should be noted that although Bob could have chosen session-level MIKEY for one media stream and SDP security descriptions for another, there are no well-defined offerer processing rules for the resulting answer. The offerer may therefore incorrectly assume use of MIKEY for both streams. To avoid this, if the answerer chooses session-level MIKEY, then all Secure RTP-based media streams SHOULD use MIKEY. This applies irrespective of whether or not SDP Capability Negotiation is being used. Use of media-level MIKEY does not have a similar constraint. ⚠️
4.4. SRTP with Session-Level MIKEY and Media-Level Security Descriptions as Alternatives
okay so this example is SO good 💖 It shows how the SDP Capability Negotiation framework can negotiate either MIKEY or SDP security descriptions 🔐 when one of them is in the actual configuration and the other is the alternative being picked. Alice is the offerer and wants an audio and video session 🎀 She prefers session-level MIKEY for key management, but she also supports SDP security descriptions 🫶
Here's the offer/answer exchange, with Alice sending the offer to Bob:
Alice Bob
| (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) |
|--------------------------------------->|
| |
| (2) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |Alice's offer has an audio stream and a video stream, and both of them offer Secure RTP ✨
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 a=-s:1
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=pcfg:1 a=-s:2Alice doesn't know whether Bob supports MIKEY or SDP security descriptions 🤔 She could include attributes for both, but the resulting procedures and potential interactions aren't well-defined, and that's a whole mess 🙈 So instead, she puts a session-level key-mgmt attribute for MIKEY in the actual configuration, and SDP security descriptions go in as the alternative in the potential configuration 💅 The potential configuration for the audio stream says that all session-level attributes get deleted (so the session-level a=key-mgmt attribute goes away) and that mandatory attribute capability 2 is used (the crypto attribute). The video stream's potential configuration is pretty similar, except it uses its own mandatory crypto attribute capability (2). Notice how deleting the session-level attributes doesn't touch the media-level attributes at all 🦋
Bob gets the offer from Alice. He supports Secure RTP, the SDP Capability Negotiation framework, and both SDP security descriptions and MIKEY 👑 Since the potential configuration is more preferred than the actual configuration, Bob (conceptually) builds an internal potential configuration SDP session description. It has the crypto attributes for audio and video, but not the key-mgmt attribute for MIKEY, so there's zero ambiguity between the two keying mechanisms 🧚 So his answer looks like this:
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 a=-s:1
m=video 55468 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=acfg:1 a=-s:2For the audio stream, Bob accepts Secure RTP using SDP security descriptions 🎶 So he includes a crypto attribute with his own keying material, plus an acfg attribute that points to actual configuration 1 from the offer for the audio stream. That acfg has the delete-attributes (-s) and attribute capability 1 (the crypto attribute from the offer). For the video stream, Bob also accepts Secure RTP with SDP security descriptions 🌸 He includes a crypto attribute with his own keying material, and an acfg attribute pointing to actual configuration 1 for the video stream, with the delete-attributes (-s) and attribute capability 2.
Now here's the flip 🙃 Below is the offer SDP session description when Bob instead offers the crypto attribute as the actual configuration keying mechanism, with key-mgmt as the potential configuration:
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=acap:2 rtpmap:98 AMR/8000
a=pcfg:1 a=-m:1,2
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 rtpmap:31 H261/90000
a=pcfg:1 a=-m:1,4Note how this time we need to do the delete-attributes at the media level instead of the session level 😭 When we do that, every attribute from the actual configuration SDP session description gets removed, including the rtpmaps. So we have to include those rtpmaps as capabilities too, then add them back in the potential configuration. That effectively recreates the original rtpmap attributes in the resulting potential configuration SDP session description 🫶✨
5. Security Considerations 🔐✨
okay so bestie, this section is the serious one 😭 The SDP Capability Negotiation framework lives inside the offer/answer model, which means all the offer/answer security considerations apply here too [RFC3264]. SIP uses SDP and the offer/answer model as well, so when it's used that way, the SIP security considerations come along for the ride [RFC3261].
BUT, and this is a big but 💅, SDP Capability Negotiation adds its own security issues. Using it to negotiate alternative transport protocols (secure and non-secure) is one, and so is its ability to negotiate more or less secure keying methods and material. Both deserve extra attention. Then there's the (continued) support for receiving media before the answer, combined with negotiating alternative transport protocols (secure and non-secure). That combo is also a whole thing 🫣 We'll go through these below.
The framework lets an offered media stream indicate and support several levels of security. For example, different levels can be negotiated through alternative attribute capabilities, each indicating more or less secure keying methods and more or less strong ciphers. Since the offerer indicates support for each of these alternatives, they will presumably accept the answerer picking any of the offered alternatives. So if an attacker can modify the SDP session description offer, they can force the negotiation of the weakest security mechanism the offerer is willing to accept 💀 That could let the attacker compromise the security of the negotiated media stream.
It gets worse with transports. Say the offerer wants a secure media stream (like Secure RTP) but also includes a non-secure media stream (like plain RTP) as a valid but less preferred option. An attacker who can modify the offered SDP session description can force the establishment of an insecure media stream. Both of these problems are solved by integrity protection over the SDP session description. Ideally that integrity protection is end-to-end, so it guards against any man-in-the-middle attack. Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751] is one such solution, but S/MIME needs a Public Key Infrastructure (PKI) to be used and available 🥺
When using SIP, a slightly less secure option that's generally way easier to deploy is SIP Identity [RFC4474]. It needs an authentication service to exist (see [RFC4474]). It still relies on a PKI, but only servers (not end-users) need third-party validatable certificates, which makes it a lot easier for ordinary users to get in on it 🙌
Then there's an even less secure option: hop-by-hop security only, like TLS or IPsec. This ensures the integrity of the offered SDP session description on a hop-by-hop basis. It's weaker because SIP allows partially trusted intermediaries on the signaling path, and those intermediaries, processing the SIP request at each hop, could perform a man-in-the-middle attack by modifying the offered SDP session description 😬 In simple architectures where the two UA's proxies talk directly to each other, the security this method gives is roughly comparable to the signature-based mechanisms we just talked about ✨
Per the normal offer/answer procedures, once the offerer has generated an offer, they must be ready to receive media that matches that offer. SDP Capability Negotiation keeps that behaviour for the actual configuration in the offer. The catch is that the offerer has no way of knowing which configuration (actual or potential) the answerer picked until an answer indication arrives. That opens up a brand new security issue: an attacker may be able to slide media toward the offerer until the answer comes back 👀
Here's an example. The offerer might use plain RTP as the actual configuration and Secure RTP as a potential alternative. Even if the answerer selects Secure RTP, the offerer won't know that until the answer shows up. So in the meantime, an attacker can send media to the offerer.
The easiest protection is to not offer the non-secure media stream in the actual configuration. But that can have its own undesirable side effects. If the answerer doesn't support the secure media stream and also doesn't support the capability negotiation framework, negotiation of the media stream will fail 😭
Another option is SDP security preconditions [RFC5027]. These make sure media doesn't flow until session negotiation has completed, so the selected configuration is known. The catch is that preconditions require both sides to support them. If they don't, and their use is required, the session will fail.
As a (limited) workaround, it is RECOMMENDED that SIP entities generate an answer SDP session description and send it to the offerer as soon as possible, for example in a 183 Session Progress message. This limits the time an attacker has to send media to the offerer. Section 3.9 presents other alternatives as well 🌸
The answer SDP session description has security considerations too. The actual configuration attribute tells the offerer which potential configuration the answer was based on. So an attacker who can either modify or remove the actual configuration attribute in the answer can cause session failure, and can also extend the time window during which the offerer will accept incoming media that doesn't match the actual answer 🚨 The fixes for this SDP session description answer integrity problem are the same as for the offer: end-to-end integrity protection, SIP identity, or hop-by-hop protection. Which one you use depends on the mechanisms the offerer supports and on the security trade-offs they're willing to accept.
As described in Sections 3.1 and 3.11, SDP Capability Negotiation conceptually lets an offerer include many different offers in a single SDP session description 🎀 That's great for flexibility, but it means the answerer may have to process a large number of alternative potential offers, which can eat up significant memory and CPU resources. An attacker can use this amplification to launch a denial-of-service attack against the answerer. The answerer must protect itself from such attacks. As explained in Section 3.11, the answerer can reduce the effects of such an attack by first discarding all potential configurations that contain unsupported transport protocols, unsupported or invalid mandatory attribute capabilities, or unsupported mandatory extension configurations. The answerer should also look out for potential configurations that are designed to pass that test, yet still produce a large number of potential configuration SDP session descriptions that can't be supported 🧐
One way an attacker could try to do this is by finding a valid session-level attribute that causes conflicts or otherwise interferes with individual media description configurations. At the time this document was published, we don't know of such an SDP attribute. But that doesn't mean it doesn't exist, or that it won't exist in the future 🔮 If such attributes are found, implementers should explicitly protect against them.
A significant number of valid and supported potential configurations may remain. However, since all of those contain only valid and supported transport protocols and attributes, it's expected that only a few of them will need to be processed on average. Still, the answerer must ensure that it does not needlessly consume large amounts of memory or CPU resources when processing those, and must be prepared to handle the case where a large number of potential configurations still need to be processed 💜
6. IANA Considerations 📋🦋
6.1. New SDP Attributes
The IANA has registered the following new SDP attributes. Here they all are, as registered:
Attribute name: csup
Long form name: Supported capability negotiation extensions
Type of attribute: Session-level and media-level
Subject to charset: No
Purpose: Option tags for supported SDP Capability
Negotiation extensions
Appropriate values: See Section 3.3.1 of RFC 5939
Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: creq
Long form name: Required capability negotiation extensions
Type of attribute: Session-level and media-level
Subject to charset: No
Purpose: Option tags for required SDP Capability
Negotiation extensions
Appropriate values: See Section 3.3.2 of RFC 5939
Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: acap
Long form name: Attribute capability
Type of attribute: Session-level and media-level
Subject to charset: No
Purpose: Attribute capability containing an attribute
name and associated value
Appropriate values: See Section 3.4.1 of RFC 5939
Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: tcap
Long form name: Transport Protocol Capability
Type of attribute: Session-level and media-level
Subject to charset: No
Purpose: Transport protocol capability listing one or
more transport protocols
Appropriate values: See Section 3.4.2 of RFC 5939
Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: pcfg
Long form name: Potential Configuration
Type of attribute: Media-level
Subject to charset: No
Purpose: Potential configuration for SDP Capability
Negotiation
Appropriate values: See Section 3.5.1 of RFC 5939
Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: acfg
Long form name: Actual configuration
Type of attribute: Media-level
Subject to charset: No
Purpose: Actual configuration for SDP Capability
Negotiation
Appropriate values: See Section 3.5.2 of RFC 5939
Contact name: Flemming Andreasen, fandreas@cisco.com6.2. New SDP Capability Negotiation Option Tag Registry ✨
Okay bestie, IANA made a brand new registry just for SDP Capability Negotiation option tags 🎀. Every registration MUST be documented in an RFC that follows the [RFC5226] IETF Review policy. That RFC MUST give the name of the option tag, a syntax, and a semantic specification for any new SDP attributes and any extensions to the potential configuration ("a=pcfg") and actual configuration ("a=acfg") attributes provided in this document. If the extension defines new SDP attributes meant to be capabilities for the capability negotiation framework (e.g., similar to "a=acap"), those capabilities MUST adhere to the guidelines in Section 3.4.3. Extensions to the potential and actual configuration attributes MUST adhere to the syntax in Sections 3.5.1 and 3.5.2 💅
The option tag "cap-v0" is defined in this document, and IANA has already registered it 🌸
6.3. New SDP Capability Negotiation Potential Configuration Parameter Registry 🧚
IANA also made a new registry for SDP Capability Negotiation Potential Configuration Parameters, and it's giving organized 💜 Each registration MUST be documented in an RFC following the [RFC5226] IETF Review policy. That RFC MUST define the syntax and semantics of each new potential configuration parameter. The syntax MUST adhere to the syntax provided for extensions in Section 3.5.1, and the semantics MUST adhere to the semantics provided for extensions in Sections 3.5.1 and 3.5.2. Associated with each registration MUST be the encoding name for the parameter, plus a short descriptive name for it 🍓
The potential configuration parameters "a" for "attribute" and "t" for "transport protocol" are defined in this document, and IANA has registered them ✨
7. Acknowledgments 🫶
The SDP Capability Negotiation solution in this document draws on the overall capability negotiation framework defined by [SDPng]. It's also heavily influenced by the discussions and work done by the SDP Capability Negotiation Design Team, so big thanks to them 💖 The following people gave really useful comments and suggestions, either on the document itself or on the overall direction of the solution: Francois Audet, John Elwell, Roni Even, Miguel Garcia, Robert Gilman, Cullen Jennings, Jonathan Lennox, Matt Lepinski, Jean-Francois Mule, Joerg Ott, Colin Perkins, Jonathan Rosenberg, Thomas Stach, and Dan Wing 🦋
General Area review comments came from Christian Vogt, and Stephen Kent provided Security Directorate review comments. Eric Rescorla gave textual input to the Security Considerations 🔥 Alexey Melnikov, Robert Sparks, and Magnus Westerlund also left several review comments 👑
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.8.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006.
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol (SDP) Media Streams", RFC
5027, October 2007.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[BESRTP] Kaplan, H. and F. Audet, "Session Description Protocol
(SDP) Offer/Answer Negotiation For Best-Effort Secure
Real-Time Transport Protocol", Work in Progress, October
2006.
[ICETCP] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity
Establishment (ICE)", Work in Progress, September 2010.
[SDPMedCap]
Gilman, R., Even, R., and F. Andreasen, "SDP media
capabilities Negotiation", Work in Progress, July 2010.
[SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session
Description and Capability Negotiation", Work in Progress,
February 2005.Author's Address 🦋
Flemming Andreasen
Cisco Systems
Iselin, NJ 08830
USA
EMail: fandreas@cisco.com📦 where this page comes from
- ietf: rfc5939 2010-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms