RFC 4411
Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events
Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events 💖
- RFC number: 4411
- Series: Network Working Group
- Author: J. Polk, Cisco Systems 👑
- Category: Standards Track 🦋
- Date: February 2006 📅
- Obsoletes / Updates: none listed in the header ✨
Status of This Memo 📜
Okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🗣️. If you want to know where this protocol sits on the standardization ladder, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📖. And the best part: distribution of this memo is unlimited 🌈.
Copyright Notice 🎀
Copyright (C) The Internet Society (2006).
Abstract 🌸
This doc proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header 💅. The header is meant to go inside a BYE Method Request when a session gets preempted, either at a user agent (UA) or somewhere in the network involving a reservation-based protocol like the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS) 🔥. It does not try to handle routers failing in the packet path 🙅♀️. Instead, it's all about a deliberate tear down of a flow between UAs, and it tells the terminated UA(s) what happened 🫶.
Table of Contents ✨
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. Access Preemption Events ........................................4
2.1. Effects of Preemption at the User Agent ....................6
2.2. Reason Header Requirements for Access Preemption Events ....6
3. Network Preemption Events .......................................7
3.1. Reason Header Requirements for Network Preemption Events ..10
4. Including a Hybrid Infrastructure ..............................10
4.1. Hybrid Infrastructure Requirements ........................11
5. Preemption Reason Header Cause Codes and Semantics .............11
5.1. Access Preemption Event Reason Code .......................12
5.1.1. Access Preemption Event Call Flow ..................12
5.2. Network Preemption Events Reason Code .....................14
5.2.1. Network Preemption Event Call Flow .................15
5.3. Generic Preemption Event Reason Code ......................16
5.4. Non-IP Preemption Event Reason Code .......................16
5.4.1. Non-IP Preemption Event Call Flow ..................17
6. Security Considerations ........................................17
7. IANA Considerations ............................................17
7.1. "Preemption" Namespace Registry ...........................18
7.2. Default Reason-Text IANA Registry for the SIP
Reason Header .............................................20
8. Contributions ..................................................20
9. Acknowledgements ...............................................20
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................211. Introduction 🧚
Okay, so once the SIP Resource-Priority (R-P) header [4] showed up, sessions could get torn down for scarce-resource reasons 😭. That means there just weren't enough resources for a particular session to keep going. Some domains are going to use this where resources get squeezed, either at the user agent (UA) or at congested router interfaces, so the more important sessions can finish at the expense of the less important ones 💅. Which sessions count as more important? Not discussed here, bestie 🙈. What this doc proposes is a SIP [2] extension to get SIP elements on the same page about why a preemption event happened and which type of preemption event it was, as seen by the element that did the preempting 🦋.
The SIP Reason Header is an application layer feedback mechanism that keeps SIP elements in sync about events 🔁. The event explained here is preemption of a session. Q.850 [5] gives an indication for preemption (cause=8) and for preemption "circuit reserved for reuse" (cause=9). But Q.850 Cause=9 doesn't apply to IP, because IP has no concept of circuits 🙅♀️. Some domains want to tell apart the right IP reasons for preempting sessions, and they want to say topologically where the preemption happened 🗺️. Nothing else exists today to explain why a session got torn down on preemption grounds, so yeah, this is the gap 💖.
If a session gets terminated for a specific reason that can (or should) be shared with SIP Servers and UAs sharing the dialog, the Reason Header [1] was created to be included in the BYE Request 📨. That wasn't the only method for this new header, though. [1] also discusses the CANCEL Method usage 🙌.
This document defines two use cases where new preemption Reason values are necessary:
- Access Preemption Event: This is when a UA receives a new SIP session request message with a valid R-P value that's higher than the one tied to the currently active session at that UA. The UA must discontinue the existing session in order to accept the new one (according to local policy of some domains) 🚪.
- Network Preemption Event: This is when a network element, such as a router, reaches capacity on a particular interface and has the ability to statefully choose which session(s) will remain active when a new session/reservation is signaled for under the parameters outlined in SIP Preconditions per [3]. That new session would otherwise overload that interface and perhaps adversely affect all sessions 😱. In this case, the router must terminate one or more reservations of lower priority so this higher priority reservation gets access to the requested amount of bandwidth (according to local policy of some domains) 🔥.
This document covers the semantics for these two cases and requests IANA registration of the new protocol value "Preemption" for the Reason Header field, with 4 cause values for the above preemption conditions 🎀. It also creates a new IANA Registry for reason-text strings that aren't currently defined through existing SIP Response codes or Q.850 cause codes. This new Registry will be useful for future protocols that use the SIP Reason header 📚.
This document uses an existing SIP RFC [3] as the starting point for network preemption events. RFC 3312 set the rules for SIP interaction with a reservation protocol for QoS preconditions, using RSVP as the example protocol 🌟. That effort didn't block other preconditions or future protocol work from becoming a means of preconditions. NSIS is a newer reservation protocol effort that specifies a preemption operation similar to RSVP's ResvErr message. It involves the NSIS NOTIFY message in [8] with a Transient error code 0x04000005 (Resources Pre-empted) 🧾.
Note that SIP itself does not cause RSVP or NSIS reservation signaling to start or end. That operation is part of a separate API within each UA 🔌.
1.1. Conventions Used in This Document 💅
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 [6] 🫶.
Part 1 of 5 done, bestie! 💜 Next up: Section 2, Access Preemption Events 🦋
2. Access Preemption Events ✨
okay so, Access Preemption Events (APE) happen at the user agent 🦋 It does not matter which UA in a unicast or multicast session it is (the UAC or UAS of a session). If local policy in a domain sets rules for how a UA works, there has to be a way for that UA (not the user) to tell the other UA(s) why a session just got cut off early. The right tool for that is the BYE Method 💅 Without some way of telling the UA what happened (if this was on purpose), the user on the far side has no clue why the call just "went away" 😭 With this kind of indication sent to the preempted UA, it can show the user what's going on, properly.
The rules in a domain about the UA being informed can be different from the rules for informing the user. Local policy should decide whether the user gets told the specific reason 🎀 This SIP indication gives the UA a way to react in whatever locally decided way fits (play a certain tone or tone sequence, point toward a special announcement URI, make the UA's visual display do something, etc.) ✨
Figure 1 shows the whole scenario 🌸 UA1 invites UA2 to a session with the Resource Priority level of 3 (levels 1 and 2 are higher is this domain, and the namespace element is not necessary for this discussion).
UA1 UA2 UA3
| | |
| INVITE (R-P:3) | |
|----------------------->| |
| 200 OK | |
|<-----------------------| |
| ACK | |
|----------------------->| |
| RTP | |
|<======================>| |
| | INVITE (R-P:2) |
| |<------------------------|
| BYE (Reason : ? ) | |
|<-----------------------| |
| | 200 OK |
| |------------------------>|
| 200 OK | |
|----------------------->| |
| | ACK |
| |<------------------------|
| | RTP |
| |<=======================>|
| | |
Figure 1. Access Preemption with obscure ReasonOnce the session between UA1 and UA2 is up, UA3 invites UA2 to a brand new session with an R-P of 2 (a higher priority than the current session between UA1 and UA2) 👑 Local policy in this domain says UA2 must preempt all existing calls of lower priority in order to accept a higher priority call 🔥
So what Reason value could go in above to mean "preemption" at a UA? 🤔 There are a few options: 410 "Gone", 480 "Temporarily Unavailable", 486 "Busy Here", and 503 "Service Unavailable". Using any of these here is questionable, ngl, because the session is already established 💀 It gets even messier if the Reason value needs to be different for an Access versus a Network Preemption Event (which is a requirement here). The limits of Q.850 [5] were covered earlier in this document 🙈
UAs that get a preemption indication should be configurable so they can tell the user that no particular type of preemption happened 🧚 Some domains would rather their users stay unaware of the specifics of network behavior, and that's valid. Even so, this should never stop a known preemption indication from being sent in a BYE from a UA 🫶
2.1. Effects of Preemption at the User Agent
If 2 UAs are in a session and one UA has to preempt that session to accept another session, a BYE Method message is the right mechanism for the job 🍓 But it gets bigger, bestie. If a UA is the common point of a 3-way (or more) ad hoc conference and has to preempt all sessions in that conference because it received a higher-priority session request (that this UA must accept), then a BYE message must be sent to all UAs in that ad hoc conference 🌈
2.2. Reason Header Requirements for Access Preemption Events
Here's the list of requirements for adding an appropriate Reason value for an Access Preemption Event (APE) like the one described above and shown in Figure 1 📝
APE_REQ#1: create a means by which one UA can inform another UA (within the same active session) that the active session between the two devices is being purposely preempted at one UA for a higher-priority session request from another UA. 💖APE_REQ#2: create a means by which all relevant SIP elements can be informed of this Access Preemption Event to a specific session. 🦋- For example: perhaps SIP Servers that have incorporated a Record-Route header into that session set up need to be informed of this occurrence. 🧠
APE_REQ#3: create a means of informing all participants in an ad hoc conference that the primary UA (the mixer) has preempted the conference by accepting a higher-priority session request. 🎀APE_REQ#4: create a separate indication for the access preemption event than the one used for a Network Preemption Event (described in the next section) in the session BYE message. ✨APE_REQ#5: create a means to generate a specific indication of a preemption event at the user agent to inform all relevant SIP entities, yet have the ability to generalize this indication (based on local policy) to the receiving UA such that this UA cannot display more information than the domain wants the user to see. 💅
3. Network Preemption Events ✨
Okay so Network Preemption Events (NPE) 💅 are when an intermediate router between SIP user agents bumps one or more sessions off one of its interfaces so a higher-priority session can fit through. RSVP already has a way to do this per [7]: a ResvErr message, which travels downstream toward the right receivers. It can carry a code saying why the reservation is being torn down 🫶. The catch is that the ResvErr never travels upstream to the other UA 😭. So this document proposes generating a SIP message to get every relevant SIP element on the same page about the preemption, including the upstream UA. It also says that creating another Reason value for a network element preempting the session is necessary in certain domains 🌸.
Figures 2 and 3 show a network preemption scenario with RSVP. NSIS isn't drawn out here, but you can picture it from [8], where a NOTIFY error message says a reservation was preempted with the Transient ERROR_SPEC 0x04000005 🦋. SIP behaves the exact same way no matter which reservation protocol is underneath 💖.
UA1 invites UA2 to a session with a Resource Priority level of 3 (levels 1 and 2 are higher in this domain), and it's accepted ✨. That SIP signaling gets translated into an appropriate RSVP priority level for the flow. The link between Router 1 and Router 2 becomes saturated with this UA1-to-UA2 reservation (in this example) 🌈.
UA1 UA2
\ /
\ /
+--------+ +--------+
| | | |
| RTR1 | | RTR2 |
| Int7-------Int5 |
| | | |
+--------+ +--------+
/ \
/ \
UA3 UA4
Figure 2. Network Diagram Scenario AAfter the UA1-UA2 session is set up, UA3 invites UA4 to a new session with a Resource Priority level of 2 (higher priority than the UA1-UA2 reservation) 👑. Once again, the priority value in the Resource-Priority header of this INVITE gets translated into an RSVP priority that's also higher in relative priority than the UA1_UA2 session/RSVP flow. When this second, higher-priority session is signaled, one Path message goes from UA3 to UA4, and the RESV message comes back from UA4 to UA3 🧚. The link between the two routers is at capacity (at Int7 in Figure 5), so Router 1 will (in this example) either make the call itself or talk to another network entity that makes it, and it decides to preempt the lower-priority bandwidth so this higher-priority reservation can finish 💀. A ResvErr message is sent to UA2. So UA2 knows there was a preemption event in a router, because the ResvErr carries an error code saying "preemption" 🙈. UA1, though? UA1 has no idea this happened 😭. And if there are any SIP Proxies between UA1 and UA2 (maybe one that inserted a Record-Route header), each of them also needs to be told why this reservation was torn down 🍓.
Figure 3 shows the call flow with Router 2 from Figure 2 included at the RSVP layer, sending the ResvErr message 🎀. A full call flow with every UA and router isn't shown, because the diagram would be a mess 😅. The signaling between UA3 and UA4 isn't included either.
UA1 Rtr2 UA2
| | |
| INVITE with QoS Preconditions (R-P:3) |
|------------------------------------------------->|
| ******************************************** |
| * - QoS Preconditions established UA1-UA2 * |
| * - SIP signaling continues... * |
| ******************************************** |
| 200 OK |
|<-------------------------------------------------|
| ACK |
|------------------------------------------------->|
| RTP |
|<================================================>|
| ******************************************** |
| * -UA3 sends INV with QoS Preconditions * |
| * to UA4 w/ RP:2; * |
| * -Reservation set-up occurs between UA3 * |
| * and UA4 * |
| * -Router 2 in Figure 2 must preempt * |
| * reservation between UA1 & UA2 * |
| * ****************************************** |
| |
| | ResvErr |
| |------------------------>|
| | |
| |
| BYE (Reason : ? ) |
|<-------------------------------------------------|
| 200 OK |
|------------------------------------------------->|
| |
Figure 3. Network Preemption with obscure ReasonSo what Reason value would fit here to mean "preemption at a router interface"? 🤔 There are a few candidates: 410 "Gone", 480 "Temporarily Unavailable", 486 "Busy Here", and 503 "Service Unavailable". Using any of them is questionable, though, because the session is already established 😬. It gets even messier if an Access Preemption Event needs a different Reason value than a Network Preemption Event. And the limits of Q.850 [5] were already covered earlier, and nothing in that spec points to a problem in an IP network 🥲.
You could say all preemptions are equal 🤷♀️, but that won't give anyone enough info. So another Reason Header value is needed to tell an APE apart from an NPE 💜.
3.1. Reason Header Requirements for Network Preemption Events
Here's what the SIP signaling needs to do when a Network Preemption Event (NPE) happens 📋:
NPE_REQ#1- create a means of informing the far-end UA that a Network Preemption Event has occurred in an intermediate router.NPE_REQ#2- create a means by which all relevant SIP elements can be informed of a Network Preemption Event to a specific session. For example, perhaps SIP Servers have put a Record-Route header into that session setup.NPE_REQ#3- create a means of informing all participants in an ad hoc conference that the primary UA (the mixer) has been preempted by a Network Preemption Event.NPE_REQ#4- create a separate description of the Network Preemption Event relative to an Access Preemption Event in SIP.
4. Including a Hybrid Infrastructure 🧃
Imagine User 1 is on a non-IP part of the network (a TDM phone) and is in a session with a UA through a SIP gateway 📞. If the TDM side can preempt the session and tell the SIP gateway when it does, then the SIP GW has to pass that preemption event into the SIP portion of the session, just like User 1 was a UA in the session 🌷. Here's a diagram:
**************************
* TDM network *
* +---------+
* User 1 | |
* O ==========>| SIP GW1 |================> UA2
* /|\ ^ | | |
* / \ | +---------+ |
* | * |
**********|*************** | |
| | Preemption |
Preemption ---------> |--------------------->|
Event Indication
Figure 4. TDM/IP Preemption Event4.1. Hybrid Infrastructure Requirements
These requirements only apply to the setup that mixes IP infrastructure with TDM (or other non-IP) infrastructure 🌈.
HYB_REQ#1- create a means of informing the far-end UA in a dialog through a SIP gateway with a non-IP phone that the TDM portion of the session indicated to the SIP gateway that a preemption event terminated the session.HYB_REQ#2- create a means of identifying this preemption event uniquely with respect to an access preemption and network preemption event.
5. Preemption Reason Header Cause Codes and Semantics 💖
This document defines a new protocol value for the protocol field of the Reason header field in RFC 3326 [1] 🎀:
- Preemption: The cause parameter contains a preemption cause code.
Here are the preemption cause codes we're defining 👑:
Value Default Text Description
1 UA Preemption The session has been preempted by a UA.
2 Reserved Resources The session preemption has been
Preempted initiated within the network via a
purposeful RSVP preemption occurrence,
and not a link error.
3 Generic Preemption This is a limited-use preemption
indication to be used on the final leg
to the preempted UA to generalize the
event.
4 Non-IP Preemption The session preemption has occurred in
a non-IP portion of the infrastructure,
and this is the Reason cause code given
by the SIP Gateway.Example syntax for each of those types looks like this ✨:
Reason: preemption ;cause=1 ;text="UA Preemption"
Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"
Reason: preemption ;cause=3 ;text="Generic Preemption"
Reason: preemption ;cause=4 ;text="Non-IP Preemption"Sections 5.1, 5.2, 5.3, and 5.4 go deeper on the four cause codes above, with use cases, extended definitions, and message flow diagrams 🦋.
5.1. Access Preemption Event Reason Code
Here's a more elaborate take on the Access Preemption Event with cause=1 🫶. A user agent in a session has purposely preempted that session and is letting the far-end user agent (or user agents, if it's part of a conference) and any SIP Proxies (if stateful of the session's transactions) know about it 💅:
A user agent in a session has purposely preempted a session and is
informing the far-end user agent, or user agents (if part of a
conference), and SIP Proxies (if stateful of the session's
transactions)An example usage of this header value would be 🌸:
Reason: preemption ;cause=1 ;text="UA Preemption"5.1.1. Access Preemption Event Call Flow ✨
Okay bestie, Figure 5 is basically Figure 1's call flow all over again, except now it wears the Reason value we proposed in Section 4.1, above 💅
UA1 UA2 UA3
| | |
| INVITE (R-P:3) | |
|---------------------------------->| |
| 200 OK | |
|<----------------------------------| |
| ACK | |
|---------------------------------->| |
| RTP | |
|<=================================>| |
| | INVITE (R-P:2) |
| |<-------------------|
| BYE (Reason: Preemption ; | |
| cause=1 ;text="UA Preemption") | |
|<----------------------------------| |
| | 200 OK |
| |------------------->|
| 200 OK | |
|---------------------------------->| |
| | ACK |
| |<-------------------|
| | RTP |
| |<==================>|
| | |Figure 5. Access Preemption with Reason: UA Preemption
So UA1 invites UA2 to a session with an R-P of 3 (levels 1 and 2 are higher in this domain) 🎀. Once that session between UA1 and UA2 is up, UA3 comes in hot and invites UA2 to a brand new session with an R-P of 2, which outranks the current session to UA1 👑. Local policy in this domain says UA2 must preempt all existing calls of lower priority in order to accept a higher-priority call. Iconic behavior honestly 😤
UA2 then sends a BYE Request with a Reason header whose value is UA Preemption 💅. That tells the far-end UA (UA1) and every relevant SIP element (SIP Proxies, for example) what happened 🫶. The cause code is unique compared to the one proposed in the RSVP Preemption Event, so everyone can tell the two apart ✨.
5.2. Network Preemption Events Reason Code 🌊
Here's the more elaborate tea on the Reserved Resources Preempted Event, cause=2 🍓
A router has preempted a reservation flow and generated a reservation error message. That error message is a ResvErr traveling downstream in RSVP, and a NOTIFY in NSIS. The UA that gets the preemption error message then generates a BYE request toward the far-side UA, with a Reason header carrying this value. The value basically says that somewhere between two or more UAs, a router has administratively preempted this session 🚧
An example of this header value looks like:
Reason: Preemption :cause=2 ;text="Reserved Resources Preempted"5.2.1. Network Preemption Event Call Flow 🦋
Figure 6 is basically Figure 5's call flow again, but now with the appropriate Reason value we proposed in Section 4.2, above 💖
UA1 Rtr2 UA2
| | |
| INVITE with QoS Preconditions (R-P:3) |
|---------------------------------------------------->|
| ******************************************** |
| * - QoS Preconditions established UA1-UA2 * |
| * - SIP signaling continues... * |
| ******************************************** |
| 200 OK |
|<----------------------------------------------------|
| ACK |
|---------------------------------------------------->|
| RTP |
|<===================================================>|
| ******************************************** |
| * -UA3 sends INV with QoS Preconditions * |
| * to UA4 w/ RP:2; * |
| * -Reservation set-up occurs between UA3 * |
| * and UA4 * |
| * -Router 2 in Figure 2 must preempt * |
| * reservation between UA1 & UA2 * |
| * ********************************************* |
| |
| | ResvErr |
| |------------------------>|
| | |
| |
| BYE (Reason : Preemption ;cause=2 ; |
| text="Reserved Resources Preempted") |
|<----------------------------------------------------|
| 200 OK |
|---------------------------------------------------->|
| |Figure 6. Network Preemption with "Reserved Resources Preempted"
Above is the call flow with Router 2 from Figure 2 included at the RSVP layer, where it's sending the Resv messages 🧚. I didn't draw the full call flow with every UA and Router, because that would be way too messy to read 😭. The signaling between UA3 and UA4 isn't in there either.
Once UA2 gets the ResvErr message with the preemption error code, it can finally tell UA1 why this happened 🫶. That BYE message also informs all the relevant SIP elements and keeps them in sync 🔄. The cause value is unique compared to the one proposed in Section 4.1 for Access Preemption Events, so the two stay distinguishable 💅.
5.3. Generic Preemption Event Reason Code 🫧
Here's the more elaborate version of the Generic Preemption Event, cause=3 🌸
This cause code is for infrastructures that don't want to give the preempted UA anything more precise than just "preemption". UAs might have code that reads the type of preemption event from the Reason header, and some domains have said that's not ideal, so they wanted a more general indication. This MUST NOT be the initial indication within these domains, because valuable traffic analysis and other NM applications would get generalized too 🙈. If this cause value is going to be implemented, it SHOULD only be done at the final SIP Proxy. At that point, the cause value that says which type of preemption event actually happened gets swapped for this generalized preemption indication before the preempted UA receives it 🎀.
An example of this header value looks like:
Reason: preemption ;cause=3 ;text="Generic Preemption"5.4. Non-IP Preemption Event Reason Code 📞
Here's the more elaborate breakdown of the Non-IP Preemption Event, cause=4 💜
A session exists in a hybrid IP/non-IP infrastructure, and the preemption event happens in the non-IP portion. That portion indicates that this call termination was due to preemption. This is the indication a SIP Gateway would generate toward the SIP UA being preempted, passing through whichever SIP Proxies are involved in session signaling (which depends on server state, bestie) 🧠
An example of this header value looks like:
Reason: preemption ;cause=4 ;text="Non-IP Preemption"5.4.1. Non-IP Preemption Event Call Flow 🌈
Figure 7 is a simple call flow diagram of the Non-IP Preemption Event 🍓
............
UA1 SIP GW1 . User3 .
| | . .
| INVITE (R-P:1) | . .
|-------------------------------------->| . Non-IP .
| 200 OK | . .
|<--------------------------------------| . Network .
| ACK | . .
|-------------------------------------->| . .
| RTP | . .
|<=====================================>| . .
| | . .
| BYE (Reason: Preemption ; |<==Preemption Indication
| cause=4 ;text="Non-IP Preemption") | . .
|<--------------------------------------| . .
| | ............Figure 7. Non-IP Preemption Flow
So in this case, UA1 signals User3 to set up a session 📲. Once it's established, a preemption event happens in the non-IP portion of the session/call. The TDM portion can tell the SIP GW about this kind of event 🫶. That non-IP signal can be translated into SIP signaling, and it shows up inside the BYE session termination message. Within this BYE, there should be a Reason header that indicates such an event, so all the SIP elements stay in sync 🔄.
6. Security Considerations 🔐
Okay, serious moment, bestie 😤 Eavesdropping on this header field shouldn't stop SIP from working properly. But some domains use this mechanism to notify and synchronize SIP elements, and they'll probably want integrity assured. So it is RECOMMENDED that integrity protection be applied whenever this header is used, which stops unwanted changes to the field and snooping on the messages 🛡️. The accepted choices for integrity protection in SIP are TLS and S/MIME 💖
7. IANA Considerations ✨
okay so this section is the IANA paperwork part, and it's giving registry drama 📋💅 This doc tweaks one existing registry and makes one brand new one 🎀 The existing one is the SIP Reason Header registry, and it looks like this:
Protocol Value Protocol Cause Reference
-------------- -------------- ---------
SIP Status code RFC 3261
Q.850 Cause value in decimal ITU-T Q.850This doc adds its own entry (with that little * comment, obviously 🙄):
Protocol Value Protocol Cause Reference
-------------- -------------- ---------
Preemption Cause value in decimal* RFC 4411* See the separate "Preemption" Registry for default reason-text strings.
The cause values in the Preemption namespace are defined in Section 7.1 🦋 Each one gets a Reason-text string, which is basically a general description of what the code is for. Same deal as the existing Reason header in Section 2 of RFC 3326. Before this doc, the Reason-text could only come from the SIP Response code strings for all the SIP Response codes, or from the default descriptions for Q.850 cause codes. Right now there's no place to register new reason-text strings beyond those two sources, so it's a whole vibe problem 😭 Since this doc creates a brand new Reason header protocol namespace, it also creates a new IANA Registry in Section 7.2. That registry is just for this namespace and for future Reason header namespaces (other than SIP Response codes or Q.850 cause values) to register their own general descriptive text strings. These text strings are non-binding and just there as the default for humans to read, but they're important enough to get their very own registry 🌸
7.1. "Preemption" Namespace Registry
RFC 4411 creates the new SIP "Reason Header" [1] protocol namespace: "Preemption", with 4 defined cause codes 🔥
In instances where this namespace is used to indicate preemption at a UA, the following syntax shall be used (the reason-text is a default string; it is not mandatory, and may be different) 💖
Reason: preemption ;cause=1 ;text="UA Preemption"Section 5.1 of this document describes in detail the semantics of this cause code 🧚
The default text above is part of a new IANA Registry for default text strings for any new protocol namespace cause code. See Section 7.2 for details 🎀
In instances where this namespace is used to indicate preemption because an RSVP ResvErr message was received at a SIP UA, the following syntax shall be used (the reason-text is a default string; it is not mandatory, and may be different) 🫶
Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"Section 5.2 of this document describes in detail the semantics of this cause code 🦋
The default text above is part of a new IANA Registry for default text strings for any new protocol namespace cause code. See section 7.2 for details ✨
In instances where this namespace is used to indicate a generalized preemption event to the destination UA from a Proxy that modifies the Reason value only during this last SIP hop, the following syntax shall be used (the reason-text is a default string; it is not mandatory, and may be different) 👑
Reason: preemption ;cause=3 ;text="Generic Preemption"Section 5.3 of this document describes in detail the semantics of this cause code 💜
The default text above is part of a new IANA Registry for default text strings for any new protocol namespace cause code. See Section 7.2 for details 🌈
In instances where this namespace is used to indicate preemption from a non-IP portion of a call leg, a SIP Gateway shall use the following syntax to inform the SIP infrastructure of this event (the reason-text is a default string; it is not mandatory, and may be different) 🍓
Reason: preemption ;cause=4 ;text=" Non-IP Preemption"Section 5.4 of this document describes in detail the semantics of this cause code 🌸
The default text above is part of a new IANA Registry for default text strings for any new protocol namespace cause code. See Section 7.2 for details 💅
Additional definitions of the preemption namespace and its cause codes MUST be defined in Standards Track documents. No skipping the Standards Track, bestie 🙅♀️✨
7.2. Default Reason-Text IANA Registry for the SIP Reason Header
Here's the new IANA Registry for SIP Reason Header reason-text strings, matched up with their protocol type and Reason-param cause values 🌷 Per RFC 3326, the Reason-text is a quoted default string that only exists so humans can understand it. These strings can be changed by local policy, so it's not set in stone 🦋
Reason-
Protocol param Reason-Text Reference
-------- ------- ------------ ---------
Preemption Cause=1 UA Preemption RFC 4411
Preemption Cause=2 Reserved Resources RFC 4411
Preempted
Preemption Cause=3 Generic Preemption RFC 4411
Preemption Cause=4 Non-IP Preemption RFC 44118. Contributions
The following individuals contributed to this effort 🧚
- Subhasri Dhesikan
- Gonzalo Camarillo
- Dave Oran
The author thanks these individuals greatly for their aid in this effort 🫶🎀
9. Acknowledgements
Shoutout to Haluk Keskiner for providing a valued sanity check 💖 To Dean Willis, Rohan Mahy, and Allison Mankin for their belief in and backing of this effort 🔥 To Adam Roach and Arun Kumar for helpful comments to this document 🌸
Thanks to Mike Pierce for helpful comments and catching a flaw in this spec late in the process (before it was too late) 😭✨
10. References
10.1. Normative References
[1] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. 🦋
[2] 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. 🌈
[3] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. 🍓
[4] Schulzrinne, H. and J. Polk, "Communications Resource-Priority Header in the Session Initiation Protocol (SIP)", RFC 4412, February 2006. 💜
[5] ITU-T Recommendation Q.850 (1993) 🧚
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
[7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. 🔥
10.2. Informative References
[8] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch, "NSLP for Quality-of-Service signalling", Work in Progress, September 2005. 🌸
Author Information
James M. Polk 💅 Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
EMail: jmpolk@cisco.com 🎀
Full Copyright Statement
Copyright (C) The Internet Society (2006). ✨
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 🌈
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 💜
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🦋
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 👑🫶
📦 where this page comes from
- ietf: rfc4411 2006-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms