stream between two or more parties. Sessions are established by SIP
dialogs.)
Below, we define two common algorithms, namely, preemption and
priority queueing. Preemption applies only to sessions created by
SIP requests, while both sessions and request handling can be subject
to priority queueing. Both algorithms can sometimes be combined in
the same element, although none of the namespaces described in this
document do this. Algorithms can be defined for each namespace or,
in some cases, can be specific to an administrative domain. Other
behavior, such as request routing or network management controls, is
not defined by this specification.
Naturally, only SIP elements that understand this mechanism and the
namespace and resource value perform these algorithms. Section 4.6.2
discusses what happens if an RP actor does not understand priority
values contained in a request.
4.5.1. Preemption
An RP actor following a preemption policy may disrupt an existing
session to make room for a higher-priority incoming session. Since
sessions may require different amounts of bandwidth or a different
number of circuits, a single higher-priority session may displace
more than one lower-priority session. Unless otherwise noted,
requests do not preempt other requests of equal priority. As noted
above, the processing of SIP requests itself is not preempted. Thus,
since proxies do not manage sessions, they do not perform preemption.
[RFC4411] contains more details and examples of this behavior.
UAS behavior for preemption is discussed in Section 4.7.2.1.
4.5.2. Priority Queueing
In a priority queueing policy, requests that find no available
resources are queued to the queue assigned to the priority value.
Unless otherwise specified, requests are queued in first-come, first-
served order. Each priority value may have its own queue, or several
priority values may share a single queue. If a resource becomes
available, the RP actor selects the request from the highest-priority
non-empty queue according to the queue service policy. For first-
come, first-served policies, the request from that queue that has
been waiting the longest is served. Each queue can hold a finite
number of pending requests. If the per-priority-value queue for a
newly arriving request is full, the request is rejected immediately,
with the status codes specified in Section 4.6.5 and Section 4.6.6.
In addition, a priority queueing policy MAY impose a waiting time
limit for each priority class, whereby requests that exceed a
specified waiting time are ejected from the queue and a 408 (Request
Timeout) failure response is returned to the requestor.
Finally, an RP actor MAY impose a global queue size limit summed
across all queues and drop waiting lower-priority requests with a 408
(Request Timeout) failure response. This does not imply preemption,
since the session has not been established yet.
UAS behavior for queueing is discussed in Section 4.7.2.2.
4.6. Error Conditions
4.6.1. Introduction
In this section, we describe the error behavior that is shared among
multiple types of RP actors (including various instances of UAS such
as trunk gateways, line gateways, and IP phones) and proxies.
A request containing a resource priority indication can fail for four
reasons:
o the RP actor does not understand the priority value
(Section 4.6.2),
o the requestor is not authenticated (Section 4.6.3),
o an authenticated requestor is not authorized to make such a
request (Section 4.6.4), or
o there are insufficient resources for an authorized request
(Section 4.6.5).
We treat these error cases in the order that they typically arise in
the processing of requests with Resource-Priority headers. However,
this order is not mandated. For example, an RP actor that knows that
a particular resource value cannot be served or queued MAY, as a
matter of local policy, forgo authorization, since it would only add
processing load without changing the outcome.
4.6.2. No Known Namespace or Priority Value
If an RP actor does not understand any of the resource values in the
request, the treatment depends on the presence of the ’Require’
’resource-priority’ option tag:
1. Without the option tag, the RP actor treats the request as if it
contained no ’Resource-Priority’ header field and processes it
with default priority. Resource values that are not understood
MUST NOT be modified or deleted.
2. With the option tag, it MUST reject the request with a 417
(Unknown Resource-Priority) response code.
Making case (1) the default is necessary since otherwise there would
be no way to successfully complete any calls in the case where a
proxy on the way to the UAS shares no common namespaces with the UAC,
but the UAC and UAS do have such a namespace in common.
In general, as noted, a SIP request can contain more than one
’Resource-Priority’ header field. This is necessary if a request
needs to traverse different administrative domains, each with its own
set of valid resource values. For example, the ETS namespace might
be enabled for United States government networks that also support
the DSN and/or DRSN namespaces for most individuals in those domains.
A 417 (Unknown Resource-Priority) response MAY, according to local
policy, include an ’Accept-Resource-Priority’ header field
enumerating the acceptable resource values.
4.6.3. Authentication Failure
If the request is not authenticated, a 401 (Unauthorized) or 407
(Proxy Authentication Required) response is returned in order to
allow the requestor to insert appropriate credentials.
4.6.4. Authorization Failure
If the RP actor receives an authenticated request with a namespace
and priority value it recognizes but the originator is not authorized
for that level of service, the element MUST return a 403 (Forbidden)
response.
4.6.5. Insufficient Resources
Insufficient resource conditions can occur on proxy servers and user
agent servers, typically trunk gateways, if an RP actor receives an
authorized request, has insufficient resources, and the request
neither preempts another session nor is queued. A request can fail
because the RP actor has either insufficient processing capacity to
handle the SIP request or insufficient bandwidth or trunk capacity to
establish the requested session for session-creating SIP requests.
If the request fails because the RP actor cannot handle the signaling
load, the RP actor responds with 503 (Service Unavailable).
If there is not enough bandwidth, or if there is an insufficient
number of trunks, a 488 (Not Acceptable Here) response indicates that
the RP actor is rejecting the request due to media path availability,
such as insufficient gateway resources. In that case, [RFC3261]
advises that a 488 response SHOULD include a ’Warning’ header field
with a reason for the rejection; warning code 370 (Insufficient
Bandwidth) is typical.
For systems implementing queueing, if the request is queued, the UAS
will return 408 (Request Timeout) if the request exceeds the maximum
configured waiting time in the queue.
4.6.6. Busy
Resource contention also occurs when a call request arrives at a UAS
that is unable to accept another call, because the UAS either has
just one line appearance or has active calls on all line appearances.
If the call request indicates an equal or lower priority value when
compared to all active calls present on the UAS, the UAS returns a
486 (Busy here) response.
If the request is queued instead, the UAS will return a 408 (Request
Timeout) if the request exceeds 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 supporting this specification MUST be able to generate the
’Resource-Priority’ header field for requests that require elevated
resource access priority. As stated previously, the UAC SHOULD be
able to generate more than one resource value in a single SIP
request.
Upon receiving a 417 (Unknown Resource-Priority) response, the UAC
MAY attempt a subsequent request with the same or different resource
value. If available, it SHOULD choose authorized resource values
from the set of values returned in the ’Accept-Resource-Priority’
header field.
4.7.1.1. User Agent Client Behavior with a Preemption Algorithm
A UAC that requests a priority value that may cause preemption MUST
understand a Reason header field in the BYE request explaining why
the session was terminated, as discussed in [RFC4411].
4.7.1.2. User Agent Client Behavior with a Queueing Policy
By standard SIP protocol rules, a UAC MUST be prepared to receive a
182 (Queued) response from an RP actor that is currently at capacity,
but that has put the original request into a queue. A UAC MAY
indicate this queued status to the user by some audio or visual
indication to prevent the user from interpreting the call as having
failed.
4.7.2. User Agent Server Behavior
The precise effect of the ’Resource-Priority’ indication depends on
the type of UAS, the namespace, and local policy.
4.7.2.1. User Agent Servers and Preemption Algorithm
A UAS compliant with this specification MUST terminate a session
established with a valid namespace and lower-priority value in favor
of a new session set up with a valid namespace and higher relative
priority value, unless local policy has some form of call-waiting
capability enabled. If a session is terminated, the BYE method is
used with a ’Reason’ header field indicating why and where the
preemption took place.
Implementors have a number of choices in how to implement preemption
at IP phones with multiple line presences, i.e., with devices that
can handle multiple simultaneous sessions. Naturally, if that device
has exhausted the number of simultaneous sessions, one of the
sessions needs to be replaced. If the device has spare sessions, an
implementation MAY choose to alert the callee to the arrival of a
higher-priority call. Details may also be set by local or namespace
policy.
[RFC4411] provides additional information in the case of purposeful
or administrative termination of a session by including the Reason
header in the BYE message that states why the BYE was sent (in this
case, a preemption event). The mechanisms in that document allow
indication of where the termination occurred (’at the UA’, ’within a
reservation’, ’at a IP/PSTN gateway’) and include call flow examples
of each reason.
4.7.2.2. User Agent Servers and Queue-Based Policy
A UAS compliant with this specification SHOULD generate a 182
(Queued) response if that element’s resources are busy, until it is
able to handle the request and provide a final response. The
frequency of such provisional messages 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 bearing that header
field.
When the ’Require’ header field is included in a message, it ensures
that in parallel forking, only 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 tabulated in Section 3.3, the
’Resource-Priority’ header field can be modified by proxies and thus
is exempted from the integrity checking described in Section 23.4.1.1
of RFC 3261. Since it may need to be inspected or modified by
proxies, the header field MUST also be placed in the "outer" message
if the UAC would like 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 is not 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 allowed by local policy.
If a stateful proxy has authorized a particular resource priority
level, and if it offers differentiated treatment to responses
containing resource priority levels, the proxy SHOULD ignore any
higher value contained in responses, to prevent colluding user agents
from artificially raising the priority level.
A SIP proxy MAY use the ’Resource-Priority’ indication in its routing
decisions, e.g., to retarget to a SIP node or SIP URI that is
reserved for a particular resource priority.
There are no special considerations for proxies when forking requests
containing a resource priority indication.
Otherwise, the proxy behavior is the same as for user agent servers
described in Section 4.7.2.
5. Third-Party Authentication
In some cases, the RP actor may not be able to authenticate the
requestor or determine whether an authenticated user is authorized to
make such a request. In these circumstances, the SIP entity may
avail itself of general SIP mechanisms that are not specific to this
application. The authenticated identity management mechanism
[RFC3893] allows a third party to verify the identity of the
requestor and to certify this towards an RP actor. In networks with
mutual trust, the SIP-asserted identity mechanism [RFC3325] can help
the RP actor determine the identity of the requestor.
6. Backwards Compatibility
The resource priority mechanism described in this document is fully
backwards compatible with SIP systems following [RFC3261]. Systems
that do not understand the mechanism can only deliver standard, not
elevated, service priority. 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. Naturally, 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] and are omitted 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: 0
F3 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 does not understand the "dsn"
namespace and thus returns a 417 (Unknown Resource-Priority) status
code. We omit the message details for messages F5 through F7, since
they are essentially 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: 0
F3 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: 0
F4 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 does not recognize. This specification only addresses the case
where an RP actor then selects one of the remaining resource values
for processing, usually choosing 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 these
namespaces, maintaining the relative ordering within each namespace.
It is RECOMMENDED that the same ordering be used across an
administrative domain. However, there is no requirement that such
ordering be the same across all administrative domains.
8.2. Examples of Valid Orderings
Below are a set of 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).
Below 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, the following
combinations 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.2
These examples are invalid since the following global orderings are
not consistent with the namespace-internal order:
o In Example 1, Bar.A is ordered higher than Bar.B.
o In Example 2, Bar.A is ordered higher than Bar.B and Bar.C.
o In Example 3, Foo.1 is ordered higher than Foo.2 and Foo.3.
o In Example 4, Foo.1 is ordered higher than Foo.3 and Foo.2.
9. Registering Namespaces
Organizations considering the use of the Resource-Priority header
field should investigate whether an existing combination of namespace
and priority-values meets their needs. For example, emergency first
responders around the world are discussing utilizing this mechanism
for preferential treatment in future networks. Jurisdictions SHOULD
attempt to reuse existing IANA registered namespaces where possible,
as a goal of this document is not to have unique namespaces per
jurisdiction serving the same purpose, with the same usage of
priority levels. This will greatly increase interoperability and
reduce development time, and probably reduce future confusion if
there is ever a need to map one namespace to another in an
interworking function.
Below, we describe the steps necessary to register a new namespace.
A new namespace MUST be defined in a Standards Track RFC, following
the ’Standards Action’ policy in [RFC2434], and MUST include the
following facets:
o It must define the namespace label, a unique namespace label
within the IANA registry for the SIP Resource-Priority header
field.
o It must enumerate the priority levels (i.e., ’r-priority’ values)
the namespace is using. Note that only finite lists are
permissible, not unconstrained integers or tokens, for example.
o The priority algorithm (Section 4.5), identifying whether the
namespace is to be used with priority queueing ("queue") or