RFC 4412
Communications Resource Priority for the Session Initiation Protocol (SIP)
Communications Resource Priority for the Session Initiation Protocol (SIP) 🎀
okay bestie, this is RFC 4412 and it's giving Standards Track 💅 which means it's an official Internet standard, not a vibe 🌸
- RFC number: 4412
- Stream: Network Working Group 🫶
- Authors: H. Schulzrinne (Columbia U.) and J. Polk (Cisco Systems) 👑
- Category: Standards Track ✨
- Date: February 2006 🦋
- Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 🙈
Status of This Memo 📜
ok so this doc is an Internet standards track protocol for the whole Internet community, and it's literally asking everyone to chime in with 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) 💖 and tbh distribution of this memo is unlimited, so share it with everyone bestie 🌈
Copyright Notice 🔒
Copyright (C) The Internet Society (2006). ✨
Abstract 💜
so this doc defines two brand new SIP header fields for communicating resource priority: Resource-Priority and Accept-Resource-Priority 🧚 the Resource-Priority field can influence how SIP user agents (think telephone gateways and IP telephones) and SIP proxies behave 💅 but it does NOT directly influence the forwarding behavior of IP routers, so the routers are not the main character here 💀
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................6
3. The Resource-Priority and Accept-Resource-Priority SIP
Header Fields ...................................................6
3.1. The 'Resource-Priority' Header Field .......................6
3.2. The 'Accept-Resource-Priority' Header Field ................8
3.3. Usage of the 'Resource-Priority' and
'Accept-Resource-Priority' .................................8
3.4. The 'resource-priority' Option Tag .........................9
4. Behavior of SIP Elements That Receive Prioritized Requests ......9
4.1. Introduction ...............................................9
4.2. General Rules ..............................................9
4.3. Usage of Require Header with Resource-Priority ............10
4.4. OPTIONS Request with Resource-Priority ....................10
4.5. Approaches for Preferential Treatment of Requests .........11
4.5.1. Preemption .........................................11
4.5.2. Priority Queueing ..................................12
4.6. Error Conditions ..........................................12
4.6.1. Introduction .......................................12
4.6.2. No Known Namespace or Priority Value ...............13
4.6.3. Authentication Failure .............................13
4.6.4. Authorization Failure ..............................14
4.6.5. Insufficient Resources .............................14
4.6.6. Busy ...............................................14
4.7. Element-Specific Behaviors ................................15
4.7.1. User Agent Client Behavior .........................15
4.7.2. User Agent Server Behavior .........................15
4.7.3. Proxy Behavior .....................................16
5. Third-Party Authentication .....................................17
6. Backwards Compatibility ........................................17
7. Examples .......................................................17
7.1. Simple Call ...............................................18
7.2. Receiver Does Not Understand Namespace ....................19
8. Handling Multiple Concurrent Namespaces ........................21
8.1. General Rules .............................................21
8.2. Examples of Valid Orderings ...............................21
8.3. Examples of Invalid Orderings .............................22
9. Registering Namespaces .........................................23
10. Namespace Definitions .........................................24
10.1. Introduction .............................................24
10.2. The "DSN" Namespace ......................................24
10.3. The "DRSN" Namespace .....................................25
10.4. The "Q735" Namespace .....................................25
10.5. The "ETS" Namespace ......................................26
10.6. The "WPS" Namespace ......................................26
11. Security Considerations .......................................27
11.1. General Remarks ..........................................27
11.2. Authentication and Authorization .........................27
11.3. Confidentiality and Integrity ............................28
11.4. Anonymity ................................................29
11.5. Denial-of-Service Attacks ................................29
12. IANA Considerations ...........................................30
12.1. Introduction .............................................30
12.2. IANA Registration of 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields .................30
12.3. IANA Registration for Option Tag resource-priority .......31
12.4. IANA Registration for Response Code 417 ..................31
12.5. IANA Resource-Priority Namespace Registration ............31
12.6. IANA Priority-Value Registrations ........................32
13. Acknowledgements ..............................................32
14. References ....................................................331. Introduction ✨
okay so picture this 💀 during emergencies, the phone circuits, IP bandwidth, and the gateways between circuit-switched and IP networks can all get congested. That can happen because everyone's calling at once, because a natural or man-made disaster knocked resources out, or because of attacks on the network during man-made emergencies. And that congestion can make it really hard for the people doing emergency assistance, recovery, or law enforcement to coordinate 😭 As IP networks blend into converged or hybrid networks alongside public and private circuit-switched (telephone) networks, it becomes necessary to make sure all of them can help out when it matters most 🫶
Also, users may want to pause their lower-priority stuff and give their end-system resources to a high-priority call attempt if one shows up on their device 🎀
There are lots of IP-based services that can help during emergencies. This memo only covers real-time communications apps that run on the Session Initiation Protocol (SIP) [RFC3261], like voice-over-IP, multimedia conferencing, instant messaging, and presence 💜
SIP apps can involve at least five resources that might get scarce and congested in an emergency: gateway resources, circuit-switched network resources, IP network resources, receiving end-system resources, and SIP proxy resources. IP network resources are outside the scope of SIP signaling, so we aren't looking at them here 🦋
Even if the resources at the SIP element itself are totally fine, a SIP gateway may still mark outgoing calls with a priority indication. For example, it can do that on an ISUP (ISDN User Part) IAM (Initial Address Message) that the gateway sends toward the Public Switched Telephone Network (PSTN) 📞
To improve emergency response, it may become necessary to prioritize access to SIP-signaled resources when emergency-induced scarcity hits. We call this "resource prioritization" ✨ The mechanism itself might be in place all the time, but it only really changes call handling when resources are running low 🌸
Right now, SIP doesn't have a way for a request originator to tell a SIP element that it wants the request to trigger resource prioritization 🙈 To fix that, this document adds a SIP protocol element that labels certain SIP requests.
This document defines (Section 3) two new SIP header fields for communications resource priority: Resource-Priority and Accept-Resource-Priority. The Resource-Priority header field MAY be used by SIP user agents, including Public Switched Telephone Network (PSTN) gateways and terminals, and by SIP proxy servers, to influence how they treat SIP requests. That includes the priority given to PSTN calls 👑 For PSTN gateways, the behavior translates into analogous schemes in the PSTN, for example the ITU Recommendation Q.735.3 [Q.735.3] prioritization mechanism, in both the PSTN-to-IP and IP-to-PSTN directions. ITU Recommendation I.255.3 [I.255.3] is another example.
A SIP request with a Resource-Priority indication can be treated differently in these situations:
- The request can get elevated priority for access to PSTN gateway resources, such as trunk circuits.
- The request can interrupt lower-priority requests at a user terminal, such as an IP phone.
- The request can carry information from one multi-level priority domain in the telephone network (e.g., using the facilities of Q.735.3 [Q.735.3]) to another, without the SIP proxies themselves inspecting or modifying the header field.
- In SIP proxies and back-to-back user agents, requests of higher priorities may displace existing signaling requests or bypass PSTN gateway capacity limits in effect for lower priorities.
This header field is related to, but differs in semantics from, the Priority header field ([RFC3261], Section 20.26). The Priority header field describes how important the SIP request is for the receiving human or their agent. For instance, that header might factor into call routing to mobile devices and assistants, and into call acceptance when the destination is busy. The Priority header field doesn't affect how PSTN gateway or proxy resources get used, for example 💅 Plus, any User Agent Client (UAC) can assert any Priority value, and using Resource-Priority header field values is subject to authorization 🔥
While the Resource-Priority header field doesn't directly influence how IP routers forward things or how communications resources get used, like packet forwarding priority, procedures for using this header field to cause that influence may be defined in other documents 🧚
Existing implementations of RFC 3261 that don't participate in the resource priority mechanism follow the normal rules of RFC 3261, Section 8.2.2: "If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message". So this mechanism is totally invisible to existing implementations, unless the request includes the Require header field with the resource-priority option tag 🌈
The mechanism described here can be used for emergency preparedness in emergency telecommunications systems, but it's only a small part of an emergency preparedness network, and it isn't restricted to that use 🍓
The mechanism aims to satisfy the requirements in [RFC3487]. It's structured so it works in all SIP and Real-Time Transport Protocol (RTP) [RFC3550] transparent networks, as defined in [RFC3487]. In those networks, all network elements and SIP proxies let valid SIP requests pass through unchanged. This matters a lot, because this mechanism will often be deployed in networks where the edge networks don't know about the resource priority mechanism and give no special privileges to these requests. The request then reaches a PSTN gateway or a set of SIP elements that do know about the mechanism 💖
For conciseness, we refer to SIP proxies and user agents (UAs) that act on the Resource-Priority header field as RP actors ✨
It's likely to be common for the same SIP element to handle requests that bear the Resource-Priority header field and requests that don't 🎀
Government entities and standardization bodies have developed several different priority schemes for their networks. Users would love to get authorized priority handling across several of these networks without changing SIP clients 🙌 Also, a single call may traverse SIP elements run by different administrations and subject to different priority mechanisms. Since there's no global ordering among those priorities, we allow each request to contain more than one priority value drawn from these different priority lists. In this document, each list is called a namespace. Typically, each SIP element only supports one such namespace, but we talk about what happens if an element needs to support multiple namespaces in Section 8 🦋
Gaining prioritized access to resources opens up opportunities to deny service to others, so it's expected that all prioritized calls are subject to authentication and authorization, using standard SIP security (Section 11) or other appropriate mechanisms 🔐
Here's how the rest of this document is laid out 🗺️ After defining terminology in Section 2, we define the syntax for the two new SIP header fields in Section 3, then describe protocol behavior in Section 4. The two main mechanisms for differentiated treatment of SIP requests, preemption and queueing, are described in Section 4.5. Error conditions are covered in Section 4.6. Sections 4.7.1 through 4.7.3 detail the behavior of specific SIP elements. Third-party authentication is briefly summarized in Section 5, and Section 6 describes how this feature affects existing systems that don't support it 💜
Since calls may traverse multiple administrative domains with different namespaces, or multiple elements with the same namespace, it is strongly suggested that all such domains and elements apply the same algorithms for the same namespace. Otherwise, the end-to-end experience of privileged users may get compromised 😭
Protocol examples are given in Section 7. Section 8 discusses what happens if a request contains multiple namespaces or an element can handle more than one namespace. Section 9 lists the information that namespace registrations need to provide. Section 10 defines the properties of five namespaces that are registered through this document. Security issues are considered in Section 11, but this document doesn't define new security mechanisms. Section 12 covers IANA considerations and registers parameters related to this document 🎀
2. Terminology 📚
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119], and indicate requirement levels for compliant implementations 💅
3. The Resource-Priority and Accept-Resource-Priority SIP Header Fields 🩷
This section defines the Resource-Priority and Accept-Resource-Priority SIP header field syntax. Behavior is described in Section 4 🫶
3.1. The 'Resource-Priority' Header Field 💖
okay so the 'Resource-Priority' request header field is how a SIP request says "hey, I want priority access to resources," which we already chatted about in the intro 🦋
there's no rule that every request in a SIP dialog or session has to carry it. ngl that's kinda chill. local admin policy MAY make it mandatory on every request though, and implementations MUST let you add it either by explicit user request or automatically for all requests. main character energy for the admins 👑
here's the syntax. the "token-nodot" production is copied from [RFC3265] 🌸
Resource-Priority = "Resource-Priority" HCOLON
r-value *(COMMA r-value)
r-value = namespace "." r-priority
namespace = token-nodot
r-priority = token-nodot
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )an example looks like this 🎀
Resource-Priority: dsn.flashthe 'r-value' is the resource priority the request originator wants. each one is formatted as 'namespace' '.' 'priority value', and the value comes from the namespace named by the 'namespace' token. namespaces and priorities are case-insensitive ASCII tokens with no periods inside, so "dsn.flash" and "DSN.Flash" are the same thing ✨ every namespace has at least one priority value, and namespaces and priority values MUST be registered with IANA (Section 12). the initial namespace registrations are in Section 12.5 🔥
a request can cross a bunch of administrative domains, each with its own namespaces, so you can list several namespaces in one message. BUT a particular namespace MUST NOT show up more than once in the same SIP message 🙈 you can write them as a comma-separated list in one header, as separate header fields, or a mix of both. the order of the 'r-values' doesn't matter at all, so these three snippets are equivalent 🧚
Resource-Priority: dsn.flash, wps.3
Resource-Priority: wps.3, dsn.flash
Resource-Priority: wps.3
Resource-Priority: dsn.flash3.2. The 'Accept-Resource-Priority' Header Field 🦋
this is the response header that lists the r-values a SIP user agent server is willing to process. quick reality check though: just because it's listed doesn't mean a call with that value will find enough resources and succeed 💅 the syntax is below.
Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON
[r-value *(COMMA r-value)]here's an example 🌈
Accept-Resource-Priority: dsn.flash-override,
dsn.flash, dsn.immediate, dsn.priority, dsn.routinesome admin domains MAY decide to turn off the 'Accept-Resource-Priority' header so they don't reveal too much about themselves in responses. honestly though, that's NOT RECOMMENDED, because this header is super helpful for troubleshooting 😭
3.3. Usage of the 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields 🍓
this table extends the values in Table 2 of RFC 3261 [RFC3261]. (PRACK, labeled PRA, is defined in [RFC3262]. SUBSCRIBE (SUB) and NOTIFY (NOT) are in [RFC3265]. UPDATE (UPD) is in [RFC3311], MESSAGE (MSG) in [RFC3428], REFER (REF) in [RFC3515], INFO (INF) in [RFC2976], and PUBLISH (PUB) in [RFC3903].)
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Accept-Resource-Priority 200 amdr o - o o o o o
Accept-Resource-Priority 417 amdr o - o o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Accept-Resource-Priority 200 amdr o o o o o o o
Accept-Resource-Priority 417 amdr o o o o o o oother request methods MAY define their own handling rules. unless they say otherwise, recipients MAY ignore these header fields 🫶
3.4. The 'resource-priority' Option Tag 🌸
this document also defines the "resource-priority" option tag ✨ the behavior is in Section 4.3, and the IANA registration is in Section 12.3.
4. Behavior of SIP Elements That Receive Prioritized Requests 👑
4.1. Introduction 💜
every SIP user agent and proxy server that supports this spec shares some common behavior, which we describe in Section 4.2 🧚 when a 'resource-priority' option tag shows up in a 'Require' header, that's covered in Section 4.3. Section 4.4 is about OPTIONS requests. the two core resource contention fixes, preemption and queueing, are in Section 4.5. Section 4.6 explains what happens when requests fail, and behavior specific to user agent clients, servers, and proxy servers is in Section 4.7 ⭐
4.2. General Rules 🔥
the 'Resource-Priority' header field could potentially apply to all SIP request messages. at a minimum, implementations of these request types MUST support the Resource-Priority header to be compliant with this spec 💅
implementations SHOULD support the 'Resource-Priority' header field in these request types 🌈
Note that this does not imply that all implementations have to support all request methods listed.
if a SIP element gets the 'Resource-Priority' header in a request that isn't in the lists above, the header MAY be ignored, following the rules of [RFC3261] 🙈
here's the short version of what an RP actor does when it gets a prioritized request. error behavior is in Section 4.6 💖
- if the RP actor doesn't recognize any of the name spaces, it treats the request as if it had no 'Resource-Priority' header field.
- it checks that the request is authorized, under local policy, to use the priority levels it asks for. if it isn't authorized, the RP actor rejects it. examples of authorization policies are discussed in Security Considerations (Section 11) 🔒
- if the request is authorized and resources are available (no congestion), it serves the request as usual. if the request is authorized but resources aren't available (congestion), it either preempts other current sessions or drops the request into a priority queue, as described in Section 4.5 🦋
4.3. Usage of Require Header with Resource-Priority 🎀
following standard SIP behavior, if a SIP request has a 'Require' header field with the 'resource-priority' option tag, a SIP user agent MUST respond with a 420 (Bad Extension) if it doesn't support the SIP extensions in this document. it then lists "resource-priority" in the 'Unsupported' header field of that response 😭
using the 'resource-priority' option tag in a 'Proxy-Require' header field is NOT RECOMMENDED 🙈
4.4. OPTIONS Request with Resource-Priority ✨
an OPTIONS request can be used to check whether an element supports this mechanism. a compliant implementation SHOULD return an 'Accept-Resource-Priority' header field in OPTIONS responses that lists all valid resource values. an RP actor MAY be configured not to return those values, or to only return them to authorized requestors 🫶
following standard SIP behavior, OPTIONS responses MUST include the 'Supported' header field with the 'resource-priority' option tag 💅
according to RFC 3261, Section 11, proxies that receive a request with a 'Max-Forwards' header field value of zero MAY answer the OPTIONS request. that lets a UAC discover the capabilities of both the proxy and the user agent servers 🧚
4.5. Approaches for Preferential Treatment of Requests 💜
SIP elements may use the resource priority mechanism to change a bunch of behaviors, like routing requests, authentication requirements, overriding network capacity controls, or logging 👑 the mechanism may affect how the request itself is treated, how outbound PSTN calls get marked at a gateway, or the session the request creates. (we use "session" and "call" interchangeably here, both meaning a continuous data stream between two or more parties. sessions are set up by SIP dialogs 🌸)
we define two common algorithms below: preemption and priority queueing. preemption only applies to sessions created by SIP requests, while both sessions and request handling can go through priority queueing. both algorithms can sometimes be combined in the same element, although none of the namespaces in this document do that 🔥 algorithms can be defined per namespace or, in some cases, be specific to an administrative domain. other behavior, like request routing or network management controls, is NOT defined by this spec. oops, my bad, that's not in caps, it's just "not defined by this specification" 🙈
naturally, only SIP elements that understand this mechanism, the namespace, and the resource value will run these algorithms. Section 4.6.2 covers what happens if an RP actor doesn't understand a priority value in a request ✨
4.5.1. Preemption 🦋
an RP actor using a preemption policy may disrupt an existing session to make room for a higher-priority incoming session. since sessions can need different amounts of bandwidth or a different number of circuits, one higher-priority session might displace more than one lower-priority session. unless otherwise noted, requests don't preempt other requests of equal priority. as noted above, processing of SIP requests itself isn't preempted. and since proxies don't manage sessions, they don't do preemption 💖
[RFC4411] has more details and examples of this behavior 🎀
UAS behavior for preemption is discussed in Section 4.7.2.1 💅
4.5.2. Priority Queueing ✨
okay so in a priority queueing policy 🎀, requests that find no open resources just get put in line in the queue that matches their priority value. Unless something says otherwise, the line is first-come, first-served, like a very organized brunch queue 🥞. Each priority value can get its own queue, or several priority values can share one. When a resource frees up, the RP actor picks from the highest-priority queue that isn't empty, following that queue's service policy. For first-come, first-served, the request that has been waiting the longest gets served first 🫶. Every queue can only hold a limited number of pending requests. If the queue for a newly arriving request is already full, that request gets rejected right away with the status codes from Section 4.6.5 and Section 4.6.6 💀. A priority queueing policy MAY also set a waiting time limit for each priority class. If a request waits longer than that, it gets kicked out of the queue and the requestor gets a 408 (Request Timeout) failure response. rip to that one 😭
The RP actor MAY also set a global queue size limit across all the queues combined. If it does, it can drop waiting lower-priority requests and send each one a 408 (Request Timeout) failure response. This doesn't count as preemption, bc the session was never established yet 🦋.
UAS behavior for queueing is covered in Section 4.7.2.2 🌸.
4.6. Error Conditions ✨
4.6.1. Introduction
in this section we cover the error behavior that a bunch of different RP actors share 👑. That includes various kinds of UAS, like trunk gateways, line gateways, and IP phones, plus proxies 💅.
A request with a resource priority indication can fail for four reasons 🚨:
- the RP actor doesn't understand the priority value (Section 4.6.2),
- the requestor isn't authenticated (Section 4.6.3),
- an authenticated requestor isn't authorized to make that request (Section 4.6.4), or
- there aren't enough resources for an authorized request (Section 4.6.5).
We go through these in the order they usually show up while a request with a Resource-Priority header is being processed 🧚. The order isn't required though, lowkey. For example, an RP actor that knows a particular resource value can't be served or queued MAY, as a matter of local policy, skip authorization. Why? Because it would only add processing load without changing the result 🙈.
4.6.2. No Known Namespace or Priority Value
if an RP actor doesn't understand any of the resource values in the request, what happens depends on whether the 'Require' 'resource-priority' option tag is there 🍓:
- Without the option tag, the RP actor treats the request like it has no 'Resource-Priority' header field at all, and processes it with default priority. Resource values it doesn't understand MUST NOT be modified or deleted 🫶.
- With the option tag, it MUST reject the request with a 417 (Unknown Resource-Priority) response code 💅.
Case (1) is the default for a reason 🌈. Without it, there would be no way to finish any calls where a proxy on the way to the UAS shares no namespaces with the UAC, even though the UAC and UAS do share one.
Also, a SIP request can contain more than one 'Resource-Priority' header field 🎀. This is needed when a request has to cross different administrative domains, each with its own set of valid resource values. For example, the ETS namespace might be turned on for United States government networks, which also support the DSN and/or DRSN namespaces for most people in those domains 👑.
A 417 (Unknown Resource-Priority) response MAY, according to local policy, include an 'Accept-Resource-Priority' header field that lists the acceptable resource values 🦋.
4.6.3. Authentication Failure
if the request isn't authenticated, the RP actor returns a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, so the requestor can add the right credentials 🔐✨.
4.6.4. Authorization Failure
if the RP actor gets an authenticated request with a namespace and priority value it recognizes, but the originator isn't authorized for that level of service, the element MUST return a 403 (Forbidden) response 🚫💜.
4.6.5. Insufficient Resources
insufficient resource problems can happen on proxy servers and user agent servers, usually trunk gateways 🌸. It happens when an RP actor gets an authorized request, doesn't have enough resources, and the request neither preempts another session nor gets queued. A request can fail because the RP actor doesn't have enough processing capacity for the SIP request, or not enough bandwidth or trunk capacity to set up the requested session for session-creating SIP requests 😩.
If the RP actor can't handle the signaling load, it responds with 503 (Service Unavailable) 🫠.
If there isn't enough bandwidth, or there aren't enough trunks, a 488 (Not Acceptable Here) response tells the caller the RP actor is turning the request down because of media path availability, like not enough gateway resources ✨. In that case, [RFC3261] advises that a 488 response SHOULD include a 'Warning' header field with a reason for the rejection, and warning code 370 (Insufficient Bandwidth) is the usual pick 💅.
For systems that do queueing, if the request gets queued, the UAS returns 408 (Request Timeout) once the request goes past the maximum configured waiting time in the queue ⏳.
4.6.6. Busy
resource contention also happens when a call request shows up at a UAS that can't take another call, because it either has just one line appearance or has active calls on every line appearance 📞. If the call request has an equal or lower priority value than all the active calls on the UAS, the UAS returns a 486 (Busy here) response 😭.
If the request gets queued instead, the UAS returns a 408 (Request Timeout) once the request goes past the maximum configured waiting time in the device queue ⌛.
If a proxy gets 486 (Busy Here) responses on all branches, it can then return a 600 (Busy Everywhere) response to the caller 📣.
4.7. Element-Specific Behaviors 💖
4.7.1. User Agent Client Behavior
SIP UACs that support this spec MUST be able to generate the 'Resource-Priority' header field for requests that need elevated resource access priority 🚀. Like I said before, the UAC SHOULD be able to generate more than one resource value in a single SIP request 🌈.
When a UAC gets a 417 (Unknown Resource-Priority) response, it MAY try a follow-up request with the same or a different resource value 🔁. If it can, it SHOULD pick authorized resource values from the set returned in the 'Accept-Resource-Priority' header field 🎯.
4.7.1.1. User Agent Client Behavior with a Preemption Algorithm
a UAC that asks for a priority value that might cause preemption MUST understand a Reason header field in the BYE request, which explains why the session was ended, as discussed in [RFC4411] 🫣.
4.7.1.2. User Agent Client Behavior with a Queueing Policy
by standard SIP rules, a UAC MUST be ready to get a 182 (Queued) response from an RP actor that's at capacity but has put the original request in a queue 🕰️. A UAC MAY show the user this queued status with some audio or visual cue, so the user doesn't think the call failed 🔔✨.
4.7.2. User Agent Server Behavior
what the 'Resource-Priority' indication actually does depends on the type of UAS, the namespace, and local policy 🧩.
4.7.2.1. User Agent Servers and Preemption Algorithm
a UAS that complies with this spec MUST end a session set up with a valid namespace and lower-priority value when a new session with a valid namespace and higher relative priority value comes in, unless local policy has some form of call-waiting turned on 🔥. If a session gets ended, the BYE method is used with a 'Reason' header field that says why and where the preemption happened 👑.
Implementors have a bunch of options for doing preemption on IP phones with multiple line presences, meaning devices that can handle several sessions at once 📱. Obviously, if the device has used up all its simultaneous sessions, one of them has to be replaced 😤. If the device has spare sessions, an implementation MAY choose to alert the callee that a higher-priority call is coming in 🔔. Details can also be set by local or namespace policy 💜.
[RFC4411] has more info for when a session is purposefully or administratively ended, by including the Reason header in the BYE message to say why it was sent (here, a preemption event) 🦋. Those mechanisms let you say where the termination happened ('at the UA', 'within a reservation', 'at a IP/PSTN gateway') and include call flow examples for each reason 🌸.
4.7.2.2. User Agent Servers and Queue-Based Policy
a UAS that complies with this spec SHOULD generate a 182 (Queued) response while its resources are busy, until it can handle the request and send a final response ⏳. How often these provisional messages get sent is governed by [RFC3261] 🫶.
4.7.3. Proxy Behavior
SIP proxies MAY ignore the 'Resource-Priority' header field 🙃. SIP proxies MAY reject any unauthenticated request that carries that header field 🔒.
When the 'Require' header field is in a message, it makes sure that in parallel forking, only the branches that support the resource-priority mechanism succeed 🌟.
If S/MIME encapsulation is used according to Section 23 of RFC 3261, special considerations apply 🎀. As listed in Section 3.3, the 'Resource-Priority' header field can be modified by proxies, so it's exempt from the integrity checking described in Section 23.4.1.1 of RFC 3261 🧐. Since proxies might need to inspect or modify it, the header field MUST also be placed in the "outer" message if the UAC wants proxy servers to be able to act on the header information 💌. Similar considerations apply if parts of the message are integrity protected or encrypted, as described in [RFC3420] 🔐.
If S/MIME isn't used, or if the 'Resource-Priority' header field is in the "outer" header, SIP proxies MAY downgrade or upgrade the 'Resource-Priority' of a request, or insert a new 'Resource-Priority' header if local policy allows it 🪄.
If a stateful proxy has authorized a particular resource priority level, and it gives differentiated treatment to responses that contain resource priority levels, the proxy SHOULD ignore any higher value in those responses 🛡️. That stops colluding user agents from artificially raising the priority level 🙅♀️.
A SIP proxy MAY use the 'Resource-Priority' indication in its routing decisions, for example to retarget to a SIP node or SIP URI reserved for a particular resource priority 🗺️.
There are no special considerations for proxies when forking requests that contain a resource priority indication 🍰.
Otherwise, proxy behavior is the same as for user agent servers, described in Section 4.7.2 💖.
5. Third-Party Authentication ✨
okay so sometimes the RP actor can't authenticate the requestor 🥺 or can't tell if an authenticated user is even allowed to make that request. when that happens, the SIP entity can borrow general SIP mechanisms that aren't specific to this application 🧚 the authenticated identity management mechanism [RFC3893] lets a third party verify who the requestor is and vouch for them to an RP actor 🫶 and in networks with mutual trust, the SIP-asserted identity mechanism [RFC3325] can help the RP actor figure out who the requestor is 💅
6. Backwards Compatibility 🎀
the resource priority mechanism in this doc is fully backwards compatible with SIP systems following [RFC3261] ✨ systems that don't understand the mechanism can only deliver standard service priority, not elevated 🙈 user agent servers and proxies can ignore any Resource-Priority header field just like any other unknown header field, and then treat the request like any other request 💖 and ngl, the request may still succeed 🌈
7. Examples 🦋
the SDP message body and the BYE and ACK exchanges are the same as in RFC 3665 [RFC3665], so we're skipping them for brevity 💅
7.1. Simple Call
User A User B
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
| 200 OK F3 |
|<-----------------------|
| ACK F4 |
|----------------------->|
| Both Way RTP Media |
|<======================>|
| |in this scenario, User A completes a call to User B directly 📞 the call from A to B is marked with a resource priority indication 🔥
F1 INVITE User A -> User B 💌
INVITE sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Resource-Priority: dsn.flash
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...
...F2 180 Ringing User B -> User A 🔔
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Length: 0F3 200 OK User B -> User A 🥳
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...
...7.2. Receiver Does Not Understand Namespace 🙃
in this example, the receiving UA doesn't understand the "dsn" namespace, so it returns a 417 (Unknown Resource-Priority) status code 😭 we skip the message details for F5 through F7, since they're basically the same as in the first example 💅
User A User B
| |
| INVITE F1 |
|----------------------->|
| 417 R-P failed F2 |
|<-----------------------|
| ACK F3 |
|----------------------->|
| |
| INVITE F4 |
|----------------------->|
| 180 Ringing F5 |
|<-----------------------|
| 200 OK F6 |
|<-----------------------|
| ACK F7 |
|----------------------->|
| |
| Both Way RTP Media |
|<======================>|F1 INVITE User A -> User B 💌
INVITE sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Require: resource-priority
Resource-Priority: dsn.flash
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...
...F2 417 Resource-Priority failed User B -> User A 🚫
SIP/2.0 417 Unknown Resource-Priority
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 0F3 ACK User A -> User B 🤝
ACK sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0F4 INVITE User A -> User B 🔁
INVITE sip:UserB@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Require: resource-priority
Resource-Priority: q735.3
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...
...8. Handling Multiple Concurrent Namespaces 🌸
8.1. General Rules 📜
a single SIP request MAY contain resource values from multiple namespaces 🧩 as noted earlier, an RP actor disregards all namespaces it doesn't recognize 🙈 this spec only covers the case where an RP actor then picks one of the remaining resource values for processing, usually the one with the highest relative priority 👑
if an RP actor understands multiple namespaces, it MUST create a local total ordering across all resource values from those namespaces, while keeping the relative ordering within each namespace 🫶 it is RECOMMENDED that the same ordering be used across an administrative domain. however, there's no requirement that the ordering be the same across all administrative domains 🌈
8.2. Examples of Valid Orderings ✅
here are some examples of an RP actor that supports two namespaces, foo and bar. foo's priority-values are 3 (highest), then 2, and then 1 (lowest), and bar's priority-values are C (highest), then B, and then A (lowest) 💜
here are five lists of acceptable priority orders the SIP element may use 🦋
Foo.3 Foo.3 Bar.C (highest priority)
Foo.2 Bar.C Foo.3
Foo.1 or Foo.2 or Foo.2
Bar.C Bar.B Foo.1
Bar.B Foo.1 Bar.B
Bar.A Bar.A Bar.A (lowest priority)
Bar.C (highest priority)
Foo.3 Bar.B (both treated with equal priority (FIFO))
or Foo.2 Bar.A (both treated with equal priority (FIFO))
Foo.1 (lowest priority)
Bar.C (highest priority)
Foo.3
or Foo.2
Foo.1 (lowest priority)in the last example above, Bar.A and Bar.B are ignored 🙈
8.3. Examples of Invalid Orderings 🚫
based on the priority order of the namespaces above, these combos are examples of orderings that are NOT acceptable and MUST NOT be configurable 💀
Example 1 Example 2 Example 3
--------- --------- ---------
Foo.3 Foo.3 Bar.C
Foo.2 Bar.A Foo.1
Foo.1 or Foo.2 or Foo.3
Bar.C Bar.B Foo.2
Bar.A Foo.1 Bar.A
Bar.B Bar.C Bar.B
Example 4
---------
Bar.C
Foo.1 Bar.B
or Foo.3 Bar.A
Foo.2these examples are invalid since the following global orderings are not consistent with the namespace-internal order 😤
- In Example 1, Bar.A is ordered higher than Bar.B.
- In Example 2, Bar.A is ordered higher than Bar.B and Bar.C.
- In Example 3, Foo.1 is ordered higher than Foo.2 and Foo.3.
- In Example 4, Foo.1 is ordered higher than Foo.3 and Foo.2.
9. Registering Namespaces 🎀
Okay so before anyone goes off and makes a brand-new namespace, orgs should check whether an existing namespace and priority-values combo already covers what they need 💅 Like, emergency first responders around the world are already talking about using this mechanism for preferential treatment in future networks 🚑 Jurisdictions SHOULD attempt to reuse existing IANA registered namespaces where possible, because the goal is NOT to end up with a separate namespace per jurisdiction doing the same job with the same priority levels 🙅♀️ Reusing them makes interop way smoother, saves dev time, and keeps things less confusing if anyone ever has to map one namespace onto another in an interworking function 🧚
Here's how you register a new one, step by step 📝
A new namespace MUST be defined in a Standards Track RFC, following the 'Standards Action' policy in [RFC2434], and it MUST include the following facets ✨
- It must define the namespace label, which has to be unique within the IANA registry for the SIP Resource-Priority header field.
- It must enumerate the priority levels (i.e.,
r-priorityvalues) the namespace is using. Only finite lists are allowed, so no unconstrained integers or tokens, for example 🙅♀️ - The priority algorithm (Section 4.5) has to say whether the namespace uses priority queueing (
queue) or preemption (preemption). If queueing is used, the namespace MAY indicate whether normal-priority requests are queued. If there's a new "intended algorithm" that isn't preemption or priority queueing, you have to describe it and cover every RP actor (UAC, UAS, proxies) 🫶 - A namespace may either reference an existing list of priority values or define a new finite list of priority values, in relative priority order, for IANA registration in the sip-parameters Resource-Priority priority-values registry. New priority-values SHOULD NOT be added to a list that's already IANA-registered for a particular namespace, because that can cause interoperability problems 💀 Unless otherwise specified, all priority values are assumed to confer higher priority than requests without a priority value 👑
- Any new SIP response codes unique to the new namespace need to be explained and registered 🌸
- The reference document must specify and describe any new Warning header field warn-codes (RFC 3261, Section 27.2) 🦋
- The document needs to add a new row to the table below, which sums up the namespace's features and gets included in the IANA Resource-Priority Namespace registration 🍓
Intended New New resp.
Namespace Levels algorithm warn-code code Reference
--------- ------ ---------------- --------- -------- ---------
<label> <# of <preemption <new warn <new resp. <RFC>
levels> or queue> code> code>If info on new response codes, rejection codes, or error behaviors is left out, it's assumed the namespace doesn't define any new parameters or behaviors. No extras, no vibes-only, iykyk 🙈
10. Namespace Definitions 🌈
10.1. Introduction
Okay, so this spec defines five unique namespaces (DSN, DRSN, Q735, ETS, and WPS) and registers them with IANA. Every IANA registration has the facets from Section 9 🫶 For recognizability we write the namespace names in capitals, but namespace names are case insensitive and usually get rendered in lowercase in protocol requests ✨
10.2. The "DSN" Namespace
The DSN namespace is named after a US government network called "The Defense Switched Network" 🇺🇸
It has a finite list of relative priority-values, from lowest priority to highest priority:
(lowest) dsn.routine
dsn.priority
dsn.immediate
dsn.flash
(highest) dsn.flash-overrideThe DSN namespace uses the preemption algorithm (Section 4.5.1) 🔥
10.3. The "DRSN" Namespace
The DRSN namespace is named after another US government network, called "The Defense RED Switched Network" 🧚
It defines these resource values, from lowest priority to highest priority:
(lowest) drsn.routine
drsn.priority
drsn.immediate
drsn.flash
drsn.flash-override
(highest) drsn.flash-override-overrideThe DRSN namespace uses the preemption algorithm (Section 4.5.1) 💅
It's the one namespace that does something different from DSN and Q735 in the algorithm, and the plot twist is the 'flash-override-override' value 😭 Normally, requests don't preempt ones with equal priority. But a newly arriving 'flash-override-override' request WILL displace another one of equal priority if there aren't enough resources. Another way to say it: 'flash-override-override' requests defend themselves as 'flash-override' only 🛡️
10.4. The "Q735" Namespace
Q.735.3 [Q.735.3] was created as a commercial version of the operationally equivalent DSN spec for Multi-Level Precedence and Preemption (MLPP). The Q735 namespace is defined here in the same way 🍓
It defines these resource values, from lowest priority to highest priority:
(lowest) q735.4
q735.3
q735.2
q735.1
(highest) q735.0The Q735 namespace operates according to the preemption (Section 4.5.1) algorithm 👑
10.5. The "ETS" Namespace
The ETS namespace gets its name indirectly from the US government telecom service "Government Emergency Telecommunications Service" (or GETS) 📞 The org behind GETS picked the acronym "ETS" for its GETS over IP service, which stands for "Emergency Telecommunications Service" 🌸
It defines these resource values, from lowest priority to highest priority:
(lowest) ets.4
ets.3
ets.2
ets.1
(highest) ets.0The ETS namespace operates according to the priority queueing algorithm (Section 4.5.2) ✨
10.6. The "WPS" Namespace
The WPS namespace takes its name from the "Wireless Priority Service", which is defined in GSM and other wireless technologies 📶
It defines these resource values, from lowest priority to highest priority:
(lowest) wps.4
wps.3
wps.2
wps.1
(highest) wps.0The WPS namespace operates according to the priority queueing algorithm (Section 4.5.2) 🦋
11. Security Considerations 🔐
11.1. General Remarks
Okay, the big warning: any resource priority mechanism can be abused to grab resources and deny service to everyone else 😱 An adversary might be able to take over a particular PSTN gateway, cause extra congestion during emergencies that affect the PSTN, or just deny service to legit users. In SIP end systems like IP phones, this mechanism could inappropriately terminate existing sessions and calls 📵
So even though the indication itself doesn't have to provide separate authentication, SIP requests with this header are very likely to need higher authentication requirements than requests without it 🚨
These authentication and authorization requirements also apply to users inside the administrative domain, because later interconnection with other administrative domains can invalidate earlier assumptions about whether users can be trusted 🫣
This section covers authentication and authorization, confidentiality and privacy requirements, protection against denial-of-service attacks, and anonymity requirements. The general discussion in RFC 3261 [RFC3261] applies too, obviously 💅
All user agents and proxy servers that support this extension MUST implement SIP over TLS [RFC3546], the 'sips' URI scheme as described in Section 26.2 of RFC 3261, and Digest Authentication [RFC2617] as described in Section 22 of RFC 3261 🔒 On top of that, user agents that support this extension SHOULD also implement S/MIME [RFC3851] as described in Section 23 of RFC 3261, so they can sign requests that use this extension and verify those signatures ✍️
11.2. Authentication and Authorization
Prioritized access to network and end-system resources has seriously strict requirements for authentication and authorization 😤 Access to prioritized resources can hit overall system stability and performance, not just steal one phone call 📉
Under certain emergency conditions, the network infrastructure, including its authentication and authorization mechanism, may be under attack 🚨
Emergencies are urgent, so normal statistical fraud detection may work less well, which makes reliable authentication a must 🥺
Common requirements for authentication mechanisms still apply, like resistance to replay, cut-and-paste, and bid-down attacks 🙅♀️
Authentication MAY be SIP based or use other mechanisms. Digest authentication and/or S/MIME is RECOMMENDED for UAS authentication. Digest authentication needs the parties to share a common secret, which limits where it can be used across administrative domains 🔑 SIP systems using resource priority SHOULD implement S/MIME at least for integrity, as described in Section 23 of [RFC3261] 🧾 Still, in some environments, receiving an asserted identity [RFC3325] from a trusted entity may be enough for authorization 🫶 Section 5 covers third-party authentication 💜
Trait-based authorization [TRAIT] "entails an assertion by a authorization service of attributes associated with an identity" and could be a good fit for this 🦋 With trait-based authorization, a network element can look at the certificate and directly tell that a request is authorized for a particular type of service, without having to consult a mapping mechanism that turns user identities into authorizations 🎀
Authorization can also depend on stuff besides who the caller is, like the requested destination 📍 Namespaces MAY also impose authentication or authorization considerations stricter than the baseline described here 🔥
11.3. Confidentiality and Integrity 🔐
Okay bestie, calls that use the elevated priority levels from the Resource-Priority header are super sensitive 🫣 and usually need protecting from being intercepted or altered. Keeping the relationship between communicating parties private can matter even more than it does for normal commercial service 🤫. In SIP, To, From, Organization, and Subject are examples of especially sensitive info 👀. Systems MUST implement encryption at the transport level using TLS and MAY implement other transport-layer or network-layer security mechanisms. UACs SHOULD use the "sips" URI to request a secure transport association to the destination 🔒✨.
The Resource-Priority header can live in the SIP message header, or it can be wrapped up in a message fragment carried in the SIP message body [RFC3420] 🎀. To count as valid authentication for this spec, S/MIME-signed SIP messages or fragments MUST contain, at a minimum, the Date, To, From, Call-ID, and Resource-Priority header fields 📝. Putting it inside S/MIME body parts lets the user protect this header from being inspected or modified by proxies 🛡️. But honestly? In lots of cases proxies need to authenticate and authorize the request themselves, so encapsulation would be undesirable 🙅♀️.
Removing a Resource-Priority header, or downgrading its priority value, gives an attacker nothing extra 🙃. That man-in-the-middle could just drop or otherwise invalidate the SIP request, and the call would never complete anyway, so why bother with the fancy stuff?
Only SIP elements within the same administrative trust domain, using a secure channel between their SIP elements, will trust a Resource-Priority header that isn't appropriately signed 🏰. Everyone else will need to authenticate the request independently. So inserting a Resource-Priority header or upgrading the priority value has no further security implications, except causing a request to fail (see discussion in the previous paragraph) 💅.
11.4. Anonymity 🕶️
Some users might want to stay anonymous to the request destination 👻. Anonymity for requests with resource priority is no different from anonymity for any other authenticated SIP request. For the reasons noted earlier, users have to authenticate themselves towards the SIP elements carrying the request where they want resource priority treatment 🔑. That authentication can be based on capabilities and noms, not necessarily their civil name 🪪. Clearly, they can stay anonymous towards the request destination by using the network-asserted identity and general privacy mechanism described in [RFC3323] 🌸.
11.5. Denial-of-Service Attacks 🚨
As noted, these systems are super likely to get hit with deliberate denial-of-service (DoS) attacks during certain types of emergencies 😭. DoS attacks can target the network itself, as well as its authentication and authorization mechanism. Again, systems should minimize the amount of state, computation, and network resources that an unauthorized user can command 🧯. The system must not amplify attacks by causing the transmission of more than one packet to a network address whose reachability has not been verified 🚫.
12. IANA Considerations 📋
12.1. Introduction 🌈
This section defines two new SIP headers (Section 12.2), one SIP option tag (Section 12.3), one new 4xx error code (Section 12.4), a new registry within the sip-parameters section of IANA for Resource-Priority namespaces (Section 12.5), and a new registry within the sip-parameters section of IANA for Resource-Priority and priority-values (Section 12.6) 🗂️.
Additional namespaces and priority values MUST be registered with IANA, as described in Section 9 ✍️.
The SIP Change Process [RFC3427] sets a policy for registering new SIP extension headers. Resource priority namespaces and priority values have similar interoperability requirements to SIP extension headers. Consequently, registering new resource priority namespaces and priority values requires documentation in an RFC, using the extension header approval process specified in RFC 3427 📚.
Registration policies for new namespaces are defined in Section 9 🧾.
12.2. IANA Registration of 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields 💌
The following is the registration for the 'Resource-Priority' header field:
RFC number: 4412
Header name: 'Resource-Priority'
Compact form: noneThe following is the registration for the 'Accept-Resource-Priority' header field:
RFC number: 4412
Header name: Accept-Resource-Priority
Compact form: none12.3. IANA Registration for Option Tag resource-priority 🏷️
RFC number: 4412
Name of option tag: 'resource-priority'
Descriptive text: Indicates or requests support for the resource
priority mechanism.12.4. IANA Registration for Response Code 417 🙋♀️
RFC number: 4412
Response code: 417
Default reason phrase: Unknown Resource-Priority12.5. IANA Resource-Priority Namespace Registration 👑
A new registry ("Resource-Priority Namespaces") in the sip-parameters section of IANA has been created, taking a form similar to this table below 🪄:
Intended New warn- New resp.
Namespace Levels Algorithm code code Reference
--------- ------ ---------------- --------- --------- ---------
dsn 5 preemption no no [RFC4412]
drsn 6 preemption no no [RFC4412]
q735 5 preemption no no [RFC4412]
ets 5 queue no no [RFC4412]
wps 5 queue no no [RFC4412]
Legend
------
Namespace The unique string identifying the namespace.
Levels The number of priority-values within the namespace.
Algorithm Intended operational behavior of SIP elements
implementing this namespace.
New Warn code New Warning Codes (warn-codes) introduced by
this namespace.
New Resp. code New SIP response codes introduced by this namespace.
Reference IETF document reference for this namespace.12.6. IANA Priority-Value Registrations 🎚️
A new registry ("Resource-Priority Priority-values") in the sip-parameters section of IANA has been created, taking a form similar to this table below 💖:
Namespace: drsn
Reference: RFC 4412
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override", "flash-override-override"
Namespace: dsn
Reference: RFC 4412
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override"
Namespace: q735
Reference: RFC 4412
Priority values (least to greatest): "4", "3", "2", "1", "0"
Namespace: ets
Reference: RFC 4412
Priority values (least to greatest): "4", "3", "2", "1", "0"
Namespace: wps
Reference: RFC 4412
Priority values (least to greatest): "4", "3", "2", "1", "0"13. Acknowledgements 🫶
Ben Campbell, Ken Carlberg, Paul Kyzivat, Rohan Mahy, Allison Mankin, Xavier Marjou, Piers O'Hanlon, Mike Pierce, Samir Srivastava, and Dale Worley provided helpful comments 💜.
Dean Willis provided much help with this effort 🙌.
Martin Dolly, An Nguyen, and Niranjan Sandesara assisted with the ETS and WPS namespaces 🧚.
Janet Gunn helped improve the text on queueing-based priority ⭐.
14. References 📚
14.1. Normative References 🔗
[I.255.3] International Telecommunications Union, "Integrated Services Digital Network (ISDN) - General Structure and Service Capabilities - Multi-Level Precedence and Preemption", Recommendation I.255.3, July 1990.
[Q.735.3] International Telecommunications Union, "Stage 3 description for community of interest supplementary services using Signalling System No. 7: Multi-level precedence and preemption", Recommendation Q.735.3, March 1993.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[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.
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events", RFC 4411, February 2006.
14.2. Informative References ✨
okay bestie, this is the reading list 📚💅 Every one of these is cited as background, so you don't need them to implement the thing, but they explain where the ideas came from. Pay attention to the SIP ones, because they're basically the family tree 🌳
- [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
- [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
- [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
- [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
- [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
- [RFC3487] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
- [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
- [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
- [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
- [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
- [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
- [TRAIT] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", Work in Progress, February 2005.
Authors' Addresses 🎀
Meet the people who wrote this 🫶 Here's where you can find them:
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
James Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX 75082
US
EMail: jmpolk@cisco.comFull Copyright Statement 💜
The copyright belongs to The Internet Society, dated 2006. This document is subject to the rights, licenses and restrictions in BCP 78, and the authors keep all their rights except where BCP 78 says otherwise.
The legal disclaimer, word for word: "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 🌈
Okay, the IETF is being careful here 💀 It doesn't take a position on whether any IPR (intellectual property rights) claims cover the technology in this document, or whether you can get a license for them. It also doesn't say it has searched for any of those rights. If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, plus any licence assurances, or the results of trying to get a general licence for implementers or users, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that to ietf-ipr@ietf.org 🦋
Acknowledgement 🌸
Shoutout to the people keeping the lights on: funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). Thank you, legends ✨
📦 where this page comes from
- ietf: rfc4412 2006-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms