RFC 3312
Integration of Resource Management and Session Initiation Protocol (SIP)
RFC 3312 🎀 (Part 1 of 7)
Okay bestie, this is RFC 3312, Integration of Resource Management and Session Initiation Protocol (SIP) 💖. It's a Standards Track doc from October 2002, so it's a real spec, not just vibes 💅. The authors are G. Camarillo (Ed.) at Ericsson, W. Marshall (Ed.) at AT&T, and J. Rosenberg at dynamicsoft. It's from the Network Working Group, and the copyright belongs to the Internet Society (2002) ✨. The title block doesn't list any Obsoletes or Updates entries, so this one isn't replacing or updating anything named there 🌸.
Status of This Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's asking people for discussion and suggestions for improvements 🫶. For the current 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 doc defines a generic framework for preconditions, and they're extensible through IANA registration. It also talks about how network quality of service can be made a precondition for establishing sessions started by the Session Initiation Protocol (SIP) 🔥. These preconditions make the participant reserve network resources before the session continues. We do not define new quality of service reservation mechanisms here, though. The preconditions just make a participant use existing resource reservation mechanisms before the session begins ✨.
Table of Contents 🧚
1 Introduction ................................................... 2
2 Terminology .................................................... 3
3 Overview ....................................................... 3
4 SDP parameters ................................................. 4
5 Usage of preconditions with offer/answer ....................... 7
5.1 Generating an offer .......................................... 8
5.1.1 SDP encoding ............................................... 9
5.2 Generating an Answer ......................................... 10
6 Suspending and Resuming Session Establishment .................. 11
7 Status Confirmation ............................................ 12
8 Refusing an offer .............................................. 13
8.1 Rejecting a Media Stream ..................................... 14
9 Unknown Precondition Type ...................................... 15
10 Multiple Preconditions per Media Stream ....................... 15
11 Option Tag for Preconditions .................................. 16
12 Indicating Capabilities ....................................... 16
13 Examples ...................................................... 16
13.1 End-to-end Status Type ...................................... 17
13.2 Segmented Status Type ....................................... 21
13.3 Offer in a SIP response ..................................... 23
14 Security Considerations ....................................... 26
15 IANA Considerations ........................................... 26
16 Notice Regarding Intellectual Property Rights ................. 27
17 References .................................................... 27
18 Contributors .................................................. 28
19 Acknowledgments ............................................... 28
20 Authors' Addresses ............................................ 29
21 Full Copyright Statement ...................................... 301. Introduction 🦋
Some architectures need the chances of a session establishment failure to be minimal once the callee has been alerted, and that's a big deal 😭. One source of failure is not being able to reserve network resources for a session. To minimize "ghost rings," the network resources have to be reserved for the session before the callee gets alerted. The catch is that reserving resources usually means learning the IP address, port, and session parameters from the callee. That info only comes from the initial offer/answer exchange carried in SIP, and that exchange normally makes the "phone ring" 💀. So it's a total chicken-and-egg problem: you can't reserve resources without doing the initial offer/answer exchange, and you can't do that exchange without reserving resources 🙈.
The fix is the concept of a precondition 💅. A precondition is a set of constraints about the session that get introduced in the offer. The recipient of the offer generates an answer, but doesn't alert the user or otherwise move forward with session establishment. That only happens once the preconditions are met. You can find out they're met through a local event (like a confirmation of a resource reservation), or through a new offer sent by the caller ✨.
This document deals with sessions that use SIP [1] as the signalling protocol and SDP [2] to describe the session's parameters 🎀.
We put the quality of service preconditions in the SDP description instead of the SIP header, because preconditions are stream specific 🌸.
2. Terminology 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3] 📖.
3. Overview 🧚
Okay so to make sure session establishment doesn't happen until certain preconditions are met, we split a particular media stream into two different state variables: current status and desired status 🔥. This document defines the quality of service status.
The desired status is a threshold for the current status. Session establishment stops until the current status reaches or surpasses that threshold. Once it does, session establishment resumes 💜.
For example, these values for current and desired status would not let session establishment resume:
current status = resources reserved in the send direction
desired status = resources reserved in both (sendrecv) directionsBut the values below would make session establishment resume:
current status = resources reserved in both (sendrecv) directions
desired status = resources reserved in the send directionThese two state variables describe a piece of state for a media stream, the same way the direction attribute or the codecs in use describe other pieces of state 🦋. So we treat these two new variables like any other SDP media attributes in the offer/answer model used by SIP [4]: they get exchanged between two user agents using an offer and an answer, so both sides have a shared view of the session's status 🫶.
Figure 1 shows a typical message exchange between two SIP user agents using preconditions ✨. A includes quality of service preconditions in the SDP of the initial INVITE. A doesn't want B to alert the callee until there are network resources reserved in both directions (sendrecv) end-to-end 😭. B agrees to reserve network resources for this session before alerting the callee. B will handle resource reservation in the B->A direction, but it needs A to handle the A->B direction. To say so, B returns a 183 (Session Progress) response to A, asking A to start resource reservation and to confirm to B as soon as the A->B direction is ready for the session 💅. A and B both start resource reservation. B finishes reserving resources in the B->A direction, but it doesn't alert the user yet, because it needs network resources in both directions 🙈. When A finishes reserving resources in the A->B direction, it sends an UPDATE [5] to B. B returns a 200 (OK) response to the UPDATE, which says all the preconditions for the session have been met 🎀. Only then does B start alerting the user, and session establishment completes normally 🌈.
to be continued 🧚 (part 2 of 7 next!)
4 SDP parameters ✨
okay so this section is where the new SDP attributes get their official grammar 🎀 we're defining three media level attributes: current-status, desired-status, and confirm-status. here's the full ABNF, copied exactly:
current-status = "a=curr:" precondition-type
SP status-type SP direction-tag
desired-status = "a=des:" precondition-type
SP strength-tag SP status-type
SP direction-tag
confirm-status = "a=conf:" precondition-type
SP status-type SP direction-tag
precondition-type = "qos" | token
strength-tag = ("mandatory" | "optional" | "none"
= | "failure" | "unknown")
status-type = ("e2e" | "local" | "remote")
direction-tag = ("none" | "send" | "recv" | "sendrecv")Now the vibes for each piece 💅
Current status: this one carries the current status of network resources for a particular media stream. it's giving "here's where things are right now" 🦋
Desired status: this is the preconditions for a media stream. here's the key bit 🔑 when the direction-tag of the current status, for a given precondition-type and status-type on a stream, is equal to (or better than) the direction-tag of the desired status with the same precondition-type and status-type on that stream, then the preconditions are considered to be met for that stream. main character energy when things line up ✨
Confirmation status: this carries threshold conditions for a media stream. once the status of network resources reaches those conditions, the peer user agent sends an update of the session description with an updated current status attribute for that stream. it's like a little "ping me when it's ready" 🫶
Precondition type: this document defines quality of service preconditions. extensions are allowed to define other types of preconditions 🌈
Strength tag: this one tells you whether or not the callee can be alerted if the network fails to meet the preconditions. lowkey the drama of the whole thing 😭
Status type: there are two types here, end-to-end and segmented 🧚 the end-to-end status reflects the status of the end-to-end reservation of resources, and it's tagged "e2e". the segmented status reflects the status of the access network reservations of both user agents, and it's tagged "local" and "remote". end-to-end is useful when end-to-end resource reservation mechanisms are available. segmented is useful when one or both UAs do resource reservations on their own access networks. both options are valid, it just depends on the setup 💜
Here's the basic flow diagram, copied exactly:
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
Figure 1: Basic session establishment using preconditionsDirection tag: this indicates the direction in which a particular attribute (current, desired or confirmation status) applies 🎀
The values of the tags "send", "recv", "local" and "remote" are from the point of view of the entity that generates the SDP description. in an offer, "send" is the direction offerer->answerer, and "local" is the offerer's access network. in an answer, "send" is the direction answerer->offerer, and "local" is the answerer's access network. so the perspective flips depending on who's talking 🙈
Here's an example showing these new SDP attributes in two media lines of one session description:
m=audio 20000 RTP/AVP 0
a=curr:qos e2e send
a=des:qos optional e2e send
a=des:qos mandatory e2e recv
m=audio 20002 RTP/AVP 0
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos mandatory remote sendrecv5 Usage of preconditions with offer/answer
okay bestie, this is where we figure out how the offer/answer model from [4] handles all those new attributes 🦋 parameter negotiation in SIP runs on offer/answer. the whole point is that once the offerer receives the answer, both user agents have a shared view of the session parameters. this section explains which values the new SDP attributes can take in an answer, depending on what they were in the offer 💖
so the model has three tables. both user agents keep a local status table, and each offer/answer exchange gets its own transaction status table. the offerer makes a transaction status table identical to its local status table and sends it in the offer. the answerer uses that info to update its own local status table. it also fixes up any transaction status fields that were out of date and sends the table back in the answer. the offerer then updates its local status table with what came back. after that exchange, both local status tables are synchronised, so both sides have a common view of the media stream's status 🤝 sessions with several media streams keep these tables per media stream.
one important thing 🚨 this is a model of user agent behavior, not of software. an implementation can take any approach it wants, as long as it reproduces the external behavior this model defines 💅
5.1 Generating an offer
okay so both user agents MUST maintain a local precondition status, which is called a "local status table". Tables 1 and 2 show the format of these tables for the end-to-end and segmented status types. for the end-to-end status type, the table has two rows, one for each direction (send and recv). a value of "yes" in the "Current" field means the resource was successfully reserved in that direction, and "No" means resources haven't been reserved yet. the "Desired Strength" field shows how strong the preconditions are in that direction. the table for the segmented status type has four rows: both directions in the local access network and both directions in the peer's access network. the meaning of the fields is the same as in the end-to-end case 🌸
before generating an offer, the offerer MUST build a transaction status table with the current and desired status for each media stream. the different values of the strength-tag for the desired status attribute mean this:
- None: no resource reservation is needed.
- Optional: the user agents SHOULD try to provide resource reservation, but the session can continue whether or not that's possible.
- Mandatory: the user agents MUST provide resource reservation. otherwise, session establishment MUST NOT continue. 😭
then the offerer decides whether it's using the end-to-end status type or the segmented status type 👑 if the status type of the media line is end-to-end, the user agent generates records with the desired status and the current status for each direction (send and recv) on its own, like Table 1:
Direction Current Desired Strength
____________________________________
send no mandatory
recv no mandatory
Table 1: Table for the end-to-end status typeif the status type is segmented, the user agent generates records with the desired status and the current status for each direction (send and recv) and each segment (local and remote) on its own, like Table 2:
Direction Current Desired Strength
______________________________________
local send no none
local recv no none
remote send no optional
remote recv no none
Table 2: Table for the segmented status typeat the time the offer gets sent, the offerer's local status table and the transaction status table contain the same values 🎀
last bit for this part: using the transaction status table, the user agent MUST generate the current-status and desired status lines, following the syntax of Section 4 and the rules described below in Section 5.1.1 💖
5.1.1. SDP encoding
okay so for the end-to-end status type 💖, the user agent MUST generate one current status line with the tag e2e for the media stream. if the strength-tags for both directions are equal (like both "mandatory") in the transaction status table, the user agent MUST add one desired status line with the tag sendrecv. but if both tags are different, it MUST include two desired status lines, one with the tag send and the other with the tag recv. ✨
the semantics of two lines with the same strength-tag, one with a "send" tag and the other with a "recv" tag, is the same as one "sendrecv" line. however, to get a more compact encoding, we chose to make the latter format mandatory 🫶
for the segmented status type 🦋, the user agent MUST generate two current status lines: one with the tag local and the other with the tag remote. the user agent MUST add one or two desired status lines per segment (i.e., local and remote). if, for a particular segment (local or remote), the tags for both directions in the transaction status table are equal (e.g., both "mandatory"), the user agent MUST add one desired status line with the tag sendrecv. if both tags are different, the user agent MUST include two desired status lines, one with the tag send and the other with the tag recv. 💅
note that the rules above apply to the desired strength-tag none as well 👀. this way, a user agent that supports quality of service but does not intend to use them adds desired status lines with the strength-tag none. since this tag can be upgraded in the answer, as described in Section 5.2, the answerer can request quality of service reservation without a need of another offer/answer exchange. main character energy 👑
the example below shows the SDP corresponding to tables 1 and 2 🌸
m=audio 20000 RTP/AVP 0
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
m=audio 20002 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos optional remote send
a=des:qos none remote recv
a=des:qos none local sendrecv5.2. Generating an Answer
when the answerer receives the offer, it recreates the transaction status table using the SDP attributes contained in the offer 📨. then it updates both its local status and the transaction status table following the rules below:
- Desired Strength: we define an absolute ordering for the strength-tags: "none", "optional" and "mandatory". "mandatory" is the tag with the highest grade and "none" the tag with the lowest grade. an answerer MAY upgrade the desired strength in any entry of the transaction status table, but it MUST NOT downgrade it. so it's OK to upgrade a row from "none" to "optional", from "none" to "mandatory", or from "optional" to "mandatory", but not the other way around 🔥
- Current Status: for every row, the value of the "Current" field in the transaction status table and in the local status table of the answerer have to be compared. Table 3 shows the four possible combinations. if both fields have the same value (the two first rows of table 3), nothing needs to be updated. if the "Current" field of the transaction status table is "Yes" and the field of the local status table is "No" (the third row of table 3), the latter MUST be set to "Yes". if the "Current" field of the transaction status table is "No" and the field of the local status table is "Yes" (the fourth row of table 3), the answerer needs to check if it has local information (e.g., a confirmation of a resource reservation has been received) about that particular current status. if it does, the "Current" field of the transaction status table is set to "Yes". if the answerer does not have local information about that current status, the "Current" field of the local status table MUST be set to "No" 🧚
Transac. status table Local status table New values transac./local
____________________________________________________________________
no no no/no
yes yes yes/yes
yes no yes/yes
no yes depends on local info
Table 3: Possible values for the "Current" fieldsonce both tables have been updated, an answer MUST be generated following the rules described in Section 5.1.1, taking into account that "send", "recv", "local" and "remote" tags have to be inverted in the answer, as shown in table 4 🔄
Offer Answer
______________
send recv
recv send
local remote
remote local
Table 4: Values of tags in offers and answersat the time the answer is sent, the transaction status table and the answerer's local status table contain the same values 🫧. therefore, this answer contains the shared view of the status of the media line in the current-status attribute and the negotiated strength and direction-tags in the desired-status attribute.
if the resource reservation mechanism used requires participation of both user agents, the answerer SHOULD start resource reservation after having sent the answer, and the offerer SHOULD start resource reservation as soon as the answer is received. if participation of the peer user agent is not needed (e.g., segmented status type), the offerer MAY start resource reservation before sending the offer and the answerer MAY start it before sending the answer 🚀
the status of the resource reservation of a media line can change between two consecutive offer/answer exchanges. therefore, both user agents MUST keep their local status tables up to date, using local information throughout the duration of the session 🕰️
6. Suspending and Resuming Session Establishment 🌙
a user agent server that receives an offer with preconditions SHOULD NOT alert the user until all the mandatory preconditions are met. session establishment is suspended until that moment (e.g., a PSTN gateway reserves resources without sending signalling to the PSTN) 📞. a user agent server may receive an INVITE request with no offer in it. in this case, following normal procedures defined in [1] and [5], the user agent server will provide an offer in a reliable 1xx response. the user agent client will send the answer in another SIP request (i.e., the PRACK for the 1xx). if the offer and the answer contain preconditions, the user agent server SHOULD NOT alert the user until all the mandatory preconditions in the answer are met 🙈
note that in this case, a user agent server providing an initial offer with preconditions will never send a 180 (Ringing) response with preconditions, since the user agent server cannot alert the user until all the preconditions are met.
a UAS that is not capable of unilaterally meeting all of the mandatory preconditions MUST include a confirm-status attribute in the SDP (offer or answer) that it sends (see Section 7). further, the SDP (offer or answer) that contains this confirm-status attribute MUST be sent as soon as allowed by the SIP offer/answer rules 📝
while session establishment is suspended, user agents SHOULD not send any data over any media stream. in the case of RTP [6], neither RTP nor RTCP packets are sent 🤐
a user agent server knows that all the preconditions are met for a media line when its local status table has a value of "yes" in all the rows whose strength-tag is "mandatory". when the preconditions of all the media lines of the session are met, session establishment SHOULD resume ✅
for an initial INVITE, suspending and resuming session establishment is very intuitive. the callee will not be alerted until all the mandatory preconditions are met. however, offers containing preconditions sent in the middle of an ongoing session need further explanation. both user agents SHOULD continue using the old session parameters until all the mandatory preconditions are met. at that moment, the user agents can begin using the new session parameters. Section 13 contains an example of this situation 🎬
7. Status Confirmation ✨
the confirm-status attribute MAY be used in both offers and answers 💌. this attribute represents a threshold for the resource reservation. when this threshold is reached or surpassed, the user agent MUST send an offer to the peer user agent, reflecting the new current status of the media line, as soon as allowed by the SIP offer/answer rules. if this threshold is crossed again (e.g., the network stops providing resources for the media stream), the user agent MUST send a new offer as well, as soon as allowed by the SIP offer/answer rules 📉
if a peer has requested confirmation on a particular stream, an agent MUST mark that stream with a flag in its local status table. when all the rows with this flag have a "Current" value of "yes", the user agent MUST send a new offer to the peer. this offer will contain the current status of resource reservation in the current-status attributes. later, if any of the rows with this flag transition to "No", a new offer MUST be sent as well 🚩
confirmation attributes are not negotiated. the answerer uses the value of the confirm-status attribute in the offer, and the offerer uses the value of this attribute in the answer 🤝
for example, if a user agent receives an SDP description with the following attributes:
m=audio 20002 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecvit will send an offer as soon as it reserves resources in its access network ("remote" tag in the received message) for both directions (sendrecv) 🎀
8 Refusing an offer ✨
okay bestie, this is where we learn how to say "nope" politely 💅 We define a new SIP status code:
Server-Error = "580" ;Precondition FailureWhen a UAS, acting as an answerer, can't meet the preconditions in the offer, or just isn't willing to, it SHOULD reject the offer by returning a 580 (Precondition-Failure) response 🙈
Using 580 (Precondition Failure) to refuse an offer works when the offer shows up in an INVITE or an UPDATE request. ngl, SIP doesn't give us a way to refuse offers that arrive in a response (1xx or 2xx) to an INVITE 😭 So if a UAC sends an initial INVITE without an offer and then gets an offer in a 1xx or 2xx response that isn't acceptable, it SHOULD answer it with a correctly formed answer and then immediately send a CANCEL or a BYE. it's giving "I'll play along, then leave" 💖
If the offer comes in a 1xx or 2xx response to a re-INVITE, A has no way to reject it without ending the session at the same time 💀 Same advice from Section 15.2 of [1] applies here:
"The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to A, A SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session."
580 (Precondition Failure) responses, plus BYE and CANCEL requests that signal a failure to meet certain preconditions, SHOULD include an SDP description that says which desired status caused the failure 🎀 This SDP is not an offer or an answer, because it won't lead to a session being set up. Its format is based on the last SDP (an offer or an answer) received from the remote UA.
For every "m=" line in the last SDP description received, there MUST be a matching "m=" line in the SDP that signals the failure. This SDP MUST have exactly the same number of "m=" lines as the last SDP received. The port number on every "m=" line MUST be set to zero, but the connection address can be anything 🦋
The desired status line for the precondition that caused the failure MUST use the "failure" strength-tag, like this:
m=audio 20000 RTP/AVP 0
a=des:qos failure e2e send8.1 Rejecting a Media Stream
In the offer/answer model, when an answerer wants to reject a media stream, it sets the port to zero 🌸 Preconditions don't change that. Streams still get rejected by setting their port to zero, no exceptions.
Both the offerer and the answerer MUST ignore all the preconditions that affect a stream with its port set to zero. Those preconditions don't count when deciding whether session establishment can move forward 🧚
9 Unknown Precondition Type ⭐
This document defines the "qos" tag for quality of service preconditions. New precondition-types defined later will get their own tags 🌈 A UA that gets an unknown precondition-type with a "mandatory" strength-tag in an offer MUST refuse the offer, unless the only unknown mandatory preconditions have the "local" tag. In that case, the UA doesn't need to be involved to meet the preconditions. It will ask for confirmation of the preconditions, and once that confirmation arrives, it resumes session establishment 👑
A UA refusing an offer follows the rules in Section 8, but instead of the "failure" tag, it uses the "unknown" tag, like this:
m=audio 20000 RTP/AVP 0
a=des:foo unknown e2e send10 Multiple Preconditions per Media Stream 🦋
A media stream MAY have multiple preconditions. Different preconditions MAY share the same precondition-type but have different status-types (like end to end and segmented quality of service preconditions), or they MAY have different precondition-types (this document only defines the "qos" precondition type, but extensions may add more later) 💜
All the preconditions for a media stream MUST be met before session establishment can resume. Here's an example session description using both end-to-end and segmented status-types for one media stream 🍓
m=audio 20000 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=curr:qos e2e none
a=des:qos optional e2e sendrecv11 Option Tag for Preconditions 🔥
We define the option tag "precondition" for use in the Require and Supported header fields. An offerer MUST include this tag in the Require header field if the offer has one or more "mandatory" strength-tags. If all the strength-tags in the description are "optional" or "none", the offerer MUST include this tag in either a Supported header field or a Require header field. It is, however, RECOMMENDED to use the Supported header field in this case 🫶 Without preconditions in the answer, the offerer can tell the answerer didn't support this extension.
Offers and answers get mapped to SIP requests and responses by following the rules in [5]. So a user agent that includes preconditions in its SDP MUST support the PRACK and UPDATE methods. That means it MUST include the "100rel" [7] tag in its Supported header field, and it SHOULD include an Allow header field with the "UPDATE" tag [5] ✨
12 Indicating Capabilities 🌈
The offer/answer model [4] describes the format of a session description for indicating capabilities. This format is also used in responses to OPTIONS requests. A UA that supports preconditions SHOULD add desired status lines that list the precondition-types it supports for each media stream. These lines MUST have the "none" strength-tag, like in this example 💅
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=des:foo none e2e sendrecv
a=des:qos none local sendrecvHeads up: when this document was published, the precondition-type "foo" hadn't been registered yet. It's only in the session description above to show multiple precondition-types in one example 🙈
A UA that supports this framework SHOULD add a "precondition" tag to the Supported header field of its responses to OPTIONS requests 🎀
13 Examples 🧚
The following examples cover both status types; end-to-end and segmented.
13.1. End-to-end Status Type ✨
okay so Figure 2 is the basic session establishment using the end-to-end status type, and it's giving clean, simple vibes. here are the SDP descriptions for it 💅
SDP1: A puts end-to-end quality of service preconditions in the initial offer 🎀
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecvSDP2: B uses RSVP, so it can tell when resources in its "send" direction are ready, because it gets RESV messages from the network 🌸 but it has no idea what's going on with the reservations in the other direction. so B asks for confirmation of its "recv" reservations from the peer user agent A, and it puts that request in its answer 🫶
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recvonce B has sent the answer, it starts reserving network resources for the media stream 🔥 when A gets that answer (2), A starts its own reservation too. since both UAs use RSVP, A sends PATH messages towards B, and B sends PATH messages towards A 🦋
as time passes, B gets RESV messages confirming its reservation ✨ but B waits until the resources in the other direction are reserved too, because it hasn't received any confirmation yet and the preconditions still aren't met 🙈
SDP3: once A gets its RESV messages, it sends an updated offer (5) to B 💜
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecvSDP4: B answers (6) with the current status of the resource reservation (that's "sendrecv") 👑
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecvand now session establishment picks back up, and B sends a 180 (Ringing) response (7) 💖
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |Figure 2: Example using the end-to-end status type
okay now let's say that in the middle of the session, A wants to change the IP address where it receives media 🦋 Figure 3 shows how that goes ✨
SDP1: A puts an offer in a re-INVITE (1) 💅 it keeps receiving media on the old IP address (192.0.2.1), but it's ready to receive on the new one too (192.0.2.2) 🌈
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecvSDP2: B adds a "conf" attribute to its answer 🎀 and it keeps sending media to the old remote IP address (192.0.2.1) 🥺
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recvSDP3: once A gets its RESV messages, it sends an updated offer (5) to B 💜
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecvSDP4: B answers (6), saying the preconditions have been met (current status "sendrecv). this is the moment B starts sending media to the new remote IP address (192.0.2.2) 🧚
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-----------(7) 200 OK (INVITE)-------------|
| |
|------------------(8) ACK------------------>|
| |
| |Figure 3: Session modification with preconditions
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv13.2. Segmented Status Type 🌷
the call flow in Figure 4 shows a basic session establishment using the segmented status type 💖 here are the SDP descriptions for it 🫧
SDP1: A puts local and remote QoS preconditions in the initial offer 🎀 before sending it, A reserves resources in its access network 🔥 that's shown in the local current status of the SDP below:
m=audio 20000 RTP/AVP 0 8
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecvSDP2: B reserves resources in its access network, and since all the preconditions are met, it sends back an answer inside a 180 (Ringing) response (3) ✨
m=audio 30000 RTP/AVP 0 8
c=IN IP4 192.0.2.4
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecvokay so, after getting this response, A decides it only wants PCM u-law (payload 0), not both PCM u-law and A-law (payload 8) 🙈 it sends an UPDATE to B, maybe before the 200 (OK) for the INVITE shows up (5) 💅 the SDP looks like this:
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecvB makes an answer for this offer and puts it in the 200 (OK) for the UPDATE 🦋
ngl this is the tricky part 😭 the offer/answer that cuts down the supported codecs might reach the user agent server after the 200 (OK) response has already been generated. that means the session gets established before A has actually reduced its codecs 💀 to avoid that, the user agent client could wait for the first answer from the user agent before it sets its local current status to "sendrecv" 🫶
13.3 Offer in a SIP response ✨
okay so this one is about an initial offer that shows up in a reliable 1xx response 🎀 Figure 5 is the call flow, and it's giving end-to-end status type energy. Here are the SDP descriptions:
The first INVITE (1) has no session description, so B is the one who sends the initial offer, inside a reliable 183 (Session Progress) response 🦋
SDP1 is B's offer 💜 B includes end-to-end quality of service preconditions. Since B uses RSVP, B can tell when its "send" direction is ready, because the RESV messages come rolling in from the network. The other direction, though? B has no clue yet 🙈 So B asks for confirmation of the resource reservations in its "recv" direction, sent to the peer user agent A, in its answer.
m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv a=conf:qos e2e recv
SDP2 is A's answer, tucked into the PRACK for that 183 (Session Progress) response 🌸
m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv
A B
| *** |
| *R* |
| *E* |
| *S* |
| *E* |
| *R* |
| *V* |
| *A* |
| *T* |
| *I* |
| *O* |
| *N* |
| *** |
|-------------(1) INVITE SDP1--------------->|
| *** |
| *R* |
| *E* |
| *S* |
| *E* |
| *R* |
| *V* |
| *A* |
| *T* |
| *I* |
| *O* |
| *N* |
| *** |
|<----------(2) 180 Ringing SDP2-------------|
| |
|----------------(3) PRACK------------------>|
| |
|<-----------(4) 200 OK (PRACK)--------------|
| |
| |
|<-----------(5) 200 OK (INVITE)-------------|
| |
|------------------(6) ACK------------------>|
| |
| |Figure 4: Example using the segmented status type
A B
| |
|----------------(1) INVITE----------------->|
| |
|<------(2) 183 Session Progress SDP1--------|
| |
|---------------(3) PRACK SDP2-------------->|
| *** *** |
|<-*R*--------(4) 200 OK (PRACK)-------*R*---|
| *E* *E* |
| *S* *S* |
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
|-------------(5) UPDATE SDP3----------***-->|
| *** |
|<--------(6) 200 OK (UPDATE) SDP4-----***---|
| *** |
| *** |
| *** |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |Figure 5: Example of an initial offer in a 1xx response
Once A sends that answer, A starts reserving network resources for the media stream 🚀 When B gets the answer (3), B starts its own resource reservation too. Both UAs are on RSVP, so A sends PATH messages towards B and B sends PATH messages towards A ✨
SDP3 is the moment A gets RESV messages back. A sends an updated offer (5) to B 💅
m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=curr:qos e2e send a=des:qos mandatory e2e sendrecv
SDP4 is B's reply, an answer (6) that shows the current status of the resource reservation (i.e., recv) 🧚
m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=curr:qos e2e recv a=des:qos mandatory e2e sendrecv
As time passes, B gets RESV messages confirming the reservation 👑 At that point, session establishment resumes and B returns a 180 (Ringing) response (7) 🔥
14 Security Considerations
Heads up, this part is serious 😭
An entity sitting in the middle of two user agents that are establishing a session could add desired-status attributes that make session establishment impossible 💀 It could also tamper with the current-status parameters so the session gets established even though the preconditions were never met. Integrity protection can be used to avoid these attacks 🔒
Another big one: an entity that makes resource reservations as soon as it gets unauthenticated requests carrying preconditions is an easy target for a denial of service attack 🚨 Requests with preconditions SHOULD be authenticated 🫶
15 IANA Considerations
This document defines three media level SDP attributes: desired-status, current-status and conf-status. Their format is defined in Section 4 🌈
This document defines a framework for using preconditions with SIP ✨ Precondition-types to be used with this framework are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication.
- Name of the precondition-type. The name MAY be of any length, but SHOULD be no more than ten characters long.
- Descriptive text that describes the extension.
The only entry in the registry for the time being is 🎀
Pecondition-Type Reference Description
---------------- --------- -----------
qos RFC 3312 Quality of Service preconditionsThis document also defines a new SIP status code (580). Its default reason phrase (Precondition Failure) is defined in section 8 💖
This document defines a SIP option tag (precondition) in section 11 🦋
16 Notice Regarding Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, consult the online list of claimed rights.
17 References
[1] 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.
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method," RFC 3311, September 2002.
[6] Schulzrinne, S., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[8] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K. Ramakrishnan, "DOSA: an architecture for providing robust IP telephony service," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (Tel Aviv, Israel), Mar. 2000.
18. Contributors ✨
okay so the people who helped write the earlier versions of this spec are giving main character energy 💅🎀. K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon), Glenn Russell (CableLabs), Burcak Beser (Pacific Broadband Communications), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen (Cisco), Michael Ramalho (Cisco), John Pickens (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks), Doc Evans (D. R. Evans Consulting), Keith Kelly (NetSpeak), Adam Roach (dynamicsoft), Dean Willis (dynamicsoft), Steve Donovan (dynamicsoft), and Henning Schulzrinne (Columbia University) all co-wrote earlier drafts 🫶🌈.
This "manyfolks" document is literally the result of over two years of teamwork from loads of people. Most of them are listed here and in the acknowledgements below 🦋. A special shout-out goes to Flemming Andreasen, Burcak Beser, Dave Boardman, Bill Guckel, Chuck Kalmanek, Keith Kelly, Poornima Lalwaney, John Lawser, Bill Marshall, Mike Mannette, Dave Oran, K.K. Ramakrishnan, Michael Ramalho, Adam Roach, Jonathan Rosenberg, and Henning Schulzrinne 👑. They spearheaded the initial "single INVITE" quality of service preconditions work, which came out of older, non-SIP compatible "two-stage Invite" proposals 🔥. Those "two-stage INVITE" proposals started out in Distributed Call Signaling work in PacketCable. That work, in turn, had architectural elements from AT&T's Distributed Open Systems Architecture (DOSA) work [8] 🧚.
19. Acknowledgments 🌸
The Distributed Call Signaling work in the PacketCable project was done by a huge crowd from lots of different companies 💜. The authors want to give a big thank you to the following folks for helping out: John Wheeler (Motorola); David Boardman and Daniel Paul (Arris Interactive); Bill Blum, Jay Strater, Jeff Ollis, Clive Holborow (General Instruments); Doug Newlin, Guido Schuster, Ikhlaq Sidhu (3Com); Jiri Matousek (Bay Networks); Farzi Khazai (Nortel); John Chapman, Bill Guckel (Cisco); Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra (AT&T); Telcordia Technologies; and Lucent Cable Communications 🦋✨.
Miguel Angel Garcia-Martin, Rohan Mahy and Mark Watson gave helpful comments and suggestions too, so they get a big heart 🫶💖.
20. Authors' Addresses 💌
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
EMail: Gonzalo.Camarillo@ericsson.com
Bill Marshall AT&T Florham Park, NJ 07932 USA
EMail: wtm@research.att.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA
EMail: jdrosen@dynamicsoft.com
21. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved. 🌈
This document and translations of it may be copied and given to others, and derivative works that comment on or otherwise explain it or help with its implementation may be made, copied, published and distributed, in whole or in part, without restriction of any kind. That's only true if 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. The exception is when it's needed for developing Internet standards, in which case the Internet Standards process copyright procedures must be followed. Translating it into languages other than English is also allowed 🌸.
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 in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and 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 🎀.
📦 where this page comes from
- ietf: rfc3312 2002-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms