RFC 6337
Session Initiation Protocol (SIP) Usage of the Offer/Answer Model
Session Initiation Protocol (SIP) Usage of the Offer/Answer Model 💖
Okay bestie, here's the title block tea ☕ This is RFC 6337, published in August 2011 by the Internet Engineering Task Force (IETF) 🌸. The authors are S. Okumura (Softfront), T. Sawada (KDDI Corporation), and P. Kyzivat ✨. It's Informational, which means it's a helpful explainer and NOT a Standards Track spec 🦋. Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's just vibing on its own 💅
Abstract ✨
Okay so SIP uses the offer/answer model along with SDP (Session Description Protocol) to set up and update multimedia sessions 🎀. The problem? The rules for this are scattered across a bunch of different RFCs, which is so annoying 🙈. This document pulls every current SIP usage of the offer/answer model into one place so it's easy to understand 🫶
Status of This Memo ✨
This document is NOT an Internet Standards Track specification. It's published just for information 💜
It's a product of the IETF and represents the consensus of the IETF community 🌈 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🧐
Info about this doc's current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6337 🦋
Copyright Notice ✨
Copyright (c) 2011 IETF Trust and the people listed 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, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date 📜 Please actually read these, because they spell out your rights and restrictions for this doc 🙏 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, just like the Simplified BSD License says 💅
Table of Contents 🧚
1. Introduction ....................................................3
2. Summary of SIP Usage of the Offer/Answer Model ..................3
2.1. Terminology ................................................3
2.2. Offer/Answer Exchange Pairs in SIP Messages ................4
2.3. Rejection of an Offer ......................................5
2.4. Session Description That Is Not an Offer or an Answer ......7
3. Detailed Discussion of the Offer/Answer Model for SIP ...........8
3.1. Offer/Answer for the INVITE method with 100rel Extension ...8
3.1.1. INVITE Request with SDP .............................8
3.1.2. INVITE Request without SDP .........................11
3.2. Offer/Answer Exchange in Early Dialog .....................12
3.3. Offer/Answer Exchange in an Established Dialog ............12
3.4. Recovering from a Failed Re-INVITE ........................13
4. Exceptional Case Handling ......................................13
4.1. Message Crossing Case Handling ............................13
4.2. Glare Case Handling .......................................18
4.3. Interworking of UPDATE and Re-INVITE ......................21
5. Content of Offers and Answers ..................................25
5.1. General Principle for Constructing Offers and Answers .....26
5.2. Choice of Media Types and Formats to Include and Exclude ..26
5.2.1. Sending an Initial INVITE with Offer ...............26
5.2.2. Responding with an Offer When the Initial
INVITE Has No Offer ................................27
5.2.3. Answering an Initial INVITE with Offer .............27
5.2.4. Answering When the Initial INVITE Had No Offer .....28
5.2.5. Subsequent Offers and Answers ......................28
5.3. Hold and Resume of Media ..................................29
5.4. Behavior on Receiving SDP with c=0.0.0.0 ..................31
6. Security Considerations ........................................31
7. Acknowledgements ...............................................31
8. References .....................................................32
8.1. Normative References ......................................32
8.2. Informative References ....................................331. Introduction 🌸
Okay so SIP uses the offer/answer model to set up and update sessions 🎀 The rules for how that works are spread across a few RFCs: [RFC3261], [RFC3262], [RFC3264], [RFC3311], and [RFC6141] 📚
The main goal of this doc is to put every form of SIP usage of the offer/answer model in one spot so readers can fully get it 🧠 It also tries to bring in the results of the controversial discussions so people don't have to rehash the same arguments later 🙄
This doc points out ambiguities in the current specs, plus the authors' take on the correct reading of them 👀 It is NOT trying to change those specs. Instead, it's a reference for future standards work on the SIP offer/answer model, and for developers who want advice on implementing things in line with the standards 💖
2. Summary of SIP Usage of the Offer/Answer Model 🦋
The offer/answer model is independent of the higher-layer application protocols that use it 💅 SIP is just one of those applications. [RFC3264] defines the offer/answer model, but it doesn't say which SIP messages should carry an offer or an answer 🤷♀️ That's supposed to be defined in the SIP core and extension RFCs, and yes, that's the whole point of this section 😭
Here's the thing: in theory, any SIP message can have a session description in its body ✨ But a session description in a SIP message is not automatically an offer or an answer 🙅♀️ Only certain session description usages that follow the rules in Standards-Track RFCs can be read as an offer or an answer. Those rules are defined across several RFCs 📖
The offer/answer model also gives you a way to update sessions 🔥 In SIP, a dialog is what links an offer/answer exchange to the session it's supposed to update. In other words, ONLY the offer/answer exchange within the SIP dialog can update the session that dialog manages 👑
2.1. 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] 🫶
Here are the abbreviations this doc uses:
- UA: User Agent.
- UAC: User Agent Client.
- UAS: User Agent Server.
- SDP: Session Description Protocol [RFC4566].
2.2. Offer/Answer Exchange Pairs in SIP Messages 💖
Right now, the offer/answer rules are defined in [RFC3261], [RFC3262], [RFC3264], [RFC3311], and [RFC6141] 📚 Across these RFCs, only the six patterns shown in Table 1 are defined for swapping an offer and an answer inside SIP messages. Pay attention to these, they're the whole game 🎯
Quick note: an offer/answer exchange started by an INVITE request must follow exactly one of Patterns 1, 2, 3, and 4 ⚡ When an initial INVITE causes multiple dialogs because of forking, the offer/answer exchange happens separately in each distinct dialog 🍓 If an INVITE request has no offer, only Pattern 2 or Pattern 4 apply 🙈
Now, Section 13.2.1 of [RFC3261] says 'The first reliable non-failure message' has to carry an offer if the INVITE request didn't have one 😤 So a User Agent (UA) that gets an INVITE with no offer has to include an offer in the first reliable response that uses the 100rel extension 🔥 If no reliable provisional response was sent, the User Agent Server (UAS) must include an offer when it sends the 2xx response 👑
In Pattern 3, the first reliable provisional response may or may not have an answer 🦋 When a reliable provisional response contains a session description and is the first one to do so, that session description is the answer to the offer in the INVITE request ✨ The answer can't be updated, and a new offer can't be sent in a later reliable response for that same INVITE transaction. Not allowed, bestie 🙅♀️
In Pattern 5, a Provisional Response ACKnowledgement (PRACK) request can contain an offer only if the reliable response it acknowledges contains an answer to the previous offer/answer exchange 🧚
NOTE: It is legal to have UPDATE/2xx exchanges without offer/answer exchanges (Pattern 6). However, when re-INVITEs are sent for non-offer/answer purposes, an offer/answer exchange is required. In that case, the prior SDP will typically be repeated. 💅
There may be ONLY ONE offer/answer negotiation in progress for a single dialog at any point in time 🙅♀️ Section 4 explains how to make sure this happens. When an INVITE results in multiple dialogs, each one gets its own separate offer/answer negotiation 🌈
NOTE: This is when using a Content-Disposition of "session". There may be a second offer/answer negotiation in progress using a Content-Disposition of "early-session" [RFC3959]. That is not addressed by this document. 🙈
Here's Table 1, the big summary of patterns:
Offer Answer RFC Ini Est Early
-------------------------------------------------------------------
1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N
2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N
3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N
4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N
5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y
6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y
Table 1: Summary of SIP Usage of the Offer/Answer ModelIn Table 1, '1xx-rel' means the reliable provisional response that has the 100rel option defined in [RFC3262] 🎀
The 'Ini' column is about whether the pattern can be used to exchange the offer/answer and start the session. 'Y' means yes it can, 'N' means no it can't 🌸 Only the initial INVITE transaction can be used to swap offers and answers to establish a multimedia session 🫶
The 'Est' column shows whether the pattern can update an established session ✨
The 'Early' column shows which patterns can be used to change an established session while you're still in an early dialog. There are two ways to exchange a subsequent offer/answer in an early dialog, and that's coming up next 👀💜
2.3. Rejection of an Offer ✨
okay so rejecting an offer is lowkey confusing, bestie 🙈 some methods straight up don't let you say "no thanks" explicitly. For each of the patterns in Table 1, Table 2 shows how to reject an offer.
When a UA gets an INVITE request with an offer it can't accept, it SHOULD respond with a 488 response, ideally with a Warning header field saying why it's being rejected, unless some other response code fits better (Pattern 1 and Pattern 3). 💅
If this is a re-INVITE, you have to be extra careful 😭 (see [RFC6141] for the full tea). If the offer changes or adds media stream properties, and those have already been used to send or receive media before the final response goes out, then a 2xx response SHOULD be sent, with a syntactically correct session description. This MAY optionally be followed by an UPDATE request to rearrange the session parameters, but only if both ends support the UPDATE method. 🫶 Or the UA can send an error response to the (re-)INVITE request to end the dialog or roll back the offer/answer status before sending the re-INVITE request. In that case the UAS SHOULD NOT keep retransmitting the unacknowledged reliable provisional response, and the User Agent Client (UAC) SHOULD NOT keep retransmitting a PRACK request.
When a UA gets an UPDATE request with an offer it can't accept, it SHOULD respond with a 488 response, ideally with a Warning header field giving the reason, unless another response code is more appropriate (Pattern 6). 🎀
When a UA gets a PRACK request with an offer it can't accept, it MAY respond with a 200 response that has a syntactically correct session description. This can optionally be followed by an UPDATE request to rearrange the session parameters, but only if both ends support the UPDATE method. Or the UA can terminate the dialog and send an error response to the INVITE request (Pattern 5). 🦋
Also, the UAC could get a 488 response to a PRACK request, which is giving plot twist 🙈. In that case the UAC MAY send a PRACK request again without an offer, or send a CANCEL request to terminate the INVITE transaction.
NOTE: In [RFC3262], the following restriction is defined with regard to responding to a PRACK request. "If the PRACK does match an unacknowledged reliable provisional response, it MUST be responded to with a 2xx response." This restriction is not clear. There are cases where it is unacceptable to send a 2xx response. For example, the UAS may need to send an authentication challenge in a 401 response. This is an open issue and out of scope for this document.
When a UA gets a response with an offer it can't accept, it has no way to reject it explicitly 😭. So a UA SHOULD respond to the offer with the correct session description and rearrange the session parameters by starting a new offer/answer exchange, or it can just terminate the session (Pattern 2 and Pattern 4). When starting a new offer/answer, a UA SHOULD take care not to cause an infinite offer/answer loop. Yikes, nobody wants that. 💀
Section 14.2 of [RFC3261], "UAS Behavior", says:
The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description.
This is a rule for an offer inside a 2xx response to a re-INVITE. This rule SHOULD be applied to an offer inside a reliable provisional response and a PRACK request too. 🌸
Here's the rejection cheat sheet (Table 2) 🍓:
Offer Rejection
------------------------------------------------------------------
1. INVITE Req. (*) 488 INVITE Response
2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer
OR termination of dialog
3. INVITE Req. 488 INVITE Response (same as Pattern 1)
4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer
5. PRACK Req. (**) 200 PRACK Resp. followed by new offer
OR termination of dialog
6. UPDATE Req. 488 UPDATE Response(*) If this was a re-INVITE, a failure response SHOULD NOT be sent if media has already been exchanged using the new offer.
(**) A UA SHOULD only use PRACK to send an offer when it has strong reasons to expect the receiver will accept the offer.
Table 2: Rejection of an Offer2.4. Session Description That Is Not an Offer or an Answer 🧚
Like I said before, a session description in a SIP message isn't always an offer or an answer 🙈. SIP can use a session description to describe capabilities outside of the offer/answer exchange. Two examples are a 200 OK response to OPTIONS and a 488 response to INVITE. Not every session description is drama, bestie 💜.
3. Detailed Discussion of the Offer/Answer Model for SIP 💖
3.1. Offer/Answer for the INVITE method with 100rel Extension 🌈
The INVITE method gives you the basic offer/answer procedure in SIP. Without the 100rel option, it's simple, as described in [RFC3261]. If an INVITE request includes a session description, Pattern 1 applies. If an INVITE request doesn't include one, Pattern 2 applies.
With 100rel, Patterns 3, 4, and 5 get added, and that makes things way more complicated 😭. An INVITE request can cause multiple responses. And even when both UAs support the 100rel extension, not all the provisional responses have to be sent reliably. 🫠
3.1.1. INVITE Request with SDP 🎀
When a UAC includes an SDP body in the INVITE request as an offer, only the first SDP in a reliable non-failure response to the INVITE request is the real answer. No other offer/answer exchanges can happen within the messages of the INVITE transaction (other responses and ACK). Main character rules only, bestie 👑.
[RFC3261] has some descriptions of an offer/answer exchange, but they're a little confusing 😵💫. We read them like this:
UAC behavior:
- If the first SDP the UAC receives is in an unreliable provisional response to the INVITE request, [RFC3261] (Section 13.2.1, second bullet) requires that it be treated as an answer. But that same section says the answer has to be in a reliable non-failure message, so this SDP is not the true answer, and the offer/answer exchange isn't finished yet.
- After the UAC gets the answer in a reliable provisional response to the INVITE, [RFC3261] requires that any SDP in later responses be ignored.
- If the second and later SDP (including a real answer) is different from the first SDP, the UAC SHOULD consider that the SDP is equal to the first SDP. So the UAC SHOULD NOT switch to the new SDP. 🙅♀️
UAS behavior:
- [RFC3261] requires all SDP in responses to the INVITE request to be identical.
- After the UAS has sent the answer in a reliable provisional response to the INVITE, the UAS SHOULD NOT include any SDPs in later responses to the INVITE.
- [RFC3261] permits the UAS to send any provisional response without SDP, no matter whether the answer has been sent. 💅
A session description in an unreliable response that comes before a reliable response can be treated as a "preview" of the answer that's coming. ✨
NOTE: This "preview" session description rule applies to a single offer/answer exchange. In parallel offer/answer exchanges (caused by forking), a UA may obviously receive a different "preview" of an answer in each dialog. UAs are expected to deal with this.
Even though [RFC3261] says a UA SHOULD accept media once an INVITE with an offer has been sent, in lots of cases an answer (or at least a preview of it) is needed before media gets accepted 😤. Here are two reasons why that might be:
- To avoid receiving media from undesired sources, some User Agents assume symmetric RTP will be used. They ignore all incoming media packets until they receive an address/port from the other end, and then they use that address/port to filter incoming media packets. 🕵️♀️
- In some networks, an intermediate node has to authorize a media stream before it can flow, and it needs a confirming answer to the offer before doing that. 🛂
So a UAS SHOULD send an SDP answer reliably (if possible) before it starts sending media. And if neither the UAC nor the UAS supports 100rel, the UAS SHOULD send a preview of the answer before it starts sending media. 🌸
Here's the diagram 🦋:
UAC UAS
| F1 INVITE (SDP) | <- The offer in the offer/answer model.
|-------------------->|
| F2 1xx (SDP) | <- The offer/answer exchange is not
|<--------------------| closed yet, but UAC acts as if it
| | ^ receives the answer.
| F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer
|<--------------------| | SDP.
| F4 PRACK (no SDP) | |
|-------------------->| | The UAC must not send a new offer.
| F5 2xx PRA (no SDP) | |
|<--------------------| v
| |
| F6 1xx-rel (SDP) | <- The answer in the offer/ answer model.
|<--------------------| -
| F7 PRACK | | The UAC can send a new offer in a PRACK
|-------------------->| | request to acknowledge F6.
| F8 2xx PRA | | After F7, the UAC and UAS can send a new
|<--------------------| v offer in an UPDATE request.
| |
| F9 1xx-rel | <- SDP should not be included in the
|<--------------------| subsequent 1xx-rel once offer/answer
| F10 PRACK | has been completed.
|-------------------->|
| F11 2xx PRA |
|<--------------------|
| |
| F12 2xx INV | <- SDP should not be included in the
|<--------------------| final response once offer/answer has
| F13 ACK | been completed.
|-------------------->| Figure 1: Example of Offer/Answer with 100rel Extension (1)Look at Figure 1 🔍: only the SDP in F6 is the answer. The SDP in the unreliable response (F2) is the preview of the answer, and it MUST be the same as the answer in F6. When the UAC gets F2, it SHOULD act as if it got the answer. But the offer/answer exchange isn't finished yet, so the UAC MUST NOT send a new offer until it gets the same SDP in a reliable non-failure response, which is the real answer. After sending the SDP in F6, the UAS MUST be ready to receive a new offer from the UAC in a PRACK request, or in an UPDATE request if the UAS supports UPDATE. 🫶
The UAS doesn't include SDP in responses F9 and F12. Still, the UAC SHOULD be ready to receive SDP bodies in F9 and/or F12 and just ignore them, in case the peer doesn't follow the recommended implementation. Be nice and tolerant, bestie 🥹💖
3.1.2. INVITE Request without SDP ✨
Okay, so what if the UAC sends an INVITE with no SDP body at all? 🤔 Per [RFC3261] (Section 13.2.1, first bullet), the UAS has to put an offer in the first reliable non-failure response. The catch is that RFC 3261 doesn't really picture the other responses to the INVITE carrying SDP, so a UAC might not be expecting it. That's why the UAS ought not include any SDP in the other responses to the INVITE request. Bestie, keep it clean! 🧼
NOTE: In Figure 2, the UAS should not include SDP in the responses F6 and F9. However, the UAC should prepare to receive SDP bodies in F6 and/or F9, and just ignore them to handle a peer that does not conform to the recommended implementation.
Here's the whole flow in ASCII art, bestie 🎀
UAC UAS
| F1 INVITE (no SDP) |
|-------------------->|
| F2 1xx |
|<--------------------|
| |
| F3 1xx-rel (SDP) | <- The first 1xx-rel must contain SDP
|<--------------------| as the offer.
| F4 PRACK (SDP) | <- A PRACK request to the first 1xx-rel
|-------------------->| must contain SDP as the answer.
| F5 2xx PRA (no SDP) | -
|<--------------------| |
| | |
| F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not
|<--------------------| | contain SDP.
| F7 PRACK | |
|-------------------->| | The UAC can send a new offer in an UPDATE
| F8 2xx PRA | | request after F4.
|<--------------------| v
| |
| F9 2xx INV (no SDP) | <- The final response should not
|<--------------------| contain SDP.
| F10 ACK |
|-------------------->|
Figure 2: Example of Offer/Answer with 100rel Extension (2)Now, a little heads-up 🚨 If the UAC has to ask the user whether to accept or reject the offer, a reliable provisional response carrying SDP as an offer (Pattern 4) can keep getting retransmitted until the PRACK can go out. So the UAC should take care to avoid that situation when it sends the INVITE without SDP. Don't let your retransmits go wild, babe 💅
3.2. Offer/Answer Exchange in Early Dialog
Here's the vibe: when both UAs support the 100rel extension, they can update the session in the early dialog once the first offer/answer exchange is done. Main character energy 👑
From a UA sending an INVITE request:
A UA can send an UPDATE request with a new offer if both ends support the UPDATE method. Just a heads-up: if the UAS needs to prompt the user to accept or reject the offer, that delay can cause the UPDATE request to be retransmitted. ⏳
A UA can send a PRACK request with a new offer only when it's acknowledging the reliable provisional response that carries the answer to an offer in the INVITE request. Compared to UPDATE, PRACK can cut down the number of messages exchanged between the UAs, which is lowkey iconic 🦋 But, to avoid problems or delays caused by PRACK offer rejection, the UA is recommended to send a PRACK request only when it has strong reasons to expect the receiver will accept it. For example, the procedure used in precondition extension [RFC3312] is a case where a PRACK request should be used for updating the session status in an early dialog. Also, if a UAS needs to prompt the user to accept or reject the offer, the delay can cause the PRACK request to be retransmitted. 🫶
From a UA receiving an INVITE request:
A UA can send an UPDATE request with a new offer if both ends support the UPDATE method. Here's the tea ☕ A UAS cannot send a new offer in the reliable provisional response, so the UPDATE method is the only method a UAS can use to update an early session. Iykyk 🌸
3.3. Offer/Answer Exchange in an Established Dialog
Both the re-INVITE and UPDATE methods can be used in an established dialog to update the session. Pick your fighter! 🥊
The UPDATE method is simpler and can save at least one message compared with the INVITE method. But, and this is a big but 💀, both ends must support the UPDATE method for it to be used.
The INVITE method needs at least three messages to complete, but no extensions are needed. It also lets the peer take time to decide whether or not it will accept a session update by sending provisional responses. So re-INVITE lets the UAS interact with the user at the peer, while UPDATE needs to be answered automatically by the UAS. It's noted that re-INVITE should be answered immediately unless that kind of user interaction is needed. Otherwise, some Third Party Call Control (3PCC) [RFC3725] flows will break. Bestie, please don't break 3PCC 😭
3.4. Recovering from a Failed Re-INVITE
Okay, so Section 14.1 of [RFC3261] requires that the session parameters in effect before a re-INVITE stay unchanged if the re-INVITE fails, as if no re-INVITE had ever been sent. This still holds even if multiple offer/answer exchanges happened between sending the re-INVITE and its failure, and even if media has already flowed using the proposed changes. Because that can be really hard to pull off in practice 🙃, a newer specification [RFC6141] recommends that the UAS send a 2xx response to a re-INVITE in cases where rolling back changes would be problematic.
Still, a UAC may get a failure response to a re-INVITE after proposed changes that need rolling back have already been used. In that case, the UAC should send an UPDATE offering the SDP that has been reinstated. (See [RFC6141] for details.) Reinstate with confidence, queen 👸
4. Exceptional Case Handling ✨
So, [RFC3264] sets out the following restrictions on sending a new offer 📜
At any time, either agent MAY generate a new offer that updates the session. However, it MUST NOT generate a new offer if it has received an offer which it has not yet answered or rejected. Furthermore, it MUST NOT generate a new offer if it has generated a prior offer for which it has not yet received an answer or a rejection.
Assuming those rules are guaranteed, there seem to be two possible 'exceptional' cases to think about in SIP offer/answer usage: the 'message crossing' case and the 'glare' case. 🌀 One reason the use of SIP methods to exchange offer/answer has to be carefully restricted in the RFCs is so the UA can detect and handle these exceptional cases properly and avoid incompatible behavior. Safety first, bestie 🫶💜
4.1. Message Crossing Case Handling ✨
okay so bestie, picture this 🦋 messages are packets zipping through the transport network, and sometimes two of them pass each other mid-flight. Here, an offer can show up before the answer to the previous offer/answer exchange. Totally chaotic, I know 😭 In that case, UA A must detect that the session description SDP-2 is not the answer to offer1. Plot twist, right? 💅
A B
|SDP-1 (offer1)|
M1 |----------------->|
|SDP-2 (answer1)|
M2 |<------\ /-------|
| \/ |
|SDP-3 /\(offer2)|
M3 |<------/ \-------|
Figure 3: Message Crossing CaseOkay, so there are restrictions on where offers and answers can go (we summarized those in Table 1 🎀), which means only a small handful of message exchanges can actually lead to this crossing mess. They're all listed in Table 3 🌸. (That table only shows the messages that carry offers or answers. Other messages without session descriptions exist too, they're just not shown, bestie 🙈)
Now, when a response to an UPDATE request crosses a reliable response to an INVITE request, we get the variants in Figures 4 and 5. These depend on an INVITE (Mx) that has no offer in it. They're in Table 3 too, obviously 💖
A B
| |
|UPDATE(offer1) |
M1 |==============================>|
|re-INVITE(no offer) |
Mx |------------------------------>| --+
| 2xx-UPD(answer1)| |
M2 |<===========\ /===============| | first reliable
| \/ 1xx-rel/2xx-INV| | response
| /\ (offer2)| |
M3 |<===========/ \===============| <-+
|PRACK/ACK(answer2) |
My |------------------------------>|
| |
Figure 4: Avoidable Message Crossing CasesTo dodge the crossing shown in Figure 4, UA A should not send this re-INVITE request until an UPDATE transaction has been completed. And if UA B runs into this crossing anyway, it should reject this re-INVITE request with a 500 response. Keep it moving, girl 🏃♀️💨
A B
| |
|re-INVITE(no offer) |
Mx |------------------------------>| --+
|UPDATE(offer1) | |
M1 |==============================>| |
| 2xx-UPD(answer1)| |
M2 |<===========\ /===============| | first reliable
| \/ 1xx-rel/2xx-INV| | response
| /\ (offer2)| |
M3 |<===========/ \===============| <-+
|PRACK/ACK(answer2) |
My |------------------------------>|
| |
Figure 5: Avoidable Message Crossing CasesFor Figure 5, the fix is that UA A should not send this UPDATE request until an ACK or a PRACK transaction associated with an offer/answer has been completed. If UA B hits this crossing, it should reject the UPDATE request with a 500 response 🫶
Next up: when a PRACK request crosses an UPDATE request, which is Figure 6 🧚
A B
| |
| re-INVITE (no offer)|
1st reliable+-- |<------------------------------|
response | M1|1xx-rel(offer1) |
+-> |==============================>| --+
| PRACK(answer1)| M3| Acknowledge
|<===========\ /===============| <-+
| \/ |
| /\ UPDATE(offer2)|
|<===========/ \===============| M2
|500-UPD |
|------------------------------>|
|2xx-PRA |
|------------------------------>|
| |
Figure 6: Avoidable Message Crossing CasesTo avoid the crossing in Figure 6, UA B should not send this UPDATE request until a PRACK transaction associated with an offer/answer has been completed. If UA A runs into this crossing, it should reject this UPDATE request with a 500 response. Bestie, the rules are so specific it's giving legal documents 💀
Then there's a reliable provisional response to an INVITE crossing an UPDATE, shown in Figure 7 🌈
A B
| |
|re-INVITE(offer1) |
M1 |==============================>|
| 1xx-rel(answer1)|
|<===========\ /===============| M3
| \/ |
| /\ UPDATE(offer2)|
+-- |<===========/ \===============| M2
| |491-UPD |
Acknowledge | |------------------------------>|
| |PRACK |
+-> |------------------------------>|
| |
Figure 7: Avoidable Message Crossing CasesFor Figure 7, UA B should not send this UPDATE request until a PRACK transaction associated with an offer/answer has been completed. If UA A encounters this crossing, it should reject this UPDATE request with a 491 response. Different code, same vibe 😌
Last one is a 2xx response to an INVITE crossing an UPDATE, which is Figure 8. This is a true glare 😭🔥
A B
| |
|re-INVITE(offer1) |
|==============================>|
| 2xx-INV(answer1)|
|<===========\ /===============|
| \/ |
| /\ UPDATE(offer2)|
+-- |<===========/ \===============|
| |491-UPD |
Acknowledge | |------------------------------>|
| |ACK |
+-> |------------------------------>|
| |
Figure 8: Avoidable Message Crossing CasesTo avoid the crossing in Figure 8, UA B should not send the UPDATE request until it has received an ACK request. But honestly, there's no problem even if UA B sends it anyway 🙌 If UA A encounters this crossing, it should reject this UPDATE request with a 491 response.
And finally, a response to an UPDATE request crossing a PRACK request, shown in Figure 9 🍓
A B
| |
| re-INVITE(offer0)|
|<------------------------------|
|1xx-rel(answer0) |
|------------------------------>| --+
|UPDATE(offer1) | |
M1 |==============================>| |
| 2xx-UPD(answer1)| | Acknowledge
|<===========\ /===============| M3|
| \/ | |
| /\ PRACK(offer2)| M2|
|<===========/ \===============| <-+
| |
Figure 9: Avoidable Message Crossing CaseTo avoid the crossing in Figure 9, UA A should not send this UPDATE request until a PRACK transaction associated with an offer/answer has been completed. If UA B encounters this crossing, it should reject this UPDATE request with a 491 response.
Okay, so Table 3 wraps up this whole section 🎀 Each action is described in Section 4.3, so don't worry, we're getting there 💜
| M1 | M3 | M2 |Action |Action |Figure|
|(offer1)|(answer1) |(offer2) | of A | of B | |
+--------+----------+-----------+-------+-------+------+
| UPDATE | 2xx-UPD | UPDATE |UAS-UcU| | |
| | +-----------+-------+ - | |
| | | INVITE |UAS-UcI| | |
| | +-----------+-------+-------+------+
| | | 1xx-INV | | | |
| | +-----------+UAC-UI,|UAS-UsI| 4,5 |
| | | 2xx-INV |UAC-IU |UAS-IsU| |
| | +-----------+-------+-------+------+
| | | PRACK (*)|UAC-IU |UAS-IcU| 9 |
+--------+----------+-----------+-------+-------+------+
| PRACK | 2xx-PRA | UPDATE |UAS-IcU| | |
+--------+----------+-----------+-------+ | |
| 2xx-INV| ACK | UPDATE |UAS-IsU| - | |
| | +-----------+-------+ | |
| | | INVITE |UAS-IsI| | |
+--------+----------+-----------+-------+-------+------+
| 1xx-rel| PRACK | UPDATE |UAS-IsU| | 6 |
+--------+----------+-----------+-------+UAC-IU +------+
| INVITE | 1xx-rel | UPDATE (*)| | | 7 |
| +----------+-----------+UAS-IcU+-------+------+
| | 2xx-INV | UPDATE (*)| | - | 8 |
+--------+----------+-----------+-------+-------+------+
(*) invalid sequences if INVITE request is an initial one
Table 3: Offer/Answer Crossing Message Sequences4.2. Glare Case Handling ✨
okay so, glare is when BOTH ends in a dialog send a brand new offer at nearly the same time 😭 like they're texting each other at the exact same second. 🫶 Look at Figure 10. Because of that, a UA can get a new offer before it gets the answer to the offer it already sent. This is usually called a 'glare' case, and it's giving chaos 💀🔥
A B
|offer1 offer2|
M1 |-------\ /-------| M2
| \/ |
| /\ |
|<------/ \------>|
Figure 10: Glare Caseso when offer2 shows up in an UPDATE request or a (re-)INVITE request, it must be rejected with a 491 or 500 response. no exceptions, bestie 🙅♀️💖
There's a variant of Figure 7 where offer2 is in a PRACK request 🎀 (under the current rules, that's only possible if offer1 is in an UPDATE request). Check out Figure 11. UA A is in a whole dilemma here 😩
A B
| |
| re-INVITE(offer0)|
|<------------------------------|
|1xx-rel(answer0) |
|------------------------------>| --+
|UPDATE(offer1) PRACK(offer2)| M2| Acknowledge
M1 |============\ /===============| <-+
| \/ |
| /\ |
|<===========/ \==============>|
| 491-UPD|
|<------------------------------|
| |
Figure 11: Avoidable Glare Casengl the problem is that every PRACK is supposed to get a 200 response, but there's literally no way to say "hey, something's wrong" with a 200 🙈 The best it can do is go ahead assuming the UPDATE gets rejected with a 491. To dodge the glare in Figure 11, UA A should not send this UPDATE request until a PRACK transaction tied to an offer/answer has been completed 🌸 And if UA B runs into this glare, it should reject this UPDATE request with a 491 response. 💅
Glare can also happen when offer2 is in a 1xx or 2xx response. This one is a variant of Figure 5, shown in Figure 12 ✨
A B
| |
|re-INVITE(no offer) |
|------------------------------>| --+
| 1xx-rel/2xx-INV| | 1st reliable
|UPDATE(offer1) (offer2)| M2| response
M1 |============\ /===============| <-+
| \/ |
| /\ |
|<===========/ \==============>|
| 500-UPD|
|<------------------------------|
| |
Figure 12: Avoidable Glare Caseto avoid the glare in Figure 12, UA A should not send this UPDATE request until an ACK or a PRACK transaction tied to an offer/answer has been completed 🧚 If UA B hits this glare, it should reject this UPDATE request with a 500 response. 🦋
And there's a variant of Figure 4, shown in Figure 13 🍓
A B
| |
|UPDATE(offer1) |
|==========\ |
|re-INVITE \ (no offer) |
|------------\----------------->| --+
| \ 1xx-rel/2xx-INV| | 1st reliable
| \ (offer2)| | response
|<==============\===============| <-+
| \ |
| \============>|
| 500-UPD|
|<------------------------------|
| |
Figure 13: Avoidable Glare Caseso to avoid the glare in Figure 13, UA A should not send this re-INVITE request until an UPDATE transaction has been completed. And if UA B encounters this glare, it should reject this UPDATE request with a 500 response. 💜
Table 4 is the cheat sheet for this whole section 🌈 Each action is explained in Section 4.3.
| offer1 | offer2 |Action |Action |Figure|
| M1 | M2 | of A | of B | |
+-----------+-----------+-------+-------+------+
| | re-INVITE |UAS-IcI|UAS-IcI| |
| re-INVITE +-----------+-------+-------+ |
| | UPDATE |UAS-IcU|UAS-UcI| |
+-----------+-----------+-------+-------+ |
| | UPDATE |UAS-UcU|UAS-UcU| |
| +-----------+-------+-------+------+
| | 1xx-rel | | | |
| UPDATE +-----------+UAC-IU,|UAS-IsU|12,13 |
| | 2xx-INV |UAC-UI | | |
| +-----------+-------+-------+------+
| | PRACK (*) |UAC-IU |UAS-IcU| 11 |
+-----------+-----------+-------+-------+------+
(*) invalid sequences if INVITE request is an initial one
Table 4: Offer/Answer Glare Message Sequences4.3. Interworking of UPDATE and Re-INVITE 💌
Okay bestie, almost every exceptional case comes down to UPDATE and re-INVITE crossing paths 🙈. How they interwork is described in Section 5 of [RFC3311], and the UAC behavior for sending an UPDATE is in Section 5.1 of [RFC3311]. There are two concerns here ✨:
- It seems to lay out different rules for the initial INVITE and for re-INVITE. But there's no real reason they have to be separate. The lack of restrictions on sending a re-INVITE request causes a lot of the problems in Section 4.1. 💀
- It seems to say a UA may send an UPDATE request after sending or receiving a PRACK request. But it should be "after PRACK transaction is completed by 2xx response," because otherwise you get the message-crossing case in Figure 6. 🫶
Since the language in this section is non-normative and is justified as a corollary of [RFC3261], we read it like this 💅:
UAC-II: While an INVITE transaction is incomplete or ACK transaction associated with an offer/answer is incomplete, a UA must not send another INVITE request. 🚫UAC-UU: While an UPDATE transaction is incomplete, a UA must not send another UPDATE request.UAC-UI: While an UPDATE transaction is incomplete, a UA should not send a re-INVITE request.UAC-IU: While an INVITE transaction is incomplete, and an ACK or a PRACK transaction associated with an offer/answer is incomplete, a UA should not send an UPDATE request.
When a 2xx response to an INVITE includes an offer, the ACK transaction is considered to be associated with an offer/answer. 🎀
When a reliable provisional response to an INVITE includes an offer or an answer, the PRACK transaction is considered to be associated with an offer/answer. 🦋
UAS behavior for receiving an UPDATE is described in Section 5.2 of [RFC3311]. There are two concerns in this section 👀:
- There is no description of the interworking of an UPDATE request and an INVITE request without an offer.
- There is no description of the interworking of an UPDATE request and a reliable response to an INVITE with an offer.
We read this section like so 🌸:
UAS-IcI: While an INVITE client transaction is incomplete or ACK transaction associated with an offer/answer is incomplete, a UA must reject another INVITE request with a 491 response.UAS-IsI: While an INVITE server transaction is incomplete or ACK transaction associated with an offer/answer is incomplete, a UA must reject another INVITE request with a 500 response.UAS-UcU: While an UPDATE client transaction is incomplete, a UA must reject another UPDATE request with a 491 response.UAS-UsU: While an UPDATE server transaction is incomplete, a UA must reject another UPDATE request with a 500 response.UAS-UcI: While an UPDATE client transaction is incomplete, a UA should reject a re-INVITE request with a 491 response.UAS-UsI: While an UPDATE server transaction is incomplete, a UA should reject a re-INVITE request with a 500 response.UAS-IcU: While an INVITE client transaction is incomplete, and an ACK or a PRACK transaction associated with an offer/answer is incomplete, a UA should reject an UPDATE request with a 491 response.UAS-IsU: While an INVITE server transaction is incomplete, and an ACK or a PRACK transaction associated with an offer/answer is incomplete, a UA should reject an UPDATE request with a 500 response.
Here are the rules in action, in the diagrams 🧚:
A B
| |
| UPDATE|
|<------------------------------|
|UPDATE |
|==============================>|
| 491|
|<==============================|
| |Figure 14: Example of UAC-UU and UAS-UcU
A B
| |
|UPDATE CSeq:m |
|------------------------------>|
|UPDATE CSeq:n(>m) |
|==============================>|
| 500 (UPDATE CSeq:n)|
|<==============================|
| |Figure 15: Example of UAC-UU and UAS-UsU
A B
| |
| UPDATE(offer1)|
|<------------------------------|
|reINVITE(no offer) |
|==============================>|
| 491 (INVITE)|
|<==============================|
| |Figure 16: Example of UAC-UI and UAS-UcI
A B
| |
|UPDATE(offer1) |
|------------------------------>|
|reINVITE(no offer) |
|==============================>|
| 500 (INVITE)|
|<==============================|
| |Figure 17: Example of UAC-UU and UAS-UsI
A B
| |
| reINVITE(no offer)|
|<------------------------------|
|1xx-rel(offer0) |
|------------------------------>|
|UPDATE(offer1) |
|==============================>|
| 491 (UPDATE)|
|<==============================|
| |Figure 18: Example of UAC-IU and UAS-IcU
A B
| |
|reINVITE(no offer) |
|------------------------------>|
| 1xx-rel(offer0)|
|<------------------------------|
|UPDATE(offer1) |
|==============================>|
| 500 (UPDATE)|
|<==============================|
| |Figure 19: Example of UAC-IU and UAS-IsU
Also, the UPDATE request in this section is assumed to include an offer. Interworking of a re-INVITE and an UPDATE without an offer is out of scope for this document. 🚧
5. Content of Offers and Answers 🍓
While [RFC3264] and [RFC3312] give some guidance, there are still open questions about exactly what should go into an offer or answer. It gets especially messy when the common "hold" feature is turned on, and when a multimedia call is possible. 📞
How things behave depends on the capabilities and state of the User Agent 🤖. The kinds of recommendations we can make are limited by the model of device capabilities and state that is assumed to exist.
This section zooms in on a few key aspects of offers and answers that have been flagged as troublesome, and treats everything else as out of scope. This section covers:
- choice of supported media types and formats to include and exclude
- hold and resume of media
These are out of scope for this document:
- NAT traversal and Interactive Connectivity Establishment (ICE)
- specific codecs and their parameters
- the negotiation of secure media streams
- grouping of media streams
- preconditions
5.1. General Principle for Constructing Offers and Answers 🌈
A UA should send an offer that indicates what it, and its user, are interested in using or doing at that time, without regard for what the other party in the call may have indicated previously. This still applies when the offer is sent in response to an INVITE or re-INVITE that contains no offer. (However, in the case of re-INVITE, the constraints of [RFC3261] and [RFC3264] must be observed. ⚠️)
A UA should send an answer that includes as close an approximation as possible to what the UA and its user are interested in doing at that time, while staying consistent with the offer/answer rules of [RFC3264] and other RFCs. ✨
NOTE: "at that time" is important. The device may let the user configure which supported media are used by default. 💖
Sometimes a UA doesn't directly know what it's interested in doing at a particular time. If it's an intermediary, it may be able to delegate the decision 🫶. In the worst case, it may apply a default, such as assuming it wants to use all of its capabilities.
5.2. Choice of Media Types and Formats to Include and Exclude 🎶
5.2.1. Sending an Initial INVITE with Offer 🦋
When a UAC sends an initial INVITE with an offer, it has complete freedom to choose which media type(s) and media format(s) (payload types in the case of RTP) it should include in the offer. 👑
The media types may be all or a subset of the media the UAC is capable of supporting. The particular subset is determined by the design and configuration of the UAC (e.g., via [RFC6080]) combined with input from the UAC's user interface. ⭐
The media formats may be all or a subset of the media formats the UAC is capable of supporting for the corresponding media type. The particular subset is determined by the design and configuration of the UAC combined with input from the UAC's user interface. 🌸
Including all supported media formats will maximize the chance that the other party has a supported format in common. But including too many can result in an unacceptably large SDP body. 😭
5.2.2. Responding with an Offer When the Initial INVITE Has No Offer ✨
okay bestie, when a UAS gets an initial INVITE with no offer in it, it MUST pop an offer into the first reliable response to that INVITE 💅. It's basically the same vibe as sending an initial INVITE with an offer, but there are some lowkey differences 🦋. The choice might be governed by static (default) media picks AND dynamic picks the user makes by poking at the device while it's alerting 📱.
📝 NOTE: The offer may be sent in a reliable provisional response, before the user of the device has been alerted and has had a chance to pick media options for the call 🎧. So the UAS can't include any call-specific options from the user of the device 🙈. If there's a chance the user will want to change what's offered before answering, then special care SHOULD be taken 💅. If PRACK and UPDATE are supported by both caller and callee, then an initial offer can be sent reliably and changed with an UPDATE if the user wants a change ✨. If PRACK and UPDATE are not supported, then the initial offer cannot be changed until the call is fully established 😭. In that case, the offer in a 200 response for the initial INVITE SHOULD include only the media types and formats believed to be acceptable to the user 🌸.
5.2.3. Answering an Initial INVITE with Offer 💖
when a UAS receives an initial INVITE with an offer, what media lines the answer may contain is locked in by [RFC3264] 🔒. The answer MUST contain the same number of "m=" lines as the offer, and they MUST contain the same media types 👯. Each media line MAY be accepted by including a non-zero port number, or rejected by including a zero port number in the answer 🎀. The media lines that are accepted SHOULD typically be the ones with types and formats the UAS would have included if it were the offerer 🧚.
The media formats the answer may contain are also constrained by [RFC3264] 💜. For each accepted "m=" line in the answer, there MUST be at least one media format in common with the matching "m=" line of the offer 🫶. The UAS MAY also include other media formats it is able to support at this time. Doing so sets up an asymmetric media format situation, where these "other" media formats may only be sent from the offerer to the answerer 🌈. This asymmetric media situation is also limited, because it cannot be sustained if there's a subsequent offer/answer exchange in the opposite direction 🙃. Also, there's limited value in including these other media formats, because there's no assurance the offerer will be able to use them 😬.
If the UAS doesn't want to indicate support for any of the media types in a particular media line of the offer, it MUST reject that media line by setting the port number to zero 🚫.
When the UAS wants to reject all of the media lines in the offer, it MAY send a 488 failure response 💀. Alternatively, it MAY send a reliable non-failure response that includes all media lines with port numbers set to zero 🍓.
5.2.4. Answering When the Initial INVITE Had No Offer 🌷
When a UAC has sent an initial INVITE without an offer, and then gets a response with the first offer, it SHOULD answer the same way a UAS would when receiving an initial INVITE with an offer 🦢.
Because the offer arrives in a response to the INVITE, the UAC can't reject the message containing the offer 🙊. If the UAC wants to reject the entire offer, it MUST send a PRACK or ACK request that includes all the media lines with ports set to zero 🧾. Then, if it doesn't want to continue the session, it MAY send a CANCEL or BYE request to terminate the dialog 👋.
5.2.5. Subsequent Offers and Answers 🔁
The guidelines above (Sections 5.1 and 5.2.1 through Section 5.2.4) apply, but the constraints in [RFC3264] MUST also be followed 📜. These are of particular note because they've proven troublesome 😭:
- The number of
"m="lines MUST NOT be reduced in a subsequent offer. Previously rejected media streams MUST remain, or be reused to offer the same or a different stream. (Section 6 of [RFC3264].) 🙅♀️ - In the
"o="line, only the version number MAY change, and if it changes, it MUST increment by one from the one previously sent as an offer or answer. (Section 8 of [RFC3264].) If it doesn't change, then the entire SDP body MUST be identical to what was previously sent as an offer or answer. Changing the"o="line, except for the version number value, during the session is an error case. The behavior when receiving such a non-compliant offer/answer SDP body is implementation dependent. If a UA needs to negotiate a 'new' SDP session, it SHOULD use the INVITE/Replaces method. 🫠 - In the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream (
"m="line) MUST NOT change for the duration of the session. (Section 8.3.2 of [RFC3264].) 🎧
📝 NOTE: This may be impossible for a back-to-back user agent (B2BUA) to follow in some cases (e.g., 3PCC transfer) if it does not terminate media 🧐.
When the new offer is sent in response to an offerless (re-)INVITE, it SHOULD be constructed according to the General Principle for Constructing Offers and Answers (Section 5.1): all codecs the UA is currently willing and able to use SHOULD be included, not just the ones negotiated by previous offer/answer exchanges 🎶. The same goes for media types. So if UA A initially offered audio and video to UA B, and they ended up with only audio, and UA B sends an offerless (re-)INVITE to UA A, A's resulting offer SHOULD most likely re-attempt video, by reusing the zeroed "m=" line used previously 🎥✨.
📝 NOTE: The behavior above is RECOMMENDED, but it isn't always achievable, for example in some interworking scenarios. Or, the offerer may simply not have enough resources to offer "everything" at that point. Even if the UAS isn't able to offer any SDP other than the one currently in use, it SHOULD NOT reject the re-INVITE. Instead, it SHOULD generate an offer with the currently used SDP, with the "o=" line unchanged 🫶.
5.3. Hold and Resume of Media ⏸️
[RFC3264] specifies (using non-normative language) that "hold" should be indicated in an established session by sending a new offer containing "a=sendonly" for each media stream to be held 🎵. An answerer is then to respond with "a=recvonly" to acknowledge that the hold request has been understood 👌.
Note that sendonly/recvonly isn't only for hold 💅. These may be used for other reasons, such as devices that are only capable of sending or receiving 📡. So receiving an offer with "a=sendonly" MUST NOT be treated as a sure sign that the offerer has put the media stream on hold 🙈.
This model assumes the UA initiating the hold will want to play Music on Hold, which isn't always the case 🎶. A UA MAY, if it wants, initiate hold by offering "a=inactive" if it doesn't intend to transmit any media while on hold ⏹️.
The rules of [RFC3264] constrain what may be in an answer when the offer contains "sendonly", "recvonly", or "inactive" in an "a=" line 📏. But they do not constrain what MUST be in a subsequent offer. The General Principle for Constructing Offers and Answers (Section 5.1) is important here 🧠. Starting a "hold" is a local action. It SHOULD reflect the desired state of the UA, and then it affects what the UA includes in offers and answers until the local state is reset 🔄.
Receiving an offer containing "a=sendonly" or "a=inactive", and sending a compatible answer, SHOULD NOT change the desired state of the recipient 🙅♀️. However, a UA that has been "placed on hold" MAY itself desire to start its own hold status, based on local input 🦋.
If UA2 has previously been "placed on hold" by UA1, via receipt of "a=sendonly", then it MAY start its own hold by sending a new offer containing "a=sendonly" to UA1 🙌. When UA1 gets that, it will answer with "a=inactive", because that's the only valid answer that reflects its desire not to receive media 🧊.
📝 NOTE: Section 8.4 of [RFC3264] contains a conflicting recommendation that the offer contain"a=inactive"in this case. We interpret that recommendation to be non-normative. Using"a=sendonly"in this case will never produce a worse outcome, and it can produce a better outcome in useful cases 💜.
Once in this state, to resume a two-way exchange of media, each side MUST reset its local hold status 🤝. If UA1 is first to come off hold, it will then send an offer with "a=sendrecv" 🌞. UA2 will respond with its desired state of "a=sendonly", because that's a permitted response 🙆♀️. When UA2 wants to resume too, it will send an offer with "a=sendrecv". In this case, since UA1 has the same desire, it will respond with "a=sendrecv" 💖. Also, when UA2 receives the offer with "a=sendrecv", if it has decided it wants to reset its local hold but hasn't signaled that intent yet, it MAY send "a=sendrecv" in the answer 🎀.
If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive", and later wants to start its own hold, also using "a=inactive", it need not send a new offer 🛋️. That's because the only valid response is "a=inactive", and that's already in effect ✨. However, its local desired state will now be either "inactive" or "a=sendonly", and that affects what it sends in future offers and answers 🔮.
If a UA has a reason to send another offer in the session without any desire to change the hold status (e.g., in response to a re-INVITE without an offer, or when sending a re-INVITE to refresh the session timer), it SHOULD follow the General Principle for Constructing Offers and Answers (Section 5.1) 🧩. If it previously started a "hold" by sending "a=sendonly" or "a=inactive", then it SHOULD offer that again 🔁. If it had not previously started "hold", then it SHOULD offer "a=sendrecv", even if it had previously been forced to answer something else 🌈. Without this behavior, it's possible to get "stuck on hold" in some cases, especially when a 3pcc is involved 😭.
5.4. Behavior on Receiving SDP with c=0.0.0.0 🚦
[RFC3264] requires that an agent 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 🙅.
If a UA generates an answer to an offer received with "c=IN IP4 0.0.0.0", the direction attribute of the accepted media stream in the answer MUST still be based on the direction attribute of the offered stream, and on the rules specified in [RFC3264] for forming the direction "a=" line in the answer 🧭. There's no clear rule about using "c=IN IP4 0.0.0.0" in the answer. It MAY be used, or a "c=" line with a valid IP address MAY be used instead 🌸. RTP/RTCP will not be sent toward an address of 0.0.0.0, because it is an invalid address 🚫💀.
6. Security Considerations ✨
okay so bestie, this section is basically saying: this doc is just cleaning up confusing bits of how two SIP User Agents work together in a dialog 💅 The main rules live in [RFC3261] and [RFC3264], with extra stuff in [RFC3311], [RFC3312], and [RFC6141]. The whole focus here is on the cases where the confusion leads to failed or messed up calls when there's no attacker around 🫶 These clarifications don't make any previously invalid call flows legit, periodt. So the security considerations of those docs still apply and nobody needs to stretch them to cover new stuff 🔒
Now the attacker part, which is giving main character drama 😭 An attacker can totally mess up the offer/answer exchange in lots of ways. SIP has ways to protect that exchange from third parties tampering with it, and the big one to know about is "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474], plus Section 26.3.2, "Security Solutions", of [RFC3261] 🛡️💜
7. Acknowledgements 🎀
the authors gave a huge shoutout to Christer Holmberg, Rajeev Seth, Nataraju A B, Byron Campen, Jonathan Rosenberg, Gonzalo Camarillo, and Gao Yang for their thorough reviews and comments 🙈 A bunch of their suggestions and ideas made it into this doc, iconic behavior from the whole crew 👑
8. References 📚
8.1. Normative References 🌸
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC6141] Camarillo, G., Holmberg, C., and Y. Gao, "Re-INVITE and
Target-Refresh Request Handling in the Session Initiation
Protocol (SIP)", RFC 6141, March 2011.8.2. Informative References 💖
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004.
[RFC3959] Camarillo, G., "The Early Session Disposition Type for the
Session Initiation Protocol (SIP)", RFC 3959,
December 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery",
RFC 6080, March 2011.Authors' Addresses 🧚
OKUMURA Shinji
Softfront
28-196, Noth9, West15, Chuo-ku
Sapporo, Hokkaido 060-0009
Japan
EMail: shinji.okumura@softfront.jp
Takuya Sawada
KDDI Corporation
3-10-10, Iidabashi, Chiyoda-ku
Tokyo
Japan
EMail: tu-sawada@kddi.com
Paul H. Kyzivat
Hudson, MA 01749
USA
EMail: pkyzivat@alum.mit.eduThat's the whole doc, bestie! 🌈 You made it through all 8 parts, and honestly the offer/answer cleanup is so iconic 🦋✨
📦 where this page comes from
- ietf: rfc6337 2011-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms