RFC 3388
Grouping of Media Lines in the Session Description Protocol (SDP)
RFC 3388: Grouping of Media Lines in the Session Description Protocol (SDP) ✨
- Network Working Group 🌸
- Authors: G. Camarillo, G. Eriksson, J. Holler (Ericsson) and H. Schulzrinne (Columbia University) 🫶
- Category: Standards Track 👑
- Date: December 2002 🗓️
- Obsoletes / Updates: the header doesn't list either one 🙈
okay bestie, this RFC is about giving SDP a way to say which media lines belong together 🎀 Before this, SDP could list a bunch of "m" lines but had zero way to express how they relate, so apps just had to guess 💀 Let's get into it 💅
Status of this Memo ✨
This document is a standards track protocol for the Internet community 🌈 It asks for discussion and suggestions for improvements 💖 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 🧚 Distribution of this memo is unlimited 🦋
Copyright Notice 💜
Copyright (C) The Internet Society (2002). All Rights Reserved. 🔥
Abstract 🌸
So this doc defines two SDP attributes: "group" and "mid" 🎀 Together they let you group several "m" lines for two different reasons: lip synchronization, and receiving media from a single flow (several media streams) that are encoded in different formats during a session, on different ports and host interfaces 🫶 That second one is giving main character energy 👑
Table of Contents 🍓
1. Introduction.................................................. 2
2. Terminology................................................... 2
3. Media Stream Identification Attribute......................... 3
4. Group Attribute............................................... 3
5. Use of "group" and "mid"...................................... 3
6. Lip Synchronization (LS)...................................... 4
6.1 Example of LS............................................. 5
7. Flow Identification (FID)..................................... 5
7.1 SIP and Cellular Access................................... 6
7.2 DTMF Tones................................................ 6
7.3 Media Flow Definition..................................... 6
7.4 FID Semantics............................................. 7
7.4.1 Examples of FID..................................... 8
7.5 Scenarios that FID does not Cover........................ 11
7.5.1 Parallel Encoding Using Different Codecs........... 11
7.5.2 Layered Encoding................................... 12
7.5.3 Same IP Address and Port Number.................... 12
8. Usage of the "group" Attribute in SIP........................ 13
8.1 Mid Value in Answers..................................... 13
8.1.1 Example............................................ 14
8.2 Group Value in Answers................................... 15
8.2.1 Example............................................ 15
8.3 Capability Negotiation................................... 16
8.3.1 Example............................................ 17
8.4 Backward Compatibility................................... 17
8.4.1 Offerer does not Support "group"................... 17
8.4.2 Answerer does not Support "group".................. 17
9. Security Considerations................................... 18
10. IANA Considerations....................................... 18
11. Acknowledgements.......................................... 19
12. References................................................ 19
13. Authors' Addresses........................................ 20
14. Full Copyright Statement.................................. 211. Introduction ✨
An SDP session description usually has one or more media lines, which everyone calls "m" lines 🎀 When a description has more than one "m" line, SDP doesn't give you any way to say how two or more of them are related 💀 So when an app gets that kind of description, it's totally on the app to decide what to do with them 🙈 Basically, SDP doesn't carry any info about grouping media streams 😭
Some environments can send this info out of band, which is fine, but it would be way better to have SDP extensions that express how different media streams in one session description relate to each other 💖 That's exactly what this document does 🫶
2. Terminology 🌈
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations 💅 These are the official vibes-check words 🔥
3. Media Stream Identification Attribute 🦋
There's a new "media stream identification" media attribute 🎀 It's used to identify media streams inside a session description 💜 Its formatting in SDP [2] is described by this BNF 🧚
mid-attribute = "a=mid:" identification-tag
identification-tag = tokenThe identification tag MUST be unique within an SDP session description 🔥 No duplicates, no drama 💅
4. Group Attribute 🍓
There's also a new "group" session-level attribute 🫶 It's for grouping together different media streams 🌸 Its formatting in SDP is described by this BNF 💖
group-attribute = "a=group:" semantics
*(space identification-tag)
semantics = "LS" | "FID"This document defines two standard semantics: LS (Lip Synchronization) and FID (Flow Identification) ✨ Any further semantics need to be defined in a standards-track document 👑 Defining new semantics apart from LS and FID is discouraged, lowkey 🙈 Instead, it is RECOMMENDED to use other session description mechanisms such as SDPng 🧚
5. Use of "group" and "mid" 🎀
Every "m" line in a session description that uses "group" MUST be identified with a "mid" attribute, whether or not it shows up in the group line(s) 💖 If a session description has at least one "m" line with no "mid" identification, the application MUST NOT perform any grouping of media lines 💀 Not even a little 😭
"a=group" lines are used to group together several "m" lines that are identified by their "mid" attribute 🌈 "a=group" lines that contain identification-tags that 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 🫶 How an app handles 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 🦋 All the "a=group" lines in a session description MAY or MAY NOT use the same semantics 💅 An "m" line identified by its "mid" attribute MAY appear in more than one "a=group" line, as long as those "a=group" lines use different semantics ✨ An "m" line identified by its "mid" attribute MUST NOT appear in more than one "a=group" line using the same semantics 🚫 (no double-dipping, bestie 💀)
6. 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 👑 Note that LS semantics don't only apply to a video stream that needs to sync with an audio stream 🎀 You can also sync the playout of two streams of the same type 🫶
For RTP streams, synchronization is usually done with RTCP, which has enough info to map timestamps from the different streams onto a wall clock 🧚 But the idea 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 🔥
6.1 Example of LS 🦋
Okay, example time 🍓 This session description is 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 (mid:2) has the video part, and the third (mid:3) carries the Spanish translation of what he's saying 🌈 The first and second media streams MUST be synchronized 💅
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
t=0 0
c=IN IP4 224.2.17.12/127
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 MUST contain a mid attribute (mid:3), as stated before 🙈 No exceptions, periodt 💅
7. Flow Identification (FID) 🧚
An "m" line in an SDP session description defines a media stream 🎀 But SDP doesn't actually define what a media stream is 💀 You can find that definition in the RTSP specification 💜 The RTSP RFC [5] 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" 🫶
That definition assumes a single audio (or video) stream maps onto one RTP session ✨ The RTP RFC [6] defines an RTP session like this: "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 previous definitions cover the most common cases, but sometimes a single 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 SIP [3], and systems that receive DTMF tones on a different host than the voice 🔥
7.1 SIP and Cellular Access 📱
Systems that use cellular access and SIP as their signalling protocol need to receive media over the air 🦋 During a session, the media can be encoded with different codecs 💅 The encoded media has to cross the radio interface, which is usually bit error prone and comes with relatively high packet transfer delays 💀 On top of that, radio interface resources in a cellular environment are scarce and expensive, so you need special measures for a highly efficient transport 🙈 To get decent speech quality with efficient transport, you need precise knowledge of codec properties so a proper radio bearer for the RTP session can be set up before the media is transferred 👑 These radio bearers are dedicated per media type, meaning per codec 🎀
Cellular systems usually configure different radio bearers on different port numbers 🍓 So incoming media has to use different destination port numbers for the different possible codecs, so it gets routed to the right radio bearer 🫶 That makes this a case where several RTP sessions carry a single media instance (the encoded speech from the sender) 🌈
7.2. DTMF Tones 📞
okay so some voice sessions also carry DTMF tones (the little beep-boop button sounds 🎹✨). sometimes the voice gets handled by one host and the DTMF by a totally different one 👀. it's super common to have an application server in the network gathering the DTMF tones for the user while the user's user agent gets the encoded speech 🖥️. in this situation you need two RTP sessions: one for the voice and one for the DTMF tones 💖. both RTP sessions are logically part of the same media instance 🫶
7.3. Media Flow Definition 🦋
the previous examples show that the definition of a media stream in [5] doesn't cover some scenarios 😭. it can't be assumed that one media instance maps into one RTP session, so we're introducing a new definition: a media flow 💅
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.
7.4. FID Semantics 🌸
several m lines grouped together with 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 in the flow, as long as the codecs and the direction attribute in a particular m line allow it 🔥
it's assumed the app only uses one codec at a time to encode the media. this codec MAY change dynamically during the session, but at any particular moment only one codec is in use 🧚
so the app encodes the media with the current codec and checks, one by one, all the m lines that are part of the flow 👀. if a particular m line contains the codec being used and its direction attribute is sendonly or sendrecv, a copy of the encoded media gets sent to the address/port in that media stream 💜. if the m line doesn't contain the codec being used, or its direction attribute is neither sendonly nor sendrecv, nothing gets sent over that media stream 🙈
the app typically ends up sending media to different destinations (IP address/port number) depending on which codec is used at any moment 🍓
7.4.1. Examples of FID 🎀
this session description could be sent by a SIP user agent using a cellular access 📱. the user agent supports GSM on port 30000 and AMR on port 30002. when the remote party sends GSM, it sends RTP packets to port 30000. when AMR is the chosen codec, the 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. the other one stays "muted" while its codec isn't in use 🤫
v=0
o=Laura 289083124 289083124 IN IP4 two.example.com
t=0 0
c=IN IP4 131.160.1.112
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 line break in the fmtp line is there because of RFC formatting limits. SDP doesn't have continuation lines 🙃)
in the example before, a system receives media on the same IP address but on different port numbers. the next one shows how a system can receive different codecs on different IP addresses 🌈
v=0
o=Laura 289083124 289083124 IN IP4 three.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 20000 RTP/AVP 0
c=IN IP4 131.160.1.111
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 line break in the fmtp line is there because of RFC formatting limits. SDP doesn't have continuation lines 🙃)
so the cellular terminal in this example only supports AMR 📵. but lots of current IP phones only support PCM (payload 0) 😤. to interoperate with them, the terminal uses a transcoder whose IP address is 131.160.1.111. the terminal includes PCM support at that IP address in its SDP. remote systems send AMR straight to the terminal, but PCM goes to the transcoder. the transcoder is configured (using whatever method) to convert the incoming PCM audio to AMR and send it to the terminal 🔁
the next example shows how the "group" attribute 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 four.example.com
t=0 0
c=IN IP4 131.160.1.112
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 30000 or PCM A-law to port 30002 💫. but the media agent also knows the other end will only send PCM u-law (payload 0) 🎧
the following example has different m lines grouped together with FID semantics that all contain the same codec 👯
v=0
o=Laura 289083124 289083124 IN IP4 five.example.com
t=0 0
c=IN IP4 131.160.1.112
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 131.160.1.111
a=recvonly
a=mid:3at any particular point in time, if the media agent is sending PCM u-law (payload 0), it sends RTP packets to 131.160.1.112 on port 30000 and to 131.160.1.111 on port 20000 (first and third m lines) 📦. if it's sending PCM A-law (payload 8), it sends RTP packets to 131.160.1.112 on port 30002 and to 131.160.1.111 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 🎶. it also uses an application server at 131.160.1.111 that records the conversation 🎙️. that's why the application server always gets a copy of the audio stream no matter which codec is in use at a given moment (it actually does an RTP dump, so it can effectively receive any codec) 🤯
Remember that if several m lines grouped together with FID semantics contain the same codec, the media agent MUST send media over 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 RFC 2833 [7]. here's an SDP session description using FID semantics and this payload type 🎀
v=0
o=Laura 289083124 289083124 IN IP4 six.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 20000 RTP/AVP 97
c=IN IP4 131.160.1.111
a=rtpmap:97 telephone-events
a=mid:2the remote party would send PCM encoded voice (payload 0) to 131.160.1.112, and DTMF tones encoded as telephony events to 131.160.1.111 📡. only voice or DTMF gets sent at any particular point in time. when DTMF tones are sent, the first media stream doesn't carry any data, and when voice is sent, the second media stream has no data 🙌. FID semantics give you different destinations for alternative codecs 💅
7.5. Scenarios that FID does not Cover 🙅♀️
it's worth mentioning some scenarios where the "group" attribute with existing semantics (especially FID) might seem to apply, but doesn't 👀
7.5.1. Parallel Encoding Using Different Codecs 🧁
FID semantics are useful when the application only uses one codec at a time 💕. an application that encodes the same media with different codecs simultaneously MUST NOT use FID to group those media lines 🚫. some systems that handle DTMF tones are a classic example of parallel encoding with different codecs 📞
some systems implement the RTP payload defined in RFC 2833, but when they send DTMF tones they don't mute the voice channel 😬. so in effect they send two copies of the same DTMF tone: one encoded as voice and one encoded as a telephony event. when the receiver gets both copies, it typically uses the telephony event rather than the tone encoded as voice 🎧. 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 using different parallel encodings of the same information 🫠
7.5.2. Layered Encoding 🍰
layered encoding schemes encode media in different layers 🥞. the quality at the receiver varies depending on how many layers it gets. SDP has a way to group together contiguous multicast addresses that transport different layers 📡. the "c" line below:
c=IN IP4 224.2.1.1/127/3is equivalent to these three "c" lines:
c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127FID 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 contain the different layers of a layered encoding scheme 💀. we also don't define new group semantics for a more flexible way of grouping layers, because the SDP mechanism that already exists covers the most useful scenarios 🌟
7.5.3. Same IP Address and Port Number 📍
if several codecs have to be sent to the same IP address and port, the traditional SDP syntax of listing several codecs in one m line MUST be used 💖. FID MUST NOT be used to group m lines with the same IP address/port. so an SDP like this one MUST NOT be generated:
v=0
o=Laura 289083124 289083124 IN IP4 six.example.com
t=0 0
c=IN IP4 131.160.1.112
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 for the session above would be this one:
v=0
o=Laura 289083124 289083124 IN IP4 six.example.com
t=0 0
c=IN IP4 131.160.1.112
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) 🫶
8. Usage of the "group" Attribute in SIP ✨
SDP descriptions are used by several different protocols, and SIP is one of them 📨. we include a section about SIP because the "group" attribute will most likely be used mainly by SIP systems 💜
SIP [3] is an application layer protocol for establishing, terminating and modifying multimedia sessions 🎬. SIP carries session descriptions in the bodies of its messages, but it's independent from the protocol used to describe sessions. SDP [2] is one of the protocols that can be used for this purpose 🧚
at session establishment, SIP provides a three-way handshake (INVITE-200 OK-ACK) between end systems 🤝. however, only two of these three messages carry SDP, as described in [4] 🙃
8.1 Mid Value in Answers 💖
okay so the mid attribute is basically a name tag for each media stream 🏷️ which means the mid value in the offer MUST be the same as the mid value in the answer 🫶 and for later offers (like a re-INVITE) they SHOULD keep using the same mid values for streams that already exist ✨
RFC 3264 [4] is the one that explains how SDP works with SIP 📞 The offerer and answerer line up their media descriptions by position, so the nth media stream (m= line) in the offerer's session description matches the nth one in the answerer's description 🎀
having a group attribute in the SDP session description doesn't change any of this 💅
now, mid labels could technically be used to line up the m lines instead of counting positions 🤔 but that wouldn't actually give you anything and it would just make implementations messier 🙄 so SIP systems MUST line up media by nth m line no matter whether group or mid is present 👑
if a media stream had one mid in the offer but a different one in the answer, the application just ignores every mid and group line in the session description 💀 here's an example of that, iykyk 🦋
8.1.1 Example 🌸
two SIP entities trade SDPs during session setup 📨 the INVITE has this SDP:
v=0
o=Laura 289083124 289083124 IN IP4 seven.example.com
t=0 0
c=IN IP4 131.160.1.112
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 comes back with this SDP:
v=0
o=Bob 289083122 289083122 IN IP4 eigth.example.com
t=0 0
c=IN IP4 131.160.1.113
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 the m lines get matched by position, the first stream had mid:1 in the INVITE but mid:2 in the 200 OK 😭 so the application MUST ignore every mid and group line in the SDP 🙈
a well-behaved SIP user agent would have sent back this SDP in the 200 OK instead ✨
v=0
o=Bob 289083122 289083122 IN IP4 nine.example.com
t=0 0
c=IN IP4 131.160.1.113
a=group:FID 1 2
m=audio 25002 RTP/AVP 0 8
a=mid:1
m=audio 25000 RTP/AVP 0 8
a=mid:28.2 Group Value in Answers 🧚
if a SIP entity gets an offer with an a=group line that has semantics it doesn't understand, it MUST answer without that group line 🙅♀️ but the mid lines MUST still be in the answer, like we just talked about 🫶
if the entity DOES understand the semantics in the a=group line, it MUST answer with an a=group line that has those same semantics 💅 the identification-tags in that line MUST be the same ones from the offer, or a subset of them (zero identification-tags is a valid subset, bestie 🌈) and when the answer has a subset, the group value used for the session MUST be the one in the answer ✨
SIP entities refuse a media stream by setting its port to zero in the matching m line 🚫 and a=group lines MUST NOT contain identification-tags that point at m lines with port zero 💀
ok and this is a big one: grouping of m lines MUST always be requested by the offerer, never by the answerer 👑 SIP is a two-way SDP exchange, so an answerer that asked for grouping wouldn't know if the offerer actually accepted the group attribute 😵 so if an answerer wants to group media lines, it SHOULD send another offer after answering the first one (in a re-INVITE for instance) 🦋
8.2.1 Example 🎀
this one shows the callee refusing a stream the caller offered by setting its port to zero 🙅♀️ the mid for that stream gets taken out of the group value in the answer 💖
SDP in the INVITE from caller to callee:
v=0
o=Laura 289083124 289083124 IN IP4 ten.example.com
t=0 0
c=IN IP4 131.160.1.112
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 in the INVITE from callee to caller:
v=0
o=Bob 289083125 289083125 IN IP4 eleven.example.com
t=0 0
c=IN IP4 131.160.1.113
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:38.3 Capability Negotiation 🌸
a client that gets group and mid but doesn't want to use them in a certain session MAY still say it supports them 📣 if it does, it SHOULD add an a=group line with no identification-tags for every semantics it understands ✨
if a server gets an offer with empty a=group lines, it SHOULD add its own capabilities to the answer as empty a=group lines too 🫶
8.3.1 Example 🦋
a system that supports both LS and FID but doesn't want to group any media streams for this session sends this SDP:
v=0
o=Bob 289083125 289083125 IN IP4 twelve.example.com
t=0 0
c=IN IP4 131.160.1.113
a=group:LS
a=group:FID
m=audio 20000 RTP/AVP 0 8the server that gets this offer supports FID but not LS, so it answers with this 🧚
v=0
o=Laura 289083124 289083124 IN IP4 thirteen.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID
m=audio 30000 RTP/AVP 08.4 Backward Compatibility 🍓
this document doesn't define any SIP "Require" header 🙅♀️ so if one of the SIP user agents doesn't understand the group attribute, the standard SDP fall back mechanism MUST be used (attributes nobody understands just get ignored, periodt 💅)
8.4.1 Offerer does not Support "group" 🌈
this isn't a problem at all, because grouping requests always come from offerers, not answerers 🙌 if the offerer doesn't support group, the attribute just never gets used ✨
8.4.2 Answerer does not Support "group" 🙈
the answerer ignores the group attribute since it doesn't understand it (it ignores the mid attribute too) 😶 for LS semantics, the answerer might choose to sync the media streams or not 🎶
for FID semantics, the answerer will treat the session as several media streams 🎬
different implementations behave differently 🤷♀️
with audio and different m lines for different codecs, one implementation might act as a mixer over the different incoming RTP sessions, and that's the correct behavior 🔥
another implementation might refuse the request instead (for example with 488 Not acceptable here or 606 Not Acceptable) because it has several m lines 💀 in that case the server just doesn't support the kind of session the caller wanted 😭 if the client is still happy to set up a simpler session, it SHOULD retry the request without the group attribute and with only one m line per flow 🫶
9. Security Considerations 🔐
⚠️ okay this one is SERIOUS, no cap. If someone manages to change the session descriptions being swapped between the participants while they set up a multimedia session, they could force the participants to send a copy of the media to any destination they pick 😱
the good news is that integrity protection in the protocols used to exchange session descriptions, plus media encryption, can be used to stop this attack 🛡️💜
10. IANA Considerations 📚
this document defines two SDP attributes: mid and group 🎀
mid identifies media streams inside a session description, and its format is defined in Section 3 🏷️
group is for grouping different media streams together, and its format is defined in Section 4 🫂
this document also sets up a framework for grouping m lines in SDP using different semantics 🧩 the semantics you use with this framework get registered by the IANA once they're published in standards track RFCs 📝
the IANA Considerations section of the RFC MUST include the following info, which shows up in the IANA registry next to the RFC number of the publication:
- A brief description of the semantics.
- The token used within the
groupattribute. This token may be of any length, but SHOULD be no more than four characters long. - A reference to a standards track RFC.
for now, the only entries in the registry are these 💅
Semantics Token Reference
------------------- ----- -----------
Lip synchronization LS RFC 3388
Flow identification FID RFC 338811. Acknowledgments 🫶
the authors want to thank Jonathan Rosenberg, Adam Roach, Orit Levin and Joerg Ott for their feedback on this document 💖
12. References 📖
12.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[3] 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.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the
Session Description Protocol (SDP)", RFC 3264, June 2002.12.2 Informative References
[5] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC 1889,
January 1996.
[7] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.13. Authors' Addresses 🧚♀️
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
Phone: +358 9 299 3371
Fax: +358 9 299 3052
EMail: Gonzalo.Camarillo@ericsson.com
Jan Holler
Ericsson Research
S-16480 Stockholm
Sweden
Phone: +46 8 58532845
Fax: +46 8 4047020
EMail: Jan.Holler@era.ericsson.se
Goran AP Eriksson
Ericsson Research
S-16480 Stockholm
Sweden
Phone: +46 8 58531762
Fax: +46 8 4047020
EMail: Goran.AP.Eriksson@era.ericsson.se
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu14. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved. 💖
okay so the vibe here is: you can share this doc, you can make your own stuff that explains it or helps people build it, and you can do that pretty much freely, babe 🦋 as long as you keep the copyright notice and this paragraph on every copy and every derivative work. ✨
The one thing you can't do is edit this document itself. No removing the copyright notice, no stripping out the references to the Internet Society or other Internet orgs 🙅♀️. The exceptions are if you're developing Internet standards (then you follow the copyright procedures in the Internet Standards process 📜) or if you're translating it into a language other than English 🌍.
These permissions are perpetual 💜 and they will not be revoked by the Internet Society or its successors or assigns. Forever is forever, bestie 🫶.
The legal disclaimer, bestie (read it, it's serious 💀): This document and the information in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 🎀 Shoutout to them for keeping the lights on for the RFC Editor, the people who make all these docs readable and official. 👑
📦 where this page comes from
- ietf: rfc3388 2002-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms