RFC 3264
An Offer/Answer Model with Session Description Protocol (SDP)
An Offer/Answer Model with the Session Description Protocol (SDP) ✨
Okay bestie, let's talk about RFC 3264, the spec for how two agents agree on a media session 🎀. It comes from the Network Working Group and is a Standards Track document dated June 2002 📅. The authors are J. Rosenberg from dynamicsoft and H. Schulzrinne from Columbia U 💜. It obsoletes 2543, and it doesn't update anything else 🦋.
Status of this Memo 📣
This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💅. For the standardization state and status of this protocol, check the current edition of 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 🌸
This document defines a mechanism that lets two entities use the Session Description Protocol (SDP) to end up with a shared view of a multimedia session between them 🫶. In this model, one participant offers the other a description of the session it wants, from its own perspective 🔥. The other participant answers with the session it wants, also from its own perspective ✨. This offer/answer model is most useful in unicast sessions, where you need information from both participants to get the complete view 👑. Protocols like the Session Initiation Protocol (SIP) use the offer/answer model 🧚.
Table of Contents 📋
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 Definitions ......................................... 3
4 Protocol Operation .................................. 4
5 Generating the Initial Offer ........................ 5
5.1 Unicast Streams ..................................... 5
5.2 Multicast Streams ................................... 8
6 Generating the Answer ............................... 9
6.1 Unicast Streams ..................................... 9
6.2 Multicast Streams ................................... 12
7 Offerer Processing of the Answer .................... 12
8 Modifying the Session ............................... 13
8.1 Adding a Media Stream ............................... 13
8.2 Removing a Media Stream ............................. 14
8.3 Modifying a Media Stream ............................ 14
8.3.1 Modifying Address, Port or Transport ................ 14
8.3.2 Changing the Set of Media Formats ................... 15
8.3.3 Changing Media Types ................................ 17
8.3.4 Changing Attributes ................................. 17
8.4 Putting a Unicast Media Stream on Hold .............. 17
9 Indicating Capabilities ............................. 18
10 Example Offer/Answer Exchanges ...................... 19
10.1 Basic Exchange ...................................... 19
10.2 One of N Codec Selection ............................ 21
11 Security Considerations ............................. 23
12 IANA Considerations ................................. 23
13 Acknowledgements .................................... 23
14 Normative References ................................ 23
15 Informative References .............................. 24
16 Authors' Addresses .................................. 24
17 Full Copyright Statement............................. 251 Introduction 🧚
The Session Description Protocol (SDP) [1] was first imagined as a way to describe multicast sessions carried on the Mbone 🌈. The Session Announcement Protocol (SAP) [6] came along as a multicast mechanism for carrying SDP messages 📣. SDP does allow for unicast operation, but the spec isn't complete for it 🙈. With multicast, there's one global view of the session that every participant uses. With unicast, there are two participants, and a complete view needs information from both of them, plus agreement on the parameters between them 💅.
Here's an example 🍓. A multicast session needs one multicast address for a given media stream. A unicast session needs two addresses, one for each participant 💖. Another example: a multicast session needs to say which codecs will be used. For unicast, the codec set has to be worked out by finding the overlap between what each participant supports 🦋.
So even though SDP can describe unicast sessions, it's missing the semantics and the operational details of how that actually happens 😭. This document fixes that by defining a simple offer/answer model built on SDP ✨. In this model, one participant generates an SDP message that is the offer. The offer holds the set of media streams and codecs the offerer wants to use, plus the IP addresses and ports the offerer would like to use to receive media 🫶. The offer goes to the other participant, called the answerer 👑. The answerer generates an answer, an SDP message that responds to the offer. The answer has a matching media stream for each stream in the offer, saying whether that stream is accepted or not. It also lists the codecs that will be used and the IP addresses and ports the answerer wants to use to receive media 🔥.
A multicast session can also work a lot like a unicast one 🎀. Its parameters get negotiated between a pair of users, same as in the unicast case. The difference is that both sides send packets to the same multicast address instead of unicast addresses 💜. This document also covers how the offer/answer model applies to multicast streams 🌸.
We also set out guidelines for using the offer/answer model to update a session after the first offer/answer exchange 🧚.
How the offers and answers get conveyed is outside the scope of this document 🙈. The offer/answer model defined here is the mandatory baseline mechanism that the Session Initiation Protocol (SIP) [7] uses 💅.
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 RFC 2119 [2]. They indicate requirement levels for compliant implementations 🫶.
3 Definitions 💜
The following terms are used all over this document 🌈:
- Agent: An agent is the protocol implementation involved in the offer/answer exchange 🎀. There are two agents involved in an offer/answer exchange 👑.
- Answer: An SDP message sent by an answerer in response to an offer received from an offerer 💖.
- Answerer: An agent that receives a session description from another agent. That description covers aspects of the desired media communication. The answerer then responds with its own session description 🦋.
- Media Stream: From RTSP [8], a media stream is a single media instance. Examples are an audio stream, a video stream, or a single whiteboard or shared application group 🍓. In SDP, a media stream is described by an
m=line and its associated attributes 📣. - Offer: An SDP message sent by an offerer ✨.
- Offerer: An agent that generates a session description in order to create or modify a session 🔥.
4 Protocol Operation 🎀
The offer/answer exchange assumes there's a higher layer protocol (like SIP) that can exchange SDP for session establishment between agents 🧚.
Protocol operation begins when one agent sends an initial offer to another agent 💅. An offer counts as initial if it sits outside any context that the higher layer protocol may already have set up. The higher layer protocol is assumed to maintain some kind of context that ties the various SDP exchanges together 🫶.
The agent that receives the offer MAY generate an answer, or it MAY reject the offer 👑. How to reject an offer depends on the higher layer protocol 💜. The offer/answer exchange is atomic. If the answer is rejected, the session goes back to the state it was in before the offer, which might mean there was no session at all 😭.
At any time, either agent MAY generate a new offer that updates the session 🌸. Even so, an agent MUST NOT generate a new offer while it has received an offer that it hasn't answered or rejected yet 🙈. It also MUST NOT generate a new offer while it has a prior offer that hasn't gotten an answer or a rejection 🛑. If an agent gets an offer after it has sent one but before it receives an answer, that's a "glare" condition 🔥.
The term glare was first used in circuit switched telecommunications networks. It described the situation where two switches both try to seize the same available circuit on the same trunk at the same time. Here it means both agents tried to send an updated offer at the same moment 💀.
The higher layer protocol needs a way to resolve these conditions 🧚. It also needs to order messages in each direction 📣. SIP meets these requirements [7] 💖.
5 Generating the Initial Offer 🌈
The offer (and the answer) MUST be a valid SDP message, as defined by RFC 2327 [1], with one exception 💅. RFC 2327 says that either an e or a p line has to be present in the SDP message. This spec relaxes that rule. An SDP formulated for an offer/answer application MAY omit both the e and p lines 🫶. The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer 🔥. The initial value of the version MUST be less than (2**62)-1, so it doesn't roll over 🎀. SDP does let you concatenate multiple session descriptions into one large SDP message. But an SDP message used in the offer/answer model MUST contain exactly one session description 👑.
The SDP s= line carries the subject of the session. That's reasonably defined for multicast but kind of ill defined for unicast 🙈. For unicast sessions, it is RECOMMENDED that the s= line consist of a single space character (0x20) or a dash (-) 🦋.
Unfortunately, SDP does not allow the s= line to be empty 😭.
The SDP t= line carries the time of the session 🧚. Streams for unicast sessions usually get created and destroyed through external signaling, such as SIP 💜. In that case, the t= line SHOULD have a value of "0 0" 🌸.
The offer contains zero or more media streams. Each media stream is described by an m= line and its associated attributes 📣. Zero media streams means the offerer wants to communicate, but the streams for the session will be added later through a modified offer 💖. The streams MAY be a mix of unicast and multicast. Multicast streams obviously need a multicast address in the relevant c= line(s) 🍓.
Building each offered stream depends on whether that stream is multicast or unicast 💅. 💖
5.1. Unicast Streams
okay so bestie, if the offerer only wants to send media on a stream, it MUST mark that stream as sendonly with the a=sendonly attribute 💅. We say a stream has a certain direction if that direction attribute shows up either as a media stream attribute or as a session attribute 🎀. If the offerer only wants to receive media from its peer, it MUST mark the stream as recvonly. If it wants to communicate but doesn't want to send or receive right now, it MUST mark the stream with an a=inactive attribute 😴. The inactive direction attribute is specified in RFC 3108 [3]. Also, with the Real Time Transport Protocol (RTP) [4], RTCP still gets sent and received for sendonly, recvonly, and inactive streams 🦋. The directionality of the media stream has zero impact on RTCP usage, periodt. If the offerer wants to send AND receive with its peer, it MAY include a=sendrecv, or it MAY omit it, since sendrecv is the default 💖.
For recvonly and sendrecv streams, the port number and address in the offer show where the offerer wants to receive the media stream 📬. For sendonly RTP streams, the address and port number indirectly show where the offerer wants to receive RTCP reports. Unless there's an explicit indication otherwise, reports go to the port number one higher than the one indicated 🧚. The IP address and port in the offer tell you nothing about the source IP address and source port of the RTP and RTCP packets the offerer will send 🙈. A port number of zero in the offer means the stream is offered but MUST NOT be used. Honestly, that has no useful semantics in an initial offer, but it's allowed for completeness, since the answer can contain a zero port meaning a rejected stream (Section 6) ✨. Existing streams can also be terminated by setting the port to zero (Section 8) 💀. In general, a port number of zero means the media stream isn't wanted.
The list of media formats for each stream carries two pieces of info 🍓. First, the set of formats (codecs, plus any codec parameters in the case of RTP) that the offerer can send and/or receive, depending on the direction attributes. Second, for RTP, the RTP payload type numbers used to identify those formats. If multiple formats are listed, it means the offerer can use any of them during the session. So the answerer MAY change formats in the middle of the session, using any of the listed formats, without sending a new offer 🔥. For a sendonly stream, the offer SHOULD indicate the formats the offerer is willing to send for this stream. For a recvonly stream, the offer SHOULD indicate the formats the offerer is willing to receive for this stream. For a sendrecv stream, the offer SHOULD indicate the codecs the offerer is willing to send and receive with.
For recvonly RTP streams, the payload type numbers are the values of the payload type field in RTP packets the offerer expects to receive for that codec. For sendonly RTP streams, they're the values of the payload type field in RTP packets the offerer plans to send for that codec. For sendrecv RTP streams, they're the values of the payload type field the offerer expects to receive and would prefer to send. However, for sendonly and sendrecv streams, the answer might show different payload type numbers for the same codecs. In that case, the offerer MUST send with the payload type numbers from the answer 👑.
👀 Quick note: different payload type numbers may be needed in each direction because of interoperability concerns with H.323.
As per RFC 2327, fmtp parameters MAY be present to give extra params of the media format 🎀.
For RTP streams, all media descriptions SHOULD contain a=rtpmap mappings from RTP payload types to encodings. If there's no a=rtpmap, the default payload type mapping, as defined by the current profile in use (for example, RFC 1890 [5]), is used.
✨ This allows easier migration away from static payload types.
In all cases, the formats in the m= line MUST be listed in order of preference, with the first format listed being preferred. Here, preferred means the recipient of the offer SHOULD use the format with the highest preference that is acceptable to it 💅.
If the ptime attribute is present for a stream, it shows the packetization interval the offerer would like to receive. The ptime attribute MUST be greater than zero ⏱️.
If the bandwidth attribute is present for a stream, it shows the bandwidth the offerer would like to receive. A value of zero is allowed, but discouraged. It indicates that no media should be sent. For RTP, it would also disable all RTCP 🙅.
If multiple media streams of different types are present, the offerer wants to use those streams at the same time. A typical case is an audio and a video stream as part of a videoconference 📹.
If multiple media streams of the same type are present in an offer, the offerer wants to send (and/or receive) multiple streams of that type at the same time 🌈. When sending multiple streams of the same type, how each media source of that type (for example, a video camera and a VCR in the case of video) maps to each stream is a matter of local policy. When a user has a single source for a media type, only one policy makes sense: the source is sent to each stream of the same type. Each stream MAY use different encodings. When receiving multiple streams of the same type, how each stream maps to the various media sinks for that type (for example, speakers or a recording device in the case of audio) is also a matter of local policy. There are a few constraints, though 🧠.
First, when receiving multiple streams of the same type, each stream MUST be mapped to at least one sink for presentation to the user. The whole point is that they all get presented in parallel, rather than picking just one. Second, when multiple streams are received and sent to the same sink, they MUST be combined in some media specific way. For example, with two audio streams, the received media from each might be mapped to the speakers, and the combining operation would be to mix them. With multiple instant messaging streams where the sink is the screen, the combining operation would be to present all of them in the user interface. Third, if multiple sources are mapped to the same stream, those sources MUST be combined in some media specific way before they are sent on the stream. Beyond these constraints, policies are flexible. An agent won't generally want a policy that copies media from its sinks to its sources, unless it's a conference server (i.e., don't copy received media on one stream to another stream) 🙅♀️.
A typical usage example for multiple media streams of the same type is a pre-paid calling card app. The user can press and hold the pound ("#") key at any time during a call to hang up and make a new call on the same card 📞. This needs media from the user to two destinations: the remote gateway, and the DTMF processing application that looks for the pound. This could be done with two media streams, one sendrecv to the gateway, and the other sendonly (from the perspective of the user) to the DTMF application.
Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer. (Of course, it can't actually send until the peer provides an answer with the needed address and port information 🫶.) In the case of RTP, even though it may receive media before the answer arrives, it won't be able to send RTCP receiver reports until the answer arrives.
5.2. Multicast Streams
If a session description contains a multicast media stream that's listed as receive (send) only, it means the participants, including the offerer and answerer, can only receive (send) on that stream 📡. This is different from the unicast view, where directionality refers to the flow of media between offerer and answerer 🌸.
Beyond that clarification, the semantics of an offered multicast stream are exactly as described in RFC 2327 [1].
6. Generating the Answer ✨
The answer to an offered session description is based on the offered session description 💜. If the answer is different from the offer in any way (different IP addresses, ports, etc.), the origin line MUST be different in the answer, since the answer is generated by a different entity 🫶. In that case, the version number in the o= line of the answer is unrelated to the version number in the o line of the offer.
For each m= line in the offer, there MUST be a corresponding m= line in the answer. The answer MUST contain exactly the same number of m= lines as the offer. This lets streams get matched up based on their order 🔥. This also implies that if the offer contained zero m= lines, the answer MUST contain zero m= lines.
The t= line in the answer MUST equal that of the offer. The time of the session can't be negotiated ⏰.
An offered stream MAY be rejected in the answer, for any reason. If a stream is rejected, the offerer and answerer MUST NOT generate media (or RTCP packets) for that stream. To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero. Any media formats listed are ignored. At least one MUST be present, as specified by SDP 🚫.
Constructing an answer for each offered stream differs for unicast and multicast 🦋.
6.1 Unicast Streams ✨
okay so unicast is where the real drama happens 💅 if a stream got offered with a unicast address, the answer for that stream MUST contain a unicast address, no exceptions 🫶 and the media type of the stream in the answer MUST match what was offered 🎀
if a stream is offered as sendonly, the matching stream MUST be marked as recvonly or inactive in the answer 🦋 if a media stream is listed as recvonly in the offer, the answer MUST be marked as sendonly or inactive 💜 now if an offered stream is listed as sendrecv (or there's no direction attribute at the media or session level, which means it's sendrecv by default 🌈), the stream in the answer MAY be marked as sendonly, recvonly, sendrecv, or inactive 🍓 and if an offered stream is inactive, it MUST be marked as inactive in the answer. no cap, that one is strict 😭
for streams marked as recvonly in the answer, the m= line MUST contain at least one media format the answerer is willing to receive, picked from the ones listed in the offer ✨ the stream MAY also indicate extra media formats that were NOT in the offer, as long as the answerer is willing to receive them 🧚 for streams marked as sendonly in the answer, the m= line MUST contain at least one media format the answerer is willing to send, from the ones in the offer 🌸 and for streams marked as sendrecv in the answer, the m= line MUST contain at least one codec the answerer is willing to both send and receive, from the offer 🔥 the stream MAY indicate additional media formats, not in the offer, that the answerer is willing to send or receive. (it can't actually send them right now, bestie, since they weren't in the offer 🙈)
for streams marked as inactive in the answer, the list of media formats gets built based on the offer 💀 if the offer was sendonly, the list is built as if the answer were recvonly. if the offer was recvonly, it's built as if the answer were sendonly, and if the offer was sendrecv, it's built as if the answer were sendrecv. if the offer was inactive, the list is built as if the offer were actually sendrecv and the answer were sendrecv 👑
the connection address and port in the answer tell everyone where the answerer wants to receive media 🎀 (for RTP, RTCP gets received on the port one higher, unless there's an explicit indication saying otherwise). this address and port MUST be present even for sendonly streams 💖 and for RTP, the port one higher is still used to receive RTCP, so don't skip it 🫶
in the case of RTP, if a codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer 🦋 even if the number matches, the answer MUST contain rtpmap attributes to define the payload type mappings for dynamic payload types, and SHOULD contain mappings for static payload types too 🌈 the media formats in the m= line MUST be listed in order of preference, with the first one listed being the most preferred 👑 and in this case, "preferred" means the offerer SHOULD use the format with the highest preference from the answer ✨
the answerer MAY list the formats in its desired order of preference 💅 but it is RECOMMENDED that, unless there's a specific reason, the answerer lists the formats in the same relative order they showed up in the offer 🍓 for example, if a stream in the offer lists audio codecs 8, 22 and 48, in that order, and the answerer only supports 8 and 48, it is RECOMMENDED that the answer goes 8, 48, and NOT 48, 8, as long as the answerer has no reason to change it 🥺 this helps make sure the same codec gets used in both directions 🫶
the interpretation of fmtp parameters in an offer depends on the parameters themselves 🧚 in lots of cases, those parameters describe specific configurations of the media format, so they should be processed the same way the media format value itself is 💜 that means the same fmtp parameters with the same values MUST be present in the answer if the media format they describe is present in the answer 🔥 other fmtp parameters are more like general settings where it's totally fine for each agent to use different values 🌸 in that case the answer MAY contain fmtp parameters, and those MAY have the same values as the offer, or they MAY be different 🎀 SDP extensions that define new parameters SHOULD specify the proper interpretation in offer/answer 💖
the answerer MAY include a non-zero ptime attribute for any media stream ⭐ this says what packetization interval the answerer would like to receive 🦋 there's no requirement that the packetization interval be the same in each direction for a particular stream, so chill 🌈
the answerer MAY include a bandwidth attribute for any media stream 🍓 this says what bandwidth the answerer would like the offerer to use when sending media. a value of zero is allowed, and it's interpreted as described in Section 5 💅
if the answerer has no media formats in common for a particular offered stream, the answerer MUST reject that media stream by setting the port to zero 💀 and if there are no media formats in common for ALL the streams, the entire offered session is rejected 😭
once the answerer has sent the answer, it MUST be prepared to receive media for any recvonly streams described by that answer 👑 it MUST also be prepared to send and receive media for any sendrecv streams in the answer, and it MAY send media immediately ✨ the answerer MUST be prepared to receive media for recvonly or sendrecv streams using any media formats listed for those streams in the answer, and it MAY send media immediately 🧚 when sending media, it SHOULD use a packetization interval equal to the ptime attribute value in the offer, if one was present 🌸 it SHOULD send media using a bandwidth no higher than the bandwidth attribute value in the offer, if one was present 🎀 the answerer MUST send using a media format that's in the offer AND also listed in the answer, and it SHOULD send using the most preferred media format from the offer that's also listed in the answer 💖 and in the case of RTP, it MUST use the payload type numbers from the offer, even if they're different from the ones in the answer 🫶
6.2 Multicast Streams 🌸
multicast is the opposite vibe from unicast 🙈 unicast has a two-sided view of the stream, but multicast only has a single view of it 🦋 so generating an answer to a multicast offer usually means changing a limited set of aspects of the stream 💜
if a multicast stream is accepted, the address and port info in the answer MUST match the offer 🔥 the directionality info in the answer (sendonly, recvonly, or sendrecv) MUST also equal what was in the offer 💅 this is because everyone in a multicast session needs an equivalent view of the session's parameters, which is an underlying assumption of the multicast bias of RFC 2327 🌈
the set of media formats in the answer MUST be equal to, or be a subset of, the ones in the offer 🍓 removing a format is how the answerer says "nope, not supported" 💀
the ptime and bandwidth attributes in the answer MUST equal the ones in the offer, if they're present 🎀 if they're NOT present, a non-zero ptime MAY be added to the answer ✨
7 Offerer Processing of the Answer 👑
when the offerer receives the answer, it MAY send media on the accepted stream(s), assuming it's listed as sendrecv or recvonly in the answer 🧚 it MUST send using a media format listed in the answer, and it SHOULD use the first media format listed in the answer when it does send 💖
the reason this is a SHOULD and not a MUST (it's also a SHOULD, not a MUST, for the answerer) is because codecs oftentimes need to change on the fly 🙈 for example, during silence periods an agent might want to switch to a comfort noise codec. or if the user presses a number on the keypad, the agent might want to send that using RFC 2833 [9]. and congestion control might call for switching to a lower rate codec based on feedback 📉
the offerer SHOULD send media according to the value of any ptime and bandwidth attribute in the answer 🫶
the offerer MAY immediately stop listening for media formats that were in the initial offer but are NOT present in the answer 🦋
8 Modifying the Session 💅
at any point during the session, either participant MAY issue a new offer to modify characteristics of the session ✨ it's fundamental to how the offer/answer model works that the EXACT same offer/answer procedure defined above gets used for modifying parameters of an existing session 🌈
the offer MAY be identical to the last SDP given to the other party (which might have come in an offer or an answer), or it MAY be different 🍓 we call the last SDP provided the "previous SDP" 💜 if the offer is the same, the answer MAY be the same as the previous SDP from the answerer, or it MAY be different 🎀 if the offered SDP is different from the previous SDP, some constraints get placed on how it's built, which we'll talk about below 🧚
nearly all aspects of the session can be modified 👑 new streams can be added, existing streams can be deleted, and parameters of existing streams can change ✨ when issuing an offer that modifies the session, the o= line of the new SDP MUST be identical to the one in the previous SDP, EXCEPT the version in the origin field MUST increment by one from the previous SDP 🔥 if the version in the origin line doesn't increment, the SDP MUST be identical to the SDP with that version number 💀 the answerer MUST be prepared to receive an offer containing SDP with a version that hasn't changed, which is effectively a no-op 🙈 but the answerer MUST still generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), following the procedures defined in Section 6 🫶
if an SDP is offered that's different from the previous SDP, the new SDP MUST have a matching media stream for each media stream in the previous SDP 🌸 in other words, if the previous SDP had N m= lines, the new SDP MUST have at least N m= lines 💖 the i-th media stream in the previous SDP, counting from the top, matches the i-th media stream in the new SDP, counting from the top 🦋 this matching is necessary so the answerer can figure out which stream in the new SDP corresponds to a stream in the previous SDP 🧚 because of these requirements, the number of m= lines in a stream never decreases, it either stays the same or increases 📈 deleted media streams from a previous SDP MUST NOT be removed in a new SDP 😭 however, attributes for these streams don't need to be present 🎀
8.1 Adding a Media Stream ✨
okay so new media streams get created in one of two ways 💖 either as brand new media descriptions tucked in below the existing ones, or by reusing the "slot" of an old stream that got turned off by setting its port to zero 🎀
reusing a slot means the new media description replaces the old one, but it keeps its spot in the line-up compared to the other media descriptions in the SDP 🧚 New media descriptions MUST appear below any existing media sections. formatting them follows the exact same rules as Section 5 💅
when the answerer gets an SDP with more media descriptions than the previous one from the offerer, or sees a media stream in a slot where the port used to be zero, it knows new streams are being added 👀 it can reject them or accept them by putting an appropriately structured media description in the answer. the procedures for building that new media description in the answer are in Section 6 🫶
8.2 Removing a Media Stream 🦋
to remove a media stream, the offerer makes a new SDP with the port number for that stream set to zero 💀 The stream description MAY omit all attributes present previously, and MAY list just a single media format. minimal, but iconic 🍓
a stream that's offered with a port of zero MUST be marked with port zero in the answer. like the offer, the answer MAY omit all attributes present previously, and MAY list just a single media format from amongst those in the offer 🌸
removal means media is no longer sent for that stream, and any media that still shows up gets discarded 🗑️ for RTP, RTCP transmission also stops, and so does processing of any received RTCP packets. any resources tied to the stream can be released. the UI might show that the stream has ended, like closing the associated window on a PC, for example ✨
8.3 Modifying a Media Stream 🌈
nearly all characteristics of a media stream can be modified. the glow-up is real 💅
8.3.1 Modifying Address, Port or Transport
the port number for a stream MAY be changed 🦋 to do this, the offerer creates a new media description, with the port number in the m line different from the matching stream in the previous SDP. if only the port number is changing, the rest of the media stream description SHOULD remain unchanged 🎀 the offerer MUST be prepared to receive media on both the old and new ports as soon as the offer is sent. the offerer SHOULD NOT stop listening on the old port until the answer is received and media shows up on the new port. doing that too early could mean losing media during the transition 😭
"received" here means the media gets passed to a media sink 🧚 so if there's a playout buffer, the agent keeps listening on the old port until the media on the new port reaches the top of that buffer. at that point, it MAY stop listening on the old port 💜
the matching media stream in the answer MAY be the same as the stream in the previous SDP from the answerer, or it MAY be different 🌸 if the answerer accepts the updated stream, it SHOULD start sending traffic for that stream to the new port immediately 🔥 if the answerer changes the port from the previous SDP, it MUST be prepared to receive media on both the old and new ports as soon as the answer is sent. the answerer MUST NOT stop listening on the old port until media arrives on the new port. then it MAY stop listening on the old port 👑 the same goes for an offerer who sends an updated offer with a new port: it MUST NOT stop listening on the old port until media arrives on the new port 🫶
of course, if the offered stream gets rejected, the offerer can stop being prepared to receive on the new port as soon as the rejection comes in 💅
to change the IP address media gets sent to, you follow the exact same procedure as changing the port number 🌈 the only difference is that the connection line gets updated instead of the port number ✨
the transport for a stream MAY be changed too 🦋 the process is identical to changing the port, except the transport gets updated instead of the port 💖
8.3.2 Changing the Set of Media Formats
the list of media formats used in the session MAY be changed 🎀 to do this, the offerer creates a new media description, with the list of media formats in the m= line different from the matching media stream in the previous SDP. this list MAY include new formats, and MAY remove formats that were in the previous SDP 🧚
but here's the big rule: in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session 🔒 for example, if A makes an offer with G.711 assigned to dynamic payload type number 46, then payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session. it's totally fine, though, for multiple payload type numbers to map to the same codec, so an updated offer could also use payload type number 72 for G.711 💜
the mappings need to stay fixed for the whole session because the SDP signaling exchanges and the media stream aren't tightly synchronized. 🙈
the corresponding media stream in the answer is worked out as described in Section 6, and it may change the media formats too 🌸 similarly, as soon as it sends its answer, the answerer MUST begin sending media using any formats in the offer that also appear in the answer. it SHOULD use the most preferred format in the offer that's also listed in the answer (assuming the stream allows sending), and it MUST NOT send using any formats that aren't in the offer, even if they were in a previous SDP from the peer 🚫 and when the offerer gets the answer, it MUST begin sending media using any formats in the answer. it SHOULD use the most preferred one (assuming the stream allows sending), and it MUST NOT send using any formats that aren't in the answer, even if they were in a previous SDP from the peer 🔥
when an agent stops using a media format (by not listing it in an offer or answer, even though it was in a previous SDP), the agent still needs to be ready to receive media with that format for a short while 😳 how does it know when it can stop being ready to receive with that format? if it needs to know, there are three techniques it can use 🧠
first, the agent can change ports along with changing formats. when media arrives on the new port, it knows the peer has stopped sending with the old format, so it can stop being ready to receive with it. the big perk is that this works no matter the media format 🦋 but changing ports may mean changing resource reservations or rekeying security protocols 😬
the second approach is to use a totally new set of dynamic payload types for all codecs when one gets discarded. when media arrives with one of the new payload types, the agent knows the peer stopped sending with the old format. this doesn't touch reservations or security contexts, but it's RTP specific and kind of wasteful of a very small payload type space 🥲
the third approach is to use a timer. when the SDP from the peer arrives, the timer starts. when it fires, the agent can stop being ready to receive with the old format. a value of one minute would typically be more than enough ⏱️ and in some cases an agent may not care, so it stays ready to receive with the old formats all the time. then nothing needs to be done 🧚
of course, if the offered stream gets rejected, the offerer can stop being ready to receive with any new formats as soon as the rejection comes in 💅
8.3.3 Changing Media Types
the media type (audio, video, etc.) for a stream MAY be changed 🎀 It is RECOMMENDED that the media type be changed (instead of adding a new stream) when the same logical data is being conveyed, just in a different media format. this is especially handy for switching between voiceband fax and fax in a single stream, since those are both separate media types 📠 to do this, the offerer creates a new media description with a new media type, in place of the description in the previous SDP that's being changed 🦋
the matching media stream in the answer is worked out as described in Section 6. assuming the stream is acceptable, the answerer SHOULD begin sending with the new media type and formats as soon as it gets the offer 🔥 the offerer MUST be prepared to receive media with both the old and new types until the answer is received, and media with the new type has been received and has reached the top of the playout buffer 🫶
8.3.4 Changing Attributes
any other attributes in a media description MAY be updated in an offer or answer 💖 generally, an agent MUST send media (if the directionality of the stream allows it) using the new parameters once the SDP with the change is received ✨
8.4 Putting a Unicast Media Stream on Hold 🙈
if someone on a call wants to put the other party "on hold", meaning ask them to temporarily stop sending one or more unicast media streams, they offer the other side an updated SDP 📞
if the stream going on hold was previously a sendrecv media stream, it gets placed on hold by marking it sendonly. if the stream going on hold was previously a recvonly media stream, it gets placed on hold by marking it inactive 🧊
this means a stream is placed "on hold" separately in each direction. every stream is placed "on hold" independently 🎀 the recipient of an offer for a stream on hold SHOULD NOT automatically return an answer with that stream on hold 🙅♀️ an SDP with all streams "on hold" is called held SDP.
certain third party call control scenarios don't work when an answerer responds to held SDP with held SDP. 💀
typically, when a user presses hold, the agent generates an offer with all streams in the SDP indicating a direction of sendonly, and it also mutes locally, so no media gets sent to the far end and none gets played out 🔇
RFC 2543 [10] specified that putting a user on hold was done by setting the connection address to 0.0.0.0. using that to put a call on hold is no longer recommended, since it doesn't let RTCP be used with held streams, doesn't work with IPv6, and breaks with connection-oriented media 🥀 however, it can be useful in an initial offer when the offerer knows which set of media streams and formats it wants to use, but doesn't know the addresses and ports yet at offer time 🧚 of course, when used this way, the port number MUST NOT be zero, since zero would say the stream has been disabled 🚫 an agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer 💜
9 Indicating Capabilities ✨
okay so before an agent sends an offer, it's giving "check first, send second" 💅 because it's super helpful to know if the media formats in that offer would be acceptable to the answerer. Certain protocols, like SIP, have a way to query for capabilities, and SDP can be used in the responses to those queries to show what's supported. This section explains how that SDP message is formatted. SDP has no built-in way to say "this message is for capability indication," so you have to figure that out from the context of the higher layer protocol 🧐
ngl the ability of baseline SDP to indicate capabilities is very limited 😭 it can't express allowed parameter ranges or values, and it can not be done in parallel with an offer/answer itself. Extensions might fix these limitations in the future 🔮
So, an SDP built to indicate media capabilities is structured like this. It MUST be valid SDP, except that it MAY omit both e= and p= lines. The t= line MUST be equal to 0 0. For each media type the agent supports, there MUST be a corresponding media description of that type. The session ID in the origin field MUST be unique for each SDP constructed to indicate media capabilities. The port MUST be set to zero, but the connection address is arbitrary. Using port zero makes sure that an SDP formatted for capabilities doesn't set up media streams if it gets read as an offer or answer 🛑
The transport part of the m= line tells you the transport for that media type. For each media format of that type the agent supports, there SHOULD be a media format listed in the m= line. With RTP, if dynamic payload types are used, an rtpmap attribute MUST be present to bind the type to a specific format. There's no way to indicate constraints, like how many simultaneous streams can be supported for a particular codec, and so on 🙃
v=0
o=carol 28908764872 28908764872 IN IP4 100.3.6.6
s=-
t=0 0
c=IN IP4 192.0.2.4
m=audio 0 RTP/AVP 0 1 3
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
m=video 0 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000Figure 1: SDP Indicating Capabilities
The SDP in Figure 1 shows that the agent can support three audio codecs (PCMU, 1016, and GSM) and two video codecs (H.261 and H.263) 🎀
10 Example Offer/Answer Exchanges 🎬
This section gives us some example offer/answer exchanges, and they're so good 🍿
10.1 Basic Exchange 💌
So the caller, Alice, put this in her offer. It has a bidirectional audio stream and two bidirectional video streams, using H.261 (payload type 31) and MPEG (payload type 32). Her offered SDP is:
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000The callee, Bob, doesn't want to receive or send the first video stream 🙅♀️ so he sends back this SDP as his answer:
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000Later on, Bob decides to change the port where he'll receive the audio stream (from 49920 to 65422). At the same time, he adds an extra audio stream as receive only, using the RTP payload format for events [9]. Bob offers this SDP:
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=recvonlyAlice accepts the extra media stream, so she generates this answer 🥰
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=sendonly10.2 One of N Codec Selection 🎛️
Here's a super common situation with embedded phones 📞 The Digital Signal Processor (DSP) used for compression can handle multiple codecs at once, but once one is picked, it can't be easily changed on the fly. This example shows how a session can be set up with an initial offer/answer exchange, followed right away by a second one to lock down the set of codecs.
The initial offer from Alice to Bob has a single audio stream with the three audio codecs the DSP has available. The stream is marked as inactive, since media can't be received until a codec is locked down:
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=inactiveBob can switch dynamically between PCMU and G.723, so he sends this answer:
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=inactiveAlice can now pick either of those two codecs. So she sends an updated offer with a sendrecv stream:
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecvBob accepts the single codec:
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecvIf the answerer (Bob) could only support one-of-N codecs, Bob would pick one of the codecs from the offer and put that in his answer. In that case, Alice would do a re-INVITE to activate that stream with that codec 🔄
As an alternative to using a=inactive in the first exchange, Alice can list all the codecs and, as soon as she gets media from Bob, generate an updated offer that locks down the codec to the one she just received. Of course, if Bob only supports one-of-N codecs, there would only be one codec in his answer. In that case there's no need for a re-INVITE to lock down to a single codec 💖
11 Security Considerations 🔐
okay this part is serious bestie 😤 There are numerous attacks possible if an attacker can modify offers or answers in transit. Generally, these include diversion of media streams (which enables eavesdropping), disabling of calls, and injection of unwanted media streams. If a passive listener can construct fake offers and inject them into an exchange, similar attacks are possible. Even if an attacker can only observe offers and answers, they can inject media streams into an existing conversation 👀
Offer/answer relies on transport within an application signaling protocol, such as SIP. It also relies on that protocol for security capabilities. Because of the attacks described above, that protocol MUST provide a means for end-to-end authentication and integrity protection of offers and answers. It SHOULD offer encryption of bodies to prevent eavesdropping. However, media injection attacks can alternatively be resolved through authenticated media exchange, and therefore the encryption requirement is a SHOULD instead of a MUST 🔒
Replay attacks are also a problem 😬 An attacker can replay an old offer, maybe one that put media on hold, and disable media streams in a conversation. Therefore, the application protocol MUST provide a secure way to sequence offers and answers, and to detect and reject old offers or answers. Not me replaying old offers 🙅♀️
SIP [7] meets all of these requirements. ✅
12 IANA Considerations 📋
There are no IANA considerations with this specification. Nothing to register here, bestie 🌸
13 Acknowledgements 🫶
The authors would like to thank Allison Mankin, Rohan Mahy, Joerg Ott, and Flemming Andreasen for their detailed comments. Iconic group of people 👑
14 Normative References 📚
- [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [3] Kumar, R. and M. Mostafa, "Conventions For the Use of The Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001.
- [4] Schulzrinne, H., Casner, S, Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
- [5] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
15 Informative References 🧠
- [6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
- [7] 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.
- [8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
- [9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
- [10] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
16 Authors' Addresses 💌
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu17. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein 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. Thank you, Internet Society, you're the real one 💜
📦 where this page comes from
- ietf: rfc3264 2002-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms