RFC 5888
The Session Description Protocol (SDP) Grouping Framework
The Session Description Protocol (SDP) Grouping Framework 🎀
okay so this one is RFC 5888 and it's giving main character energy 💅 It's a Standards Track document from the IETF, published June 2010 under ISSN 2070-1721. The authors are G. Camarillo from Ericsson and H. Schulzrinne from Columbia University. It obsoletes RFC 3388, so if you've been reading the old one, this is the newer version that replaces it 📚
Abstract
okay so the big idea here is a framework for grouping "m" lines in the Session Description Protocol (SDP) for different purposes 🦋 The framework runs on two SDP attributes, "group" and "mid", and both of them are defined right here. The doc also explains how to use the framework for two things: lip synchronization, and receiving a media flow made of several media streams that show up on different transport addresses. And again, this document obsoletes RFC 3388 🫶
Status of This Memo
This is an Internet Standards Track document 🔥
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5888.
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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Media Stream Identification Attribute . . . . . . . . . . . . 4
5. Group Attribute . . . . . . . . . . . . . . . . . . . . . . . 4
6. Use of "group" and "mid" . . . . . . . . . . . . . . . . . . . 4
7. Lip Synchronization (LS) . . . . . . . . . . . . . . . . . . . 5
7.1. Example of LS . . . . . . . . . . . . . . . . . . . . . . 5
8. Flow Identification (FID) . . . . . . . . . . . . . . . . . . 6
8.1. SIP and Cellular Access . . . . . . . . . . . . . . . . . 6
8.2. DTMF Tones . . . . . . . . . . . . . . . . . . . . . . . . 7
8.3. Media Flow Definition . . . . . . . . . . . . . . . . . . 7
8.4. FID Semantics . . . . . . . . . . . . . . . . . . . . . . 7
8.4.1. Examples of FID . . . . . . . . . . . . . . . . . . . 8
8.5. Scenarios That FID Does Not Cover . . . . . . . . . . . . 11
8.5.1. Parallel Encoding Using Different Codecs . . . . . . . 11
8.5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . 12
8.5.3. Same IP Address and Port Number . . . . . . . . . . . 12
9. Usage of the "group" Attribute in SIP . . . . . . . . . . . . 13
9.1. Mid Value in Answers . . . . . . . . . . . . . . . . . . . 13
9.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Group Value in Answers . . . . . . . . . . . . . . . . . . 15
9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 15
9.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 16
9.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 16
9.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 17
9.4.1. Offerer Does Not Support "group" . . . . . . . . . . . 17
9.4.2. Answerer Does Not Support "group" . . . . . . . . . . 17
10. Changes from RFC 3388 . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . . 201. Introduction ✨
okay so RFC 3388 [RFC3388] was the first one to specify a media-line grouping framework for SDP [RFC4566], and this specification is the one that obsoletes it [RFC3388] 💖
here's the situation: an SDP [RFC4566] session description usually has one or more media lines, which everyone calls "m" lines. When a session description has more than one "m" line, SDP doesn't give you any way to say how two or more of them are related 🙈 When an application gets an SDP session description with more than one "m" line, it's on the application to figure out what to do with them. SDP just doesn't carry any info about grouping media streams. bestie, that's a whole vibe problem 💀
sometimes this info can travel out of band, but it's really necessary to have a mechanism inside SDP that expresses how the different media streams in a session description relate to each other. And the framework in this specification is exactly that mechanism 🦋
2. Terminology 🌸
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. Overview of Operation 🧚
this section is non-normative, so it's just the big-picture explainer for how the SDP Grouping Framework works 💜 In any session description, every "m" line gets identified by a token, and that token is carried in a "mid" attribute right below the "m" line. The session description then carries session-level "group" attributes, which group different "m" lines (by their tokens) using different group semantics. The semantics describe the purpose the "m" lines are grouped for 🍓
check out this example. The "group" line below says the "m" lines with tokens 1 and 2 (the audio and the video "m" lines) are grouped for lip synchronization (LS), so they get to be besties for that purpose 👯
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:24. Media Stream Identification Attribute 🦋
this document defines the "media stream identification" media attribute, which is what you use to identify media streams inside a session description ✨ Its format in SDP [RFC4566] is written down in the following Augmented Backus-Naur Form (ABNF) [RFC5234]:
mid-attribute = "a=mid:" identification-tag
identification-tag = token
; token is defined in RFC 4566The identification-tag MUST be unique within an SDP session description. no duplicates allowed, periodt 🙅♀️
5. Group Attribute 👑
this document defines the "group" session-level attribute, and its whole job is grouping together different media streams 🫶 Its format in SDP is described by the following ABNF [RFC5234]:
group-attribute = "a=group:" semantics
*(SP identification-tag)
semantics = "LS" / "FID" / semantics-extension
semantics-extension = token
; token is defined in RFC 4566This document defines two standard semantics: Lip Synchronization (LS) and Flow Identification (FID). New semantics extensions follow the Standards Action policy [RFC5226]. 🔥
6. Use of "group" and "mid" 💅
okay this section is the rulebook for how "group" and "mid" have to work together 📚 All of the "m" lines in a session description that uses "group" MUST be identified with a "mid" attribute, whether they show up in a group line or not. Hard rule. And if a session description has even one "m" line with no "mid" identification, the application MUST NOT perform any grouping of media lines at all. no partial grouping, that's not it 🙈
"a=group" lines are used to group together several "m" lines that are identified by their "mid" attribute 🌈 Any "a=group" line that has identification-tags which don't match any "m" line in the session description MUST be ignored. The application acts as if that "a=group" line didn't exist at all. And the behavior of an application that receives an SDP description with grouped "m" lines is defined by the semantics field in the "a=group" line ✨
There MAY be several "a=group" lines in a session description. The "a=group" lines in a session description can use the same semantics or different ones. And an "m" line identified by its "mid" attribute MAY appear in more than one "a=group" line, so it can be in multiple groups at the same time 🧚
7. Lip Synchronization (LS) 🎀
an application that receives a session description with "m" lines grouped together using LS semantics MUST synchronize the playout of the corresponding media streams 😭 And LS semantics don't only apply to a video stream that has to line up with an audio stream. The playout of two streams of the same type can get synced too 👯
for RTP streams, synchronization is usually done with the RTP Control Protocol (RTCP), which gives enough info to map the timestamps from the different streams into a local absolute time value 🦋 But the concept of media stream synchronization MAY also apply to media streams that don't use RTP. If that's the case, the application MUST recover the original timing relationship between the streams using whatever mechanism is available 💖
7.1. Example of LS 🍓
this example is a session description for a conference that's being multicast 🌸 The first media stream (mid:1) has the voice of the speaker, who talks in English. The second media stream (mid:2) is the video component, and the third (mid:3) carries the Spanish translation of what she's saying. The first and second media streams have to be synchronized 🫶
v=0
o=Laura 289083124 289083124 IN IP4 two.example.com
c=IN IP4 233.252.0.1/127
t=0 0
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation
a=mid:3Note that even though the third media stream isn't in the group line, it still has to contain a "mid" attribute (mid:3), as stated before. no exceptions, bestie 🙈
8. Flow Identification (FID) ✨
okay so an "m" line in an SDP session description defines a media stream 💖 but SDP never actually says what a media stream is 🙈 for that you have to go to the Real Time Streaming Protocol (RTSP) spec. The RTSP RFC [RFC2326] says a media stream is "a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. When using RTP, a stream consists of all RTP and RTCP packets created by a source within an RTP session".
this assumes one audio (or video) stream maps into one RTP session, and that's the vibe the RTP RFC [RFC1889] gave off too (it's now obsoleted by [RFC3550]). it defined an RTP session as "For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP)".
the old definitions cover the most common cases, but there are situations where one media instance (like an audio stream or a video stream) gets sent over more than one RTP session 😭 two examples (among many others) are cellular systems using the Session Initiation Protocol (SIP; [RFC3261]) and systems receiving Dual-Tone Multi-Frequency (DTMF) tones on a different host than the voice 🎀
8.1. SIP and Cellular Access
cellular access plus SIP as the signalling protocol means you need to receive media over the air 📡 during a session the media can be encoded with different codecs, and the encoded media has to cross the radio interface. the radio interface is known for bit errors and pretty high packet transfer delays, and radio resources in a cellular environment are scarce (so expensive too 💸), which means you need special measures for a super efficient transport. to get decent speech quality AND efficient transport, you need to know the codec properties really precisely, so a proper radio bearer for the RTP session can be configured before the media shows up. these radio bearers are dedicated per media type (aka per codec) 🦋
cellular systems usually set up different radio bearers on different port numbers. so incoming media needs different destination port numbers for each possible codec, so it gets routed to the right radio bearer 🛣️ which makes this a perfect example of several RTP sessions carrying a single media instance (the encoded speech from the sender) 💅
8.2. DTMF Tones
some voice sessions include DTMF tones ☎️ sometimes the voice gets handled by a different host than the DTMF stuff. it's super common to have an application server in the network gathering DTMF tones for the user while the user gets the encoded speech on their user agent. in this case you need to set up two RTP sessions: one for the voice and one for the DTMF tones 🎶 both RTP sessions are logically part of the same media instance 🫶
8.3. Media Flow Definition
the examples above show that the definition of a media stream in [RFC2326] just doesn't cover some scenarios 🙃 you can't assume one media instance maps to one RTP session. so we introduce the definition of a media flow ✨
A media flow consists of a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. When using RTP, a media flow comprises one or more RTP sessions.
8.4. FID Semantics
okay the vibe here is: several "m" lines grouped together using FID semantics form a media flow 🧚 a media agent handling a media flow with several "m" lines MUST send a copy of the media to every "m" line that is part of the flow, as long as the codecs and the direction attribute in a particular "m" line allow it 🔥
it's assumed the application only uses one codec at a time to encode the media it produces 👑 this codec MAY change dynamically during the session, but at any given moment only one codec is in use 🌈
so the application encodes the media with the current codec and checks, one by one, all the "m" lines in the flow 🔍 if a particular "m" line contains the codec being used AND the direction attribute is "sendonly" or "sendrecv", a copy of the encoded media gets sent to the address/port specified in that media stream 💌 if the "m" line doesn't contain the codec being used, OR the direction attribute is neither "sendonly" nor "sendrecv", then nothing gets sent over that media stream 🙅♀️
the application typically ends up sending media to different destinations (IP address/port number) depending on which codec is being used at any moment 🎀
8.4.1. Examples of FID
the session description below might be sent by a SIP user agent using a cellular access 📱 this user agent supports GSM (Global System for Mobile communications) on port 30000 and AMR (Adaptive Multi-Rate) on port 30002. when the remote party sends GSM, it sends RTP packets to port number 30000. when AMR is the codec chosen, packets go to port 30002. the remote party can switch between both codecs dynamically in the middle of the session 🦋 but in this example only one media stream at a time carries voice, and the other stays "muted" while its codec isn't in use 🤫
v=0
o=Laura 289083124 289083124 IN IP4 three.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2(The linebreak in the fmtp line accommodates RFC formatting restrictions; SDP does not have continuation lines.)
in the previous example, a system receives media on the same IP address but on different port numbers. the next example shows how a system can receive different codecs on different IP addresses 🌸
v=0
o=Laura 289083124 289083124 IN IP4 four.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=rtpmap:0 PCMU/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2(The linebreak in the fmtp line accommodates RFC formatting restrictions; SDP does not have continuation lines.)
in this example the cellular terminal only supports the AMR codec 📵 but a lot of current IP phones only support PCM (Pulse-Code Modulation; payload 0) 😬 so to play nicely with them, the cellular terminal uses a transcoder whose IP address is 192.0.2.2. the cellular terminal puts the transcoder IP address in its SDP description to support PCM. remote systems send AMR directly to the terminal, but PCM goes to the transcoder. the transcoder is configured (using whatever method is preferred) to convert the incoming PCM audio to AMR and send it to the terminal 🔄
the next example shows how the "group" attribute used with FID semantics can indicate two different codecs in the two directions of a bidirectional media stream 🧠
v=0
o=Laura 289083124 289083124 IN IP4 five.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=recvonly
a=mid:2a user agent that receives the SDP above knows that, at a certain moment, it can send either PCM u-law to port number 30000 or PCM A-law to port number 30002 🎀 the media agent also knows the other end will only send PCM u-law (payload 0) 💅
the following example shows a session description with different "m" lines grouped together using FID semantics that contain the same codec 👯♀️
v=0
o=Laura 289083124 289083124 IN IP4 six.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 20000 RTP/AVP 0 8
c=IN IP4 192.0.2.2
a=recvonly
a=mid:3at a particular point in time, if the media agent receiving the SDP above is sending PCM u-law (payload 0), it sends RTP packets to 192.0.2.1 on port 30000 AND to 192.0.2.2 on port 20000 (first and third "m" lines) 💖 if it's sending PCM A-law (payload 8), it sends RTP packets to 192.0.2.1 on port 30002 AND to 192.0.2.2 on port 20000 (second and third "m" lines) ✨
the system that generated the SDP above supports PCM u-law on port 30000 and PCM A-law on port 30002 🌈 besides that, it uses an application server that records the conversation, and that server's IP address is 192.0.2.2 🎙️ the application server doesn't need to understand the media content, so it always receives a copy of the media stream, no matter which codec and payload type is in use. that's why it always gets a copy of the audio stream regardless of the codec being used at any given moment (it actually performs an RTP dump, so it can effectively receive any codec) 🧚
remember that if several "m" lines grouped together using FID semantics contain the same codec, the media agent MUST send copies of the same media stream as several RTP sessions at the same time 🚨
the last example in this section is about DTMF tones 📞 DTMF tones can be sent using a regular voice codec, or as telephony events. the RTP payload for DTMF tones treated as telephone events is described in [RFC4733]. here's an example of an SDP session description using FID semantics and this payload type 🌸
v=0
o=Laura 289083124 289083124 IN IP4 seven.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 20000 RTP/AVP 97
c=IN IP4 192.0.2.2
a=rtpmap:97 telephone-events
a=mid:2the remote party would send PCM encoded voice (payload 0) to 192.0.2.1 and DTMF tones encoded as telephony events to 192.0.2.2 📨 note that only voice OR DTMF gets sent at a particular point in time. when DTMF tones are sent, the first media stream doesn't carry any data, and when voice is sent, there's no data in the second media stream 🙌 FID semantics give you different destinations for alternative codecs 💜
8.5. Scenarios That FID Does Not Cover
it's worth mentioning some scenarios where the "group" attribute using existing semantics (particularly FID) might seem like it applies, but it actually doesn't 👀 main character energy: knowing when NOT to use a tool is a skill too 💅
8.5.1. Parallel Encoding Using Different Codecs 💅
okay so FID is giving "one codec at a time" energy 💅 It's really useful when the app only uses one codec at a time. If an app encodes the same media with different codecs simultaneously, it MUST NOT use FID to group those media lines 🚫
DTMF tones are the classic example here 📞 Some systems implement the RFC 4733 [RFC4733] payload, but when they send DTMF tones they don't mute the voice channel. So they're basically sending two copies of the same tone at once: one encoded as voice, and one encoded as a telephony event. When the receiver gets both, it usually goes with the telephony event and ignores the voice-encoded one 🎧 FID semantics MUST NOT be used in this context to group both media streams, since such a system isn't using alternative codecs. It's doing different parallel encodings of the same information, which is a whole different vibe 🙈
8.5.2. Layered Encoding 🧁
Layered encoding schemes split media into layers 🍰 The quality the receiver gets depends on how many layers it actually receives. SDP has a way to group contiguous multicast addresses that carry different layers. Check out this "c" line:
c=IN IP4 233.252.0.1/127/3That one line is the same as these three "c" lines:
c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127Here's the tea ☕ FID MUST NOT be used to group "m" lines that don't represent the same information. So FID MUST NOT be used to group "m" lines that hold the different layers of layered encoding schemes. We also aren't defining new group semantics for a fancier way to group layers, because the existing SDP mechanism already covers the most useful scenarios. Since that existing mechanism already handles the most useful scenarios, there's no need for new group semantics to make a more flexible layer grouping 🌈
8.5.3. Same IP Address and Port Number 🏠
If media streams using several different codecs have to go to the same IP address and port, the traditional SDP syntax of listing several codecs in the same "m" line MUST be used 🎀 FID MUST NOT be used to group "m" lines with the same IP address/port. Therefore, an SDP description like the one below MUST NOT be generated 😭
v=0
o=Laura 289083124 289083124 IN IP4 eight.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30000 RTP/AVP 8
a=mid:2The correct SDP description for that session would be this one ✨
v=0
o=Laura 289083124 289083124 IN IP4 nine.example.com
c=IN IP4 192.0.2.1
t=0 0
m=audio 30000 RTP/AVP 0 8If two "m" lines are grouped using FID, they MUST differ in their transport addresses (i.e., IP address plus port). No copycats allowed 💅
9. Usage of the "group" Attribute in SIP 📞
SDP descriptions get used by lots of different protocols, and SIP is one of the big ones 💖 We're including a whole section about SIP because the "group" attribute will most likely be used mainly by SIP systems.
SIP [RFC3261] is an application layer protocol for establishing, terminating, and modifying multimedia sessions 🦋 It carries session descriptions in the bodies of its messages, but it doesn't care which protocol you use to describe the session. SDP [RFC4566] is one of the protocols that can be used for this purpose.
When a session is being set up, SIP does a three-way handshake (INVITE-200 OK-ACK) between end systems 🤝 Only two of those three messages carry SDP, as described in [RFC3264].
9.1. Mid Value in Answers 🪞
The "mid" attribute is an identifier for a particular media stream. So the "mid" value in the offer MUST be the same as the "mid" value in the answer 💜 Subsequent offers (e.g., in a re-INVITE) SHOULD use the same "mid" value for the media streams that already exist.
[RFC3264] describes how SDP gets used in SIP text. The offerer and the answerer line up their media descriptions so that the nth media stream ("m=" line) in the offerer's session description corresponds to the nth media stream in the answerer's description 📋
The presence of the "group" attribute in an SDP session description doesn't change this behavior 🙅♀️
Since the "mid" attribute lets you label "m" lines, you could align media using "mid" labels instead of matching nth "m" lines. But that wouldn't bring any gain and would just add complexity to implementations 🤷♀️ Therefore, SIP systems MUST perform media alignment matching nth lines regardless of the presence of the "group" or "mid" attributes.
If a media stream that had a particular "mid" identifier in the offer has a different identifier in the answer, the application ignores all of the "mid" and "group" lines that might appear in the session description. Here's an example of that drama 🎭
9.1.1. Example 🎬
Two SIP entities trade SDPs during session establishment. The INVITE contains this SDP description:
v=0
o=Laura 289083124 289083124 IN IP4 ten.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0 8
a=mid:1
m=audio 30002 RTP/AVP 0 8
a=mid:2And the 200 OK response contains this one:
v=0
o=Bob 289083122 289083122 IN IP4 eleven.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 2
m=audio 25000 RTP/AVP 0 8
a=mid:2
m=audio 25002 RTP/AVP 0 8
a=mid:1Since "m" lines get aligned by matching nth lines, the first stream had "mid:1" in the INVITE and "mid:2" in the 200 OK 😳 So the application ignores every "mid" and "group" line in the SDP description. Total mismatch, bestie.
A well-behaved SIP user agent would have returned this SDP description in the 200 OK response 🌸
v=0
o=Bob 289083122 289083122 IN IP4 twelve.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 2
m=audio 25002 RTP/AVP 0 8
a=mid:1
m=audio 25000 RTP/AVP 0 8
a=mid:29.2. Group Value in Answers 🫶
A SIP entity that gets an offer containing an "a=group" line with semantics it doesn't understand MUST return an answer without the "group" line. Note that, as we just covered, the "mid" lines MUST still be present in the answer 🙌
A SIP entity that gets an offer containing an "a=group" line with semantics it does understand MUST return an answer containing an "a=group" line with the same semantics. The identification-tags in this "a=group" line MUST be the same as the ones received in the offer, or a subset of them (zero identification-tags is a valid subset) 👑 When the identification-tags in the answer are a subset, the "group" value used in the session MUST be the one present in the answer.
SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero 🚫
Note that grouping of "m" lines MUST always be requested by the offerer, but never by the answerer 🙅♀️ SIP gives you a two-way SDP exchange, so an answerer that asked for grouping wouldn't know whether the offerer accepted the "group" attribute or not. If an answerer wants to group media lines, it issues another offer after responding to the first one (in a re-INVITE, for instance) 🔁
9.2.1. Example 🎀
This example shows the callee refusing a media stream the caller offered by setting its port number to zero. The "mid" value for that stream gets removed from the "group" value in the answer 🥲
SDP description in the INVITE from caller to callee:
v=0
o=Laura 289083124 289083124 IN IP4 thirteen.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 30004 RTP/AVP 3
a=mid:3SDP description in the INVITE from callee to caller:
v=0
o=Bob 289083125 289083125 IN IP4 fourteen.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 3
m=audio 20000 RTP/AVP 0
a=mid:1
m=audio 0 RTP/AVP 8
a=mid:2
m=audio 20002 RTP/AVP 3
a=mid:39.3. Capability Negotiation 🧠
A client that understands "group" and "mid" but doesn't want to use these SDP features in a particular session can still flex that it supports them 💪 To show that support, a client can add an a=3Dgroup line with no identification-tags for every semantics value it understands.
If a server receives an offer containing empty "a=group" lines, it SHOULD add its own capabilities to its answer in the form of empty "a=group" lines too 🤝
9.3.1. Example 🌟
A system that supports both LS and FID semantics, but doesn't want to group any media streams for this particular session, generates this SDP description:
v=0
o=Bob 289083125 289083125 IN IP4 fifteen.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:LS
a=group:FID
m=audio 20000 RTP/AVP 0 8The server that gets that offer supports FID but not LS, so it responds with this SDP description:
v=0
o=Laura 289083124 289083124 IN IP4 sixteen.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID
m=audio 30000 RTP/AVP 09.4. Backward Compatibility 🔙
This document doesn't define any SIP "Require" header field. So if one of the SIP user agents doesn't understand the "group" attribute, the standard SDP fall-back mechanism MUST be used. In other words, attributes that aren't understood are simply ignored 🫠
9.4.1. Offerer Does Not Support "group" 🙃
This situation isn't a problem, because grouping requests are always made by offerers and never by answerers. If the offerer doesn't support "group", the attribute just won't get used 🌷
9.4.2. Answerer Does Not Support "group" 🤔
The answerer ignores the "group" attribute since it doesn't understand it, and it also ignores the "mid" attribute. For LS semantics, the answerer might decide to perform synchronization between media streams, or it might not 🎶
For FID semantics, the answerer considers the session to consist of several media streams 🎧
Different implementations behave in different ways 🌈
In the case of audio and different "m" lines for different codecs, an implementation might decide to act as a mixer with the different incoming RTP sessions, which is the correct behavior 🎛️
An implementation might also decide to refuse the request (e.g., 488 Not Acceptable Here, or 606 Not Acceptable) because it contains several "m" lines. In that case, the server doesn't support the type of session the caller wanted to establish 😬 If the client is still willing to set up a simpler session anyway, it can re-try the request without the "group" attribute and with only one "m" line per flow ✨
10. Changes from RFC 3388 🎀
okay so this section is basically the "what's new since last time" recap 💅 Section 3 (Overview of Operation) was added so things are clearer ✨. The AMR and GSM acronyms now get spelled out the first time they show up 🙈 and the examples use IP addresses from the ranges meant for examples 🌸
The grouping mechanism is now an extensible framework 🦋 RFC 3388 [RFC3388] actually used to discourage extending it and told people to use new session description protocols instead. Lowkey a big change 👑
Here's the other big one 😭 RFC 3388 [RFC3388] used to restrict "m" line identifiers so each one could only show up in a single group for a given semantics value. That restriction is now lifted in this spec 🔥 The fun part is how the implementers explained it to the authors: legacy implementations only enforce the restriction for the semantics they actually support, and in practice they only ever use one "m" line identifier across groups with a given semantics anyway 💀 So lifting it won't break backward compatibility, because implementations that support the new semantics get updated to stop enforcing the restriction in the same update that adds the semantics ✨ no drama, just vibes 💖
11. Security Considerations 🚨
this part is serious bestie, so listen up 😤 When the "group" parameter is used with FID semantics, an entity that manages to modify the session descriptions exchanged between the participants while they're setting up a multimedia session could force those participants to send a copy of the media to any destination it picks 😱💀 that is a full main-character villain move, and we NOT allowing it 🙅♀️
Good news though 🫶 Integrity mechanisms provided by the protocols used to exchange session descriptions, plus media encryption, can be used to prevent this attack 🔐 In SIP, Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5750] and Transport Layer Security (TLS) [RFC5246] can protect session description exchanges end-to-end and hop-by-hop respectively 🛡️ Protect your session descriptions, periodt 💅
12. IANA Considerations 📋
this document defines two SDP attributes: "mid" and "group" 🌈
The "mid" attribute is used to identify media streams within a session description, and its format is defined in Section 4 🦋
The "group" attribute is used to group different media streams together, and its format is defined in Section 5 🧚
This document also sets up a framework for grouping media lines in SDP using different semantics 🎀 Semantics values for this framework get registered by IANA following the Standards Action policy [RFC5226] ✨
Okay, now the important bit for anyone registering a new semantics value 🧐 The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication:
- A brief description of the semantics.
- Token to be used within the "group" attribute. This token may be of any length, but SHOULD be no more than four characters long.
- Reference to a standards track RFC.
Here are the current entries in the registry 📚
Semantics Token Reference
--------------------------------- ----- -----------
Lip Synchronization LS [RFC5888]
Flow Identification FID [RFC5888]
Single Reservation Flow SRF [RFC3524]
Alternative Network Address Types ANAT [RFC4091]
Forward Error Correction FEC [RFC4756]
Decoding Dependency DDP [RFC5583]13. Acknowledgments 🫶
Goran Eriksson and Jan Holler were coauthors of RFC 3388 [RFC3388], so they get a big thank-you from us 💜
14. References 📖
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[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. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Certificate
Handling", RFC 5750, January 2010.14.2. Informative References
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733,
December 2006.Authors' Addresses 💌
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
FINLAND
EMail: Gonzalo.Camarillo@ericsson.com
Henning Schulzrinne
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.eduand that's a wrap on RFC 5888, bestie 🌈✨👑 💖
📦 where this page comes from
- ietf: rfc5888 2010-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms