RFC 7006
Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)
Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) 💖
Okay bestie, this is RFC 7006 🎀, an IETF spec from September 2013. It's on the Standards Track 👑 and the authors are M. Garcia-Martin (Ericsson), S. Veikkolainen (Nokia), and R. Gilman, whose affiliation isn't listed. The ISSN is 2070-1721 ✨ There's no Obsoletes or Updates line in the header, so it doesn't replace or change any other RFC 🦋
Abstract
SDP already has a capability negotiation framework that lets endpoints agree on transport protocols and attributes 🧚 That framework then got a media capabilities negotiation mechanism, so endpoints can also negotiate extra media-related capabilities. All of this runs inside the super popular SDP offer/answer procedures 💅
This memo adds three more SDP capabilities you can negotiate 🔥 Specifically, it gives you a way to negotiate bandwidth ("b=" line), connection data ("c=" line), and session or media titles ("i=" line for each session or media) 💜
Status of This Memo
This is an Internet Standards Track document 👑
It's a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). You can find more about Internet Standards in Section 2 of RFC 5741 📚
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7006 🔗
Copyright Notice
Copyright (c) 2013 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) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document 🙈 Code Components extracted from 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 ⭐
Table of Contents 🍓
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Protocol Description ............................................4
3.1. Extensions to SDP ..........................................4
3.1.1. Bandwidth Capability ................................6
3.1.2. Connection Data Capability ..........................8
3.1.3. Title Capability ...................................12
3.2. Session Level versus Media Level ..........................16
3.3. Offer/Answer Model Extensions .............................17
3.3.1. Generating the Initial Offer .......................17
3.3.2. Generating the Answer ..............................17
3.3.3. Offerer Processing of the Answer ...................18
3.3.4. Modifying the Session ..............................18
4. Field Replacement Rules ........................................18
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
6.1. New SDP Attributes ........................................19
6.2. New Option Tags ...........................................20
6.3. New SDP Capability Negotiation Configuration Parameters ...20
7. Acknowledgments ................................................20
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................211. Introduction ✨
SDP [RFC4566] is for describing multimedia sessions, like session announcements, session invitations, and other ways of starting a multimedia session 🎬 SDP got extended with the SDP Capability Negotiation Mechanism Framework [RFC5939], which lets endpoints negotiate capabilities like support for the Real-time Transport Protocol (RTP) [RFC3550] and the Secure Real-time Transport Protocol (SRTP) [RFC3711]. The SDP Media Capabilities Negotiation [RFC6871] also gives you negotiation for media lines 💅
Capability negotiation is built into the widely used SDP offer/answer procedure [RFC3264] 🧚 This memo gives you more things to negotiate beyond what [RFC5939] and [RFC6871] cover. The big three are bandwidth ("b="), connection data ("c="), and session or media titles ("i=") 🔥
These three added capabilities are independent of each other, so implementations won't necessarily support all three at once 🦋 Instead, applications will pick the capability they need for their own purpose 🌸 That's why each capability's normative part lives in its own self-contained section: Section 3.1.1 covers the bandwidth capability extension, Section 3.1.2 covers the connection data capability extension, and Section 3.1.3 covers the title capability extension. Each one gets its own SDP Capability Negotiation option tags, so endpoints can indicate and/or require support for these extensions following the procedures in SDP Capability Negotiation [RFC5939] 💖
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 read as described in BCP 14, RFC 2119 [RFC2119], and they tell you the requirement levels for compliant implementations 🎀
3. Protocol Description 🧁
3.1. Extensions to SDP 🌸
The SDP Capability Negotiation Framework [RFC5939] and the SDP Media Capabilities Negotiation [RFC6871] both specify attributes for negotiating SDP capabilities 🫧 They define new attributes (like "acap", "tcap", "rmcap", and "omcap") to do that. In this document we add three new capability attributes for SDP lines of the general form:
type=valueThe types are "b", "c", and "i" ✨ Their capability attributes are:
"bcap": bandwidth capability"ccap": connection data capability"icap": title capability
From the sub-rules of the attribute ("a=") line in SDP [RFC4566], SDP attributes look like this:
attribute = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-stringCapability attributes only use the "att-field:att-value" form 💅
The new capabilities can be referenced in potential configurations ("a=pcfg") or in latent configurations ("a=lcfg") as productions that match the <extension-config-list>, which RFC 5939 [RFC5939] and RFC 6871 [RFC6871] define:
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
; ALPHA and DIGIT defined in RFC 5234
ext-cap-list = 1*VCHAR ; VCHAR defined in RFC 5234The optional "+" marks the extension as mandatory. An extension marked that way MUST be supported in order to use that particular configuration 🚨
The new capabilities can also be referenced in actual configurations ("a=acfg") as productions that match the <sel-extension-config> defined in RFC 5939 [RFC5939]:
sel-extension-config = ext-cap-name "=" 1*VCHAREach capability's specific parameters are defined in its own description below 🧚
The "bcap", "ccap", and "icap" capability attributes can be provided at the SDP session level and/or the media level. Per the SDP Capability Negotiation [RFC5939], each extension capability has to spell out what it means to make it part of a configuration at the media level 👑
Per SDP [RFC4566], "b=", "c=", and "i=" lines can show up at either session or media level 🌈 So the "bcap", "ccap", and "icap" capability attributes, when declared at session level, get interpreted as if that attribute was given that value at session level. When they're declared at media level, they get interpreted as if that capability attribute was declared at media level 🦋
For example, here's the [RFC6871] example extended with "icap" and "bcap" capability attributes:
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=bcap:1 CT:200
a=icap:1 Video conference
m=audio 54320 RTP/AVP 0
a=rmcap:1 L16/8000/1
a=rmcap:2 L16/16000/2
a=pcfg:1 m=1|2 pt=1:99,2:98
m=video 66544 RTP/AVP 100
a=rmcap:3 H263-1998/90000
a=rtpmap:100 H264/90000
a=pcfg:10 m=3 pt=3:101 b=1 i=1
Figure 1: Example SDP offer with bcap and icap
efined at session levelHere's the vibe 🎀 The SDP above defines one PCMU audio stream and one H.264 video stream. It also defines two RTP-based media capabilities ("rmcap" numbered 1 and 2) for 16-bit linear (L16) audio at 8 kbps and 16 kbps, plus an RTP-based media capability for H.263 video ("rmcap" numbered 3). All the RTP-based media capabilities show up at media level 🎧 The example also has one bandwidth capability ("bcap") and one title capability ("icap"), both defined at session level 🍓 According to the definition above, when the capabilities in the "bcap" and "icap" attributes get referenced from the potential configuration, the resulting SDP treats them as session-level attributes. The RTP-based media capabilities still get treated as media-level attributes 💖
3.1.1. Bandwidth Capability ✨
okay so first up, the bandwidth field 💅 According to [RFC4566], the b= line says how much bandwidth the session or media is proposing to use 🦋 In this memo, we're adding a bandwidth capability attribute that can show up at the SDP session level and/or media level too. The b= field is specified in [RFC4566] like this:
b=<bwtype>:<bandwidth>where <bwtype> is an alphanumeric modifier that tells you what the <bandwidth> figure means 🌸
Here's the new thing we're defining: the bandwidth capability attribute, bcap 🎀 It lists bandwidth as capabilities and is written like this:
"a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLFwhere <bw-cap-num> is a unique integer across all the bandwidth capabilities in the entire SDP. It's how each bandwidth capability gets its number, and it can be anything from 1 to 2^31-1 (both included) ✨ The other elements work the same as the b= field in SDP [RFC4566], so nothing new to learn there, bestie 🫶
This format fits the general attribute production rules in SDP [RFC4566]. Here's the Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
att-field =/ "bcap"
att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Figure 2: Syntax of the "bcap" attributeNegotiating bandwidth per media stream can be super useful when you're negotiating media encoding capabilities that come in different bandwidths 🔥
3.1.1.1. Configuration Parameters
okay this part is giving layers 🧁 The SDP Capability Negotiation Framework [RFC5939] already gives us the pcfg and acfg attributes. Then SDP Media Capabilities Negotiation [RFC6871] extends the concept with an lcfg attribute, which carries latent configurations 🌈
Extensions to pcfg and lcfg are defined through <extension-config-list>, and extensions to acfg are defined through <sel-extension-config>, same as in [RFC5939] 💜
In this document, we extend <extension-config-list> so it can carry lists of bandwidth capabilities in latent or potential configurations. The ABNF [RFC5234] looks like this:
extension-config-list =/ bandwidth-config-list
bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR bw-cap-list)
; BAR defined in RFC 5939
bw-cap-list = bw-cap-num *("," bw-cap-num)
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Figure 3: Syntax of the bandwidth parameter
in "lcfg" and "pcfg" attributesEach bandwidth capability configuration is a comma-separated list of bandwidth capability attribute numbers. Each <bw-cap-num> points at one of the <bw-cap-num> bandwidth capability numbers we defined earlier in this document, so each one MUST be between 1 and 2^31-1 (both included) 🎀 Alternative bandwidth configurations are split up with a vertical bar (|) 🦋
The syntax is super flexible. It lets a single configuration reference multiple b= lines, even ones with the same <bwtype>. We don't see a real need for that, but we didn't restrict it, since SDP [RFC4566] doesn't restrict it either 🤷♀️
The bandwidth parameter in the actual configuration attribute (a=acfg) is formed as a <sel-extension-config> with:
ext-cap-name = "b"so:
sel-extension-config =/ sel-bandwidth-config
sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above.
Figure 4: Syntax of the bandwidth parameter in "acfg" attributes3.1.1.2. Option Tag
the SDP Capability Negotiation Framework [RFC5939] lets people define capability negotiation extensions 🧚 Each extension gets an option tag that identifies it. We're defining a new option tag, bcap-v0, that identifies support for the bandwidth capability 💖
Endpoints using the bcap capability attribute SHOULD add that option tag to any other option tags already in the csup and creq attributes in SDP. They do this following the procedures in the SDP Capability Negotiation Framework [RFC5939] ✨
3.1.2. Connection Data Capability
okay, connection data time 🌸 According to SDP [RFC4566], the connection data field carries the connection data, and it looks like this:
c=<nettype> <addrtype> <connection-address>where <nettype> is the network type, <addrtype> is the address type, and <connection-address> is the connection address, which depends on the address type 🦋
Network types that are already defined include "IN", meaning the Internet network type, and "ATM" (see RFC 3108 [RFC3108]), used for describing Asynchronous Transfer Mode (ATM) bearer connections 🌈 The Circuit-Switched (CS) descriptions in the SDP document [SDP-CS] add a "PSTN" network type for a Public Switched Telephone Network (PSTN) circuit switch 📞
SDP [RFC4566] lets connection data be specified at the session level and/or media level. To allow negotiating connection data at the media level, we define the connection data capability attribute (a=ccap) in this form:
"a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP
connection-address CRLFwhere <conn-cap-num> is a unique integer across all the connection capabilities in the entire SDP. It identifies the connection data capability and can be anything from 1 to 2^31-1 (both included). The other elements are as defined in [RFC4566] 💜
This format matches the [RFC4566] attribute production rules. Here's the ABNF [RFC5234] syntax:
att-field =/ "ccap"
att-value =/ conn-cap-num 1*WSP nettype SP addrtype
SP connection-address
conn-cap-num = 1*10(DIGIT) ; 1 to 2^31-1, inclusive
; DIGIT defined in RFC 5234
Figure 5: Syntax of the "ccap" attributeThe ccap capability attribute lets you express alternative connection address (c=) lines in SDP as part of the SDP Capability Negotiation process 🎀 One of the main use cases is offering alternative connection addresses where <nettype> is "IN" or "PSTN". Basically, you're picking between an IP-based bearer or a circuit-switched bearer 🔥
Since ccap supports the "IN" <nettype>, it can signal multiple IPv4 and IPv6 addresses. Heads up though: the Standards Track mechanism for negotiating alternative IP addresses in SDP is Interactive Connectivity Establishment (ICE) [RFC5245]. The ccap attribute doesn't change that. So the combined set of actual and potential configurations (as defined in [RFC5939]) for any given media description MUST NOT use ccap to negotiate more than one address with an IN network type. That means you can't select between "IPv4" and "IPv6" address families, or between different IP addresses in the same IP address family (i.e., it is not permissible to select between "IPv4" and "IPv6" address families or different IP addresses within the same IP address family. 😭
Figure 6 is an example SDP offer that includes a ccap capability attribute. An audio stream can be set up with an RTP flow, or by establishing a circuit-switched audio stream 🧚
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
a=creq:med-v0,ccap-v0
m=audio 38902 RTP/AVP 0 8
c=IN IP4 198.51.100.7
a=ccap:1 PSTN E164 +15555556666
a=tcap:2 PSTN
a=omcap:1 -
a=acap:1 setup:actpass
a=acap:2 connection:new
a=acap:3 cs-correlation:callerid:+15555556666
a=pcfg:1 c=1 t=2 m=1 a=1,2,3
Figure 6: Example SDP offer with a "ccap" attributeThe example in Figure 6 is an SDP offer for an audio flow using RTP, like the one in Figure 7, or an audio flow using a circuit-switched connection, like the one in Figure 8 🌸
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
m=audio 38902 RTP/AVP 0 8
c=IN IP4 198.51.100.7
Figure 7: Equivalent SDP offer with the RTP flow
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +15555556666
a=setup:actpass
a=connection:new
a=cs-correlation:callerid:+15555556666
Figure 8: Equivalent SDP offer with the circuit-switched flowThis document doesn't define any way to negotiate or describe different port numbers. So the port number from the m= line MUST be used by default 🦋 Exceptions to that default can come from extension mechanisms or network type specific rules. This document defines one exception: when the network type is "PSTN", the port number is replaced with 9 (the "discard" port). That's described in "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)" [SDP-CS] 💜
An endpoint offering alternative IP and PSTN bearers MUST include the IP media description in the actual configuration (IP address in the c= line and port number in the m= line), and the PSTN media description in the potential configuration 🫶
Exceptions for other network types, like the "ATM" network type defined in [RFC3108], need additional specifications 🌈
3.1.2.1. Configuration Parameters 🎀
Okay so the SDP Capability Negotiation Framework [RFC5939] already gives us the "pcfg" and "acfg" attributes 💅, which can carry one or more configurations to negotiate. Then SDP Media Capabilities Negotiation [RFC6871] comes along and adds an "lcfg" attribute for latent configurations 🦋.
So here we define a <connection-config> parameter, which is how you describe a connection data capability inside a potential or latent configuration attribute. It follows the form of an <extension-config-list> with ext-cap-name = "c" and ext-cap-list = conn-cap-list, and the grammar goes like this (ABNF [RFC5234] syntax, bestie 🤓):
extension-config-list =/ conn-config-list
conn-config-list = ["+"] "c=" conn-cap-list
conn-cap-list = conn-cap-num *(BAR conn-cap-num)
conn-cap-num = 1*10(DIGIT) ; 1 to 2^32-1 inclusiveFigure 9: Syntax of the connection data parameter in "lcfg" and "pcfg" attributes
Every alternative carries exactly one connection data capability number, and that number points back at a conn-cap-num capability defined earlier in this document. So the values MUST be between 1 and 2^31-1 (both included) ✨. The connection data capability only lets you express one capability per alternative instead of a whole list, because a media block can only have one connection data field anyway 🙈. You can still offer several different connection setups, though, just separate them with a vertical bar (|).
An endpoint adds a plus sign (+) to the configuration attribute when it wants to mandate support for this extension. If an endpoint gets a parameter with that plus sign and it doesn't support this extension, it MUST treat that potential configuration as not valid 🚫. Rude, but fair.
The connection data parameter in the actual configuration attribute (a=acfg) is written as a <sel-extension-config>, again with ext-cap-name = "c":
sel-extension-config =/ sel-connection-config
sel-connection-config = "c=" conn-cap-num ; as defined above.Figure 10: Syntax of the connection data parameter in "acfg" attributes
3.1.2.2. Option Tag 🏷️
The SDP Capability Negotiation Framework [RFC5939] lets people define their own capability negotiation extensions, and each one gets an option tag so everyone can tell them apart 💖. So here we define a brand new option tag, ccap-v0, which says "hey, I support the connection data capability" 🍓. This option tag SHOULD be added alongside whatever option tags you already have in your "csup" and "creq" attributes in SDP, following the procedures in the SDP Capability Negotiation Framework [RFC5939].
3.1.3. Title Capability 🌸
Okay, so SDP [RFC4566] has this info field written as an "i=" line, and it can show up at the session level and/or the media level 📻. At session level it's called the "session name", and it's basically a human-readable description of the whole session ✨.
At media level, the "i=" line tells people what that particular stream is for. For example, it might say what the stream is about 🎬. Here's the tea ☕: the "i=" line is not the same thing as the label attribute ("a=label:", [RFC4574]). The label is a machine-readable tag, and the "i=" line is for humans 🤖❌.
Now why does this matter? Apps often want to offer different versions of the same stream. Like, an audio stream could come in English or Spanish 🇬🇧🇪🇸, or a video stream could offer a choice of sources, like a speaker camera, a group camera, or a document viewer 📷. The title capability helps the answering user pick the right option, and the label is how the offering machine finds out which option got picked 🫶. So it makes sense to have a way to provide stream titles as capabilities.
Quick charset situation 🔤: the session information field ("i=", called "title" in this document) follows the "a=charset" attribute from SDP [RFC4566], so internationalization works. The title capability attribute itself ("a=icap") does not follow "a=charset", because then you couldn't include alternative titles that each use a different character set 😤. Instead, the title text inside an "a=icap" attribute follows whatever "a=charset" value is used in the configuration that includes that title capability. That keeps SDP running smoothly while still letting each configuration have its own title in its own encoding 🌈.
According to SDP [RFC4566], the session information ("i=") line looks like this:
"i=" textHere "text" is human-readable text describing the purpose of the session or media stream 📝.
In this document we create a new capability attribute, the title capability "icap" 🎉. It lists session or media titles as capabilities, and it's written like this:
"a=icap:" title-cap-num 1*WSP textHere title-cap-num is an integer that's unique across all the connection capabilities in the entire SDP. It's how you identify that specific title capability, and it can be anywhere from 1 to 2^31-1 (both included) 🔢. The text is the human-readable bit saying what the stream is supposed to be 💅.
Example time 🎀:
a=icap:1 Document CameraThat defines title capability number 1, which identifies one particular source of a media stream.
Or you can offer two title capabilities that use different encodings, using the "charset" attribute from SDP [RFC4566] and the generic capability attribute ("a=acap:") from the SDP Capability Negotiation Framework [RFC5939] 🤩:
a=icap:1 [Text encoded in ISO-8859-1]
a=acap:1 charset:ISO-8859-1
a=icap:2 [Text encoded in UTF-8]
a=acap:2 charset:UTF-8NOTE: Due to limitations of the ASCII encoding of RFCs, the actual text with non-printable characters cannot be represented in the text. See the PDF format of this RFC for a figure with non-printable characters. 🙃
The title capability attribute fits into the general attribute production rules in SDP [RFC4566] with this ABNF [RFC5234] syntax:
att-field =/ "icap"
att-value =/ title-cap-num 1*WSP text
; text defined in RFC 4566
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234Figure 11: Syntax of the "icap" attribute
3.1.3.1. Configuration Parameters 🧚
Same deal as before: the SDP Capability Negotiation Framework [RFC5939] gives us the "pcfg" and "acfg" attributes ✨. Then the SDP Media Capabilities Negotiation [RFC6871] extends that with an "lcfg" attribute for latent configurations 🌙.
In this document we define a <title-config-list> parameter for passing around title capabilities in a potential or latent configuration. It's defined as an <extension-config-list> with these associations:
ext-cap-name = "i"
ext-cap-list = title-cap-listWhich gives us this definition for the title capability parameter 💕:
extension-config-list =/ title-config-list
title-config-list = ["+"] "i=" title-cap-list
title-cap-list = title-cap-num *(BAR title-cap-num)
; BAR defined in RFC 5939
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234Figure 12: Syntax of the title capability parameter in "lcfg" and "pcfg" attributes
Each potential capability configuration holds a single title capability attribute number, where "title-cap-num" is the title capability number defined earlier in this document. So it must be between 1 and 2^31-1 (both included) 🔒. Like connection data, the title capability only lets you express one capability per alternative, since a block can only have one title field. You can still offer alternative title configurations, separated by a vertical bar (|) 🦋.
Endpoints add a plus sign (+) to the configuration attribute to mandate support for this extension. If an endpoint receives this parameter with the plus sign and doesn't support the extension, it MUST treat that potential configuration as not valid 🙅♀️.
The title parameter in the actual configuration attribute (a=acfg) is written as a <sel-extension-config> with ext-cap-name = "i":
sel-extension-config =/ sel-title-config
sel-title-config = "i=" title-cap-num ; as defined above.Figure 13: Syntax of the title parameter in "acfg" attributes
3.1.3.2. Option Tag 🏷️
Honest moment 🫠: right now it's kind of hard to picture a case where the "icap" attribute has to be supported or the offer has to get rejected. Usually, if someone ignored the icap attribute or its contents, they could still pick a configuration based on other stuff, like configuration numbering 🔢.
But imagine an SDP offer with English and Spanish potential configurations for an audio stream 🇬🇧🇪🇸. If the choice is made by configuration numbering instead of an informed user pick, the session could be totally unintelligible 😭. So it may well be useful to announce that you can use the icap attribute and its contents to select media configurations, or to tell the user which configuration(s) got selected 💜.
That's why we define a new option tag, "icap-v0", which says "I support the title capability" 🎀. This option tag SHOULD be added to other option tags already present in the "csup" and/or "creq" attributes in SDP, following the procedures in the SDP Capability Negotiation Framework [RFC5939]. Based on all that, "icap-v0" will probably show up mostly in a "csup" attribute, and only rarely in a "creq" attribute 🌈.
3.2. Session Level versus Media Level 🎀
okay so the bcap, ccap, and icap attributes can show up at the SDP session level, the media level, or both 💅. Endpoints MUST read capabilities declared at session level as part of the session level in the resulting SDP for that particular configuration. Endpoints MUST read capabilities declared at a media description as part of the media level in the resulting SDP for that particular configuration ✨.
bestie, having bcap for the same <bwtype> at both session and media level is totally allowed, but it has to follow the same constraints and restrictions that [RFC4566] puts on the bandwidth attribute b= 🧚.
to avoid chaos 🙈, the <type-attr-num> for each a=bcap, a=ccap, and a=icap line MUST be unique across all capability attributes of the same type within the entire session description. no duplicates, no drama 💖.
3.3. Offer/Answer Model Extensions 🦋
in this section we add extensions to the offer/answer model from [RFC3264], which got extended again in [RFC5939], so that bandwidth, connection, and title capabilities can be used with the SDP Capability Negotiation Framework 🌈.
3.3.1. Generating the Initial Offer 🍓
so when an endpoint makes an initial offer and wants this functionality, it first picks values for the bandwidth, connection data, and/or title capability attributes, following the rules in [RFC4566] for the b=, c=, and i= lines 📝. Then it MUST include those capability attributes and their values in the SDP offer 💅. The preferred configurations for each media stream get listed after the media line in a pcfg attribute ✨. Bandwidth and title capabilities can also show up in latent configurations in an lcfg attribute, as defined in [RFC6871] 🫶.
implementations are advised to keep an eye on the port number used in the m= line 👀. By default, a potential configuration that includes a connection data capability will use the port number from the m= line, unless the network type is PSTN. In that case the default port number is 9 🔥.
the offer SHOULD include the level of capability negotiation extensions needed to support this functionality in a creq attribute 💜.
3.3.2. Generating the Answer 🌸
when the answering party gets the offer, and it supports the required capability negotiation extensions, it SHOULD pick the most preferred configuration it can support for each media stream and build the answer from there, as defined in Section 3.6.2 of [RFC5939] 🦋.
if the connection data capability is used in a potential configuration the answerer picked, that offer configuration MUST by default use the port number from the actual offer configuration (the m= line) 🎀. The only exception is when the network type is PSTN, and then the default port MUST be assumed to be 9 ⭐. Extensions may be defined to negotiate the port number explicitly instead 🧚♀️.
3.3.3. Offerer Processing of the Answer 👑
when the offerer receives the answer, it MUST process the media lines according to normal SDP processing rules to figure out which media streams the answer accepted, if any, as defined in Section 3.6.3 of [RFC5939] 💅. If an acfg attribute is present, it MUST be used to verify the proposed configuration that formed the answer, and to infer that higher-preference configurations which weren't chosen are not acceptable 😭.
3.3.4. Modifying the Session 💖
if one of the parties later wants to change the operating parameters of a session, like adding a new media stream or changing properties on an existing stream, it can do that using the mechanisms defined for SDP offer/answer in [RFC3264] 🌈. It has to follow the procedures in Section 3.6.4 of [RFC5939] too 🫶.
4. Field Replacement Rules ✨
to keep SDP records simple 🍓, since fields inside the media description are still needed by endpoints that don't support capability negotiation, we define some straightforward field-replacement rules for fields invoked by potential or latent configurations 💅. Specifically, any i= or c= lines invoked by a configuration MUST replace the corresponding line, if one is present within the media description in question 🔥. Any b= line invoked by a configuration MUST replace any b= of the same bandwidth type at the media level, but NOT at the session level 💀.
Wait, correction for accuracy: the original says the replacement happens "at the media level, but not at the session level," so the sentence reads that the b= replaces the media-level line only. Keeping it exact:
Any b= line invoked by a configuration MUST replace any b= of the same bandwidth type at the media level, but not at the session level 💀.
5. Security Considerations 🔒
this one is serious, bestie, so pay attention 😤. This document extends SDP [RFC4566], the SDP Offer/Answer Model [RFC3264], the SDP Capability Negotiation Framework [RFC5939], and SDP Media Capabilities Negotiation [RFC6871] 🧚. So the security considerations of all of those documents apply too 🌸.
the bandwidth capability attribute may be used to reserve resources at endpoints and at intermediaries that inspect SDP 💜. If an attacker modifies the bandwidth value, the network can end up underutilized (bandwidth value too high) or congested (bandwidth value too low) 😭🔥.
similarly, if an attacker changes the alternative connection address(es), they could direct media streams to a desired endpoint 😱. That would be a version of the well-known voice hammer attack (see Section 18.5.1 of [RFC5245]) 💀.
the title capability gives alternative i= line information, and that's meant for humans to read 📖. But messing with the text could be used to give false information, leading to a bad user experience, or to the person using the service making a wrong choice about the available media streams 🙈.
if it's essential to protect the capability attribute values, one of the security mechanisms proposed in [RFC5939] SHOULD be used 🔐.
the i= line, and so the value carried in the title capability attribute, is only meant to be a human-readable description 🫶. It should not be parsed programmatically 🚫.
6. IANA Considerations 🌈
6.1. New SDP Attributes ✨
IANA has registered new attributes in the "att-field (both session and media level)" subregistry of the "Session Description Protocol (SDP) Parameters" registry 📋. Here's the registration form, bestie:
Attribute name: bcap
Long form name: Bandwidth Capability
Type of attribute: Both media and session level
Subject to charset: No
Purpose: Negotiate session or media-level bandwidths
Appropriate values: See RFC 7066, Section 3.1.1
Contact name: Miguel A. Garcia
Miguel.A.Garcia@ericsson.com
Attribute name: ccap
Long form name: Connection Data Capability
Type of attribute: Both media and session level
Subject to charset: No
Purpose: Negotiate media-level connection data
Appropriate values: See RFC 7066, Section 3.1.2
Contact name: Miguel A. Garcia
Miguel.A.Garcia@ericsson.com
Attribute name: icap
Long form name: Title Capability
Type of attribute: Both media and session level
Subject to charset: Yes
Purpose: Negotiate human-readable information
describing the session or media
Appropriate values: See RFC 7066, Section 3.1.3
Contact name: Miguel A. Garcia
Miguel.A.Garcia@ericsson.com6.2. New Option Tags 🏷️
IANA has added the new option tags "bcap-v0", "ccap-v0", and "icap-v0", defined herein, to the "SDP Capability Negotiation Option Tag" subregistry of the "Session Description Protocol (SDP) Parameters" registry 💜.
6.3. New SDP Capability Negotiation Configuration Parameters 🎀
IANA has added the new parameter identifiers "b" for "Bandwidth", "c" for "Connection Data", and "i" for "Title" to the "SDP Capability Negotiation Configuration Parameters" subregistry of the "Session Description Protocol (SDP) Parameters" registry 🧁. These parameters are permitted in lcfg, acfg, and pcfg attributes ✨.
7. Acknowledgments 🫶
big thank-yous to Christer Holmberg, Alf Heidermark, and Ingemar Johansson for arguing for the existence of this document and reviewing it in the early stages 👏. Thanks also to Flemming Andreasen, Andrew Allen, and Jonathan Lennox for a detailed review and lots of suggestions for improvement 💖.
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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010.
[RFC6871] Gilman, R., Even, R., and F. Andreasen, "Session
Description Protocol (SDP) Media Capabilities
Negotiation", RFC 6871, February 2013.8.2. Informative References 🦋
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer
Connections", RFC 3108, May 2001.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, 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.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[SDP-CS] Garcia, M. and S. Veikkolainen, "Session Description
Protocol (SDP) Extension for Setting Audio and Video Media
Streams over Circuit-Switched Bearers in the Public
Switched Telephone Network (PSTN)", Work in Progress, June
2013.Authors' Addresses 📮
Miguel A. Garcia-Martin
Ericsson
Calle Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 1000
EMail: miguel.a.garcia@ericsson.com
Simo Veikkolainen
Nokia
P.O. Box 226
NOKIA GROUP, FI 00045
Finland
Phone: +358 50 486 4463
EMail: simo.veikkolainen@nokia.com
Robert R. Gilman
3243 W. 11th Ave. Dr.
Broomfield, Colorado 80020
U.S.A.
Phone: +1 303 898 9780
EMail: bob_gilman@comcast.net📦 where this page comes from
- ietf: rfc7006 2013-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms