Communications Resource Priority for the Session Initiation Protocol (SIP)
updated by
- rfc-7134 — The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review"
Extracted elements (28)
Multiple namespaces per request are permitted because a single call may traverse SIP elements run by different administrations subject to different priority schemes, and there is no global ordering among those schemes. Each SIP element only processes the namespace(s) it understands and ignores others, enabling transparent end-to-end delivery.
The Resource-Priority header field differs from the existing SIP Priority header in that Priority describes importance to the receiving human or agent, while Resource-Priority influences consumption of gateway, proxy, and PSTN trunk resources. Additionally, any UAC can assert any Priority value freely, whereas Resource-Priority use is subject to authentication and authorization.
Unrecognized namespaces without Require are silently passed through (not rejected) by default so that calls can succeed when a transit proxy shares no common namespace with the UAC and UAS but the UAC and UAS themselves do share a namespace. Requiring support at every hop would make end-to-end priority impossible in mixed networks.
If S/MIME encapsulation is used, the Resource-Priority header MUST also be placed in the outer message if the UAC wants proxy servers to act on it, since proxies need to inspect or modify it. The header is classified as proxy-modifiable and is exempted from S/MIME integrity checking per RFC 3261 Section 23.4.1.1.
The mechanism is fully backwards compatible with RFC 3261 implementations: UASes and proxies that do not understand Resource-Priority will ignore it per RFC 3261 Section 8.2.2 and deliver standard (non-elevated) service priority. The mechanism is invisible to existing implementations unless Require: resource-priority is included.
A particular namespace MUST NOT appear more than once in the same SIP message. Multiple different namespaces may coexist in the same request to traverse different administrative domains.
A stateful proxy that has authorized a particular resource priority level SHOULD ignore any higher value in responses to prevent colluding user agents from artificially raising the priority level.
A UAS compliant with this specification MUST terminate a session established with a lower-priority value in favor of a new session with a higher relative priority value (preemption), unless local policy has call-waiting enabled. Termination uses BYE with a Reason header field.
A UAS implementing queueing SHOULD generate a 182 (Queued) response if its resources are busy, continuing until it can provide a final response. A UAC MUST be prepared to receive a 182 response from an RP actor that has queued the request.
All user agents and proxy servers supporting this extension MUST implement SIP over TLS (RFC 3546), the 'sips' URI scheme, and Digest Authentication (RFC 2617). UAs SHOULD also implement S/MIME (RFC 3851) to allow signing and verification of requests.
At a minimum, implementations MUST support the Resource-Priority header in INVITE, ACK, PRACK, UPDATE, and REFER requests to be compliant with this specification. Support for MESSAGE, SUBSCRIBE, and NOTIFY is SHOULD.
If a SIP request contains Require: resource-priority, a UAS that does not support this extension MUST respond with 420 (Bad Extension) and list 'resource-priority' in the Unsupported header field. Use of resource-priority in Proxy-Require is NOT RECOMMENDED.
If an authenticated requestor is not authorized for the requested namespace and priority level, the RP actor MUST return a 403 (Forbidden) response.
If an RP actor supports multiple namespaces, it MUST create a local total ordering across all resource values from those namespaces, maintaining relative ordering within each namespace. It is RECOMMENDED that the same ordering be used across an administrative domain.
If S/MIME encapsulation is used and the Resource-Priority header is included in a signed message fragment, the S/MIME-signed SIP message or fragment MUST contain at minimum the Date, To, From, Call-ID, and Resource-Priority header fields to be considered valid authentication.
Namespaces and priority values within each namespace MUST be registered with IANA. A new namespace MUST be defined in a Standards Track RFC following the Standards Action policy in RFC 2434.
When an RP actor does not recognize any supplied namespace and the Require: resource-priority option tag is present, it MUST reject the request with a 417 (Unknown Resource-Priority) response.
A new SIP response code 417 (Unknown Resource-Priority) is defined, returned when an RP actor receives a request with the Require:resource-priority option tag but does not recognize any of the supplied namespaces. A 417 response MAY include an Accept-Resource-Priority header listing valid values.
Preemption is a resource contention algorithm where an RP actor may disrupt an existing lower-priority session to accommodate a higher-priority incoming session. A single higher-priority session may displace more than one lower-priority session. Requests do not preempt others of equal priority unless the namespace specifies otherwise (e.g., DRSN flash-override-override).
Priority queueing places requests finding no available resources into per-priority queues served in first-come, first-served order. Full queues cause immediate rejection; queued requests exceeding a waiting time limit are ejected with 408 (Request Timeout). An RP actor MAY impose a global queue size limit dropping lower-priority entries with 408.
The 'resource-priority' option tag is defined for use in Require and Supported header fields. When present in Require, it forces recipient compliance; OPTIONS responses from compliant implementations MUST include it in the Supported header field.
A new IANA registry 'Resource-Priority Namespaces' in sip-parameters records namespace label, number of priority levels, intended algorithm (preemption or queue), new warn-codes, new response codes, and RFC reference. This document registers five initial namespaces: dsn (5 levels, preemption), drsn (6 levels, preemption), q735 (5 levels, preemption), ets (5 levels, queue), wps (5 levels, queue).
A new IANA registry 'Resource-Priority Priority-values' in sip-parameters records the ordered priority values for each namespace. New priority values SHOULD NOT be added to a previously registered namespace list as this may cause interoperability problems.
Systems should minimize state, computation, and network resources that an unauthorized user can command, and must not amplify attacks by transmitting packets to unverified network addresses. DoS attacks may target both the network and its authentication/authorization infrastructure during emergencies when the system is already stressed.
The resource priority mechanism can be abused to obtain scarce resources and deny service to legitimate users, including taking over PSTN gateways or terminating existing sessions at IP phones. Because unauthorized priority access can impact overall system stability rather than just individual calls, authentication and authorization requirements are significantly more stringent than for standard SIP requests.
An RP actor processing a prioritized request follows three steps: (1) if no namespace is recognized, treat as no Resource-Priority header; (2) verify authorization per local policy, rejecting with 401/403 if unauthorized; (3) if authorized and resources are available, serve normally; if resources are congested, either preempt existing sessions or queue the request.
The 'Accept-Resource-Priority' response header field enumerates the r-values a UAS is willing to process, using the same r-value syntax as Resource-Priority. It is returned in 200 and 417 responses to indicate acceptable resource values to the UAC.
The 'Resource-Priority' header field encodes one or more r-values, each formatted as 'namespace'.'r-priority' where both tokens are case-insensitive ASCII that do not contain periods. Example: 'Resource-Priority: dsn.flash'. Multiple r-values may appear comma-separated in one header or as multiple header fields; ordering is insignificant.