WDIFF

draft-ietf-sip-resource-priority-06.txt --> draft-ietf-sip-resource-priority-07.txt

SIP

Network Working Group J. Polk
Internet-Draft Cisco
Expires: August 21st, 2005 H. Schulzrinne
Internet-Draft Columbia U.
February 21st,
Expires: September 12, 2005 J. Polk
Cisco
March 14, 2005

Communications Resource Priority for the Session Initiation Protocol
(SIP)
draft-ietf-sip-resource-priority-06
draft-ietf-sip-resource-priority-07

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, I certify each
author represents that any applicable patent or other IPR claims of
which I am he or she is aware have been or will be disclosed, and any of
which I he or she become aware will be disclosed, in accordance with
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 21st, September 12, 2005.

Abstract

This document defines two new SIP header fields for communicating
resource priority, namely "Resource-Priority" and "Accept-Resource-
Priority".
"Accept-Resource-Priority". The "Resource-Priority" header field can
influence the behavior of SIP user agents, such as telephone gateways
and IP telephones, and SIP proxies. It does not directly influence the
forwarding behavior of IP routers.

Polk &

Schulzrinne [page & Polk Expires September 12, 2005 [Page 1]

Internet-Draft SIP Resource Priority February 21st, March 2005

the forwarding behavior of IP routers.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 7
3. The Resource-Priority and Accept-Resource-Priority SIP
Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 6 7
3.1 The 'Resource-Priority' Header Field . . . . . . . . . . . 6 7
3.2 The 'Accept-Resource-Priority' Header Field . . . . . . . 7 8
3.3 Usage of the 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields . . . . . . . . . 7 9
3.4 The 'resource-priority' Option Tag . . . . . . . . . . . . 8 9
4. Behavior of SIP Elements that Receive Prioritized Requests . . 8 9
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 General Rules . . . . . . . . . . . . . . . . . . . . . . 9
4.2 10
4.3 Usage of Require Header with Resource-Priority . . . . . . . 9
4.3 11
4.4 OPTIONS Request with Resource-Priority . . . . . . . . . . . 9
4.4 Alternatives 11
4.5 Algorithms for Preferential Treatment of Requests . . . . 10
4.4.1 11
4.5.1 Preemption Policy . . . . . . . . . . . . . . . . . . . 10
4.4.2 . . . 12
4.5.2 Priority Queuing Policy Queueing . . . . . . . . . . . . . . . . 10
4.5 Rejection Messages . . 12
4.6 Error Conditions . . . . . . . . . . . . . . . . . . . . 11
4.6 Error Conditions . 13
4.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . 12
4.6.1 13
4.6.2 No Known Namespace and or Priority Value . . . . . . . . . 13
4.6.3 Authentication Failure . 12
4.6.2 Handling Unknown Namespaces and Priority Values . . . 12
4.7 User Agent Client Behavior . . . . . . . . . . . . 14
4.6.4 Authorization Failure . . . . 13
4.7.1 User Agent Client Behavior with a Preemption Policy . . 13
4.7.2 User Agent Client Behavior with a Priority Queue Policy 13
4.8 User Agent Server Behavior . . . . . . . . . . 14
4.6.5 Insufficient Resources . . . . . . 13
4.8.1 User Agent Servers and Preemption Policy . . . . . . . . 14
4.8.1 User Agent Servers and Priority-Queue Policy . . 14
4.6.6 Busy . . . . 14
4.9 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 15
4.7 Element-Specific Behaviors . 14
5. Third-Party Authentication . . . . . . . . . . . . . . . 15
4.7.1 User Agent Client Behavior . . . 15
6. Backwards Compatibility . . . . . . . . . . . 15
4.7.2 User Agent Server Behavior . . . . . . . . 15
7. Multiple Namespaces in a Message . . . . . . 16
4.7.3 Proxy Behavior . . . . . . . . 16
8. Namespace Definitions . . . . . . . . . . . . 17
5. Third-Party Authentication . . . . . . . . 18
8.1 Namespace Descriptions . . . . . . . . . . . 17
6. Backwards Compatibility . . . . . . . . 18
8.1.1 The "DSN" Namespace . . . . . . . . . . . 18
7. Examples . . . . . . . 18
8.1.2 The "DRSN" Namespace . . . . . . . . . . . . . . . . . . 19
8.1.3 The "Q735" Namespace . . 18
7.1 Simple Call . . . . . . . . . . . . . . . . 20
8.1.4 The "ETS" Namespace . . . . . . . 18
7.2 Receiver Does Not Understand Namespace . . . . . . . . . . 19
8. Handling Multiple Concurrent Namespaces . 20
8.1.5 The "WPS" Namespace . . . . . . . . . . 21
8.1 General Rules . . . . . . . . 22
8.2 Future Namespace Considerations . . . . . . . . . . . . . . 24
9. 21
8.2 Examples of Valid Orderings . . . . . . . . . . . . . . . 22
8.3 Examples of Invalid Orderings . . . . . . . . . . . . 25
9.1 Simple Call . . . 22
9. Registering Namespaces . . . . . . . . . . . . . . . . . . . . 25
9.2 Receiver Does Not Understand 23
10. Namespace Definitions . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . 24
10.1 Introduction . . . . . . . . . . 28
10.1 Authentication and Authorization . . . . . . . . . . . . . 29 24
10.2 Confidentiality and Integrity The "DSN" Namespace . . . . . . . . . . . . . . 30
10.3 Anonymity . . . . . 24
10.3 The "DRSN" Namespace . . . . . . . . . . . . . . . . . . . 31 25
10.4 Denial-of-Service Attacks The "Q735" Namespace . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . 25
10.5 The "ETS" Namespace . . . . . . . . . . . . . . . . . . 31
11.1 IANA Registration of 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields . 26

Schulzrinne & Polk Expires September 12, 2005 [Page 2]

Internet-Draft SIP Resource Priority March 2005

10.6 The "WPS" Namespace . . . . . . . . . 32
11.2 IANA Registration for Option Tag resource-priority . . . . 32

Polk & Schulzrinne [page 2]
Internet-Draft SIP Resource Priority February 21st, 2005

11.3 IANA Registration for Response Code 417 . . . . . . 26
11. Security Considerations . . . 32
11.4 IANA Namespace Registrations . . . . . . . . . . . . . . . 32
11.5 IANA Priority-Value Registrations 27
11.1 General Remarks . . . . . . . . . . . . 33
12. Acknowledgments . . . . . . . . . 27
11.2 Authentication and Authorization . . . . . . . . . . . . . 27
11.3 Confidentiality and Integrity . 33
13. References . . . . . . . . . . . . . 28
11.4 Anonymity . . . . . . . . . . . . . 34
13.1 Normative References . . . . . . . . . . . 29
11.5 Denial-of-Service Attacks . . . . . . . . 34
13.2 Informative References . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . 29
12.1 Introduction . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . 36

1. Introduction

During emergencies, communications resources including telephone
circuits, IP bandwidth and gateways between the circuit-switched . . . 29
12.2 IANA Registration of 'Resource-Priority' and
IP networks may become congested. Congestion can occur due to heavy
'Accept-Resource-Priority' Header Fields . . . . . . . . . 30
12.3 IANA Registration for Option Tag resource-priority . . . 30
12.4 IANA Registration for Response Code 417 . . . . . . . . . 31
12.5 IANA Resource-Priority Namespace Registration . . . . . . 31
12.6 IANA Priority-Value Registrations . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 32
14.2 Informative References . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . 36

Schulzrinne & Polk Expires September 12, 2005 [Page 3]

Internet-Draft SIP Resource Priority March 2005

1. Introduction

During emergencies, communications resources including telephone
circuits, IP bandwidth and gateways between the circuit-switched and
IP networks may become congested. Congestion can occur due to heavy
usage, loss of resources caused by the natural or man-made disaster
and attacks on the network during man-made emergencies. This
congestion may make it difficult for persons charged with emergency
assistance, recovery or law enforcement to coordinate their efforts.
As IP networks become part of converged or hybrid networks along with
public and private circuit-switched (telephone) networks, it becomes
necessary to ensure that these networks can assist during such
emergencies.

Also, users may want to interrupt their lower-priority communications
activities and dedicate their end system resources to the
high-priority communications attempt if a high-priority
communications request arrives at their end system.

There are many IP-based services that can assist during emergencies.
This memo only covers real-time communications applications involving
the Session Initiation Protocol (SIP) [RFC3261], including
voice-over-IP, multimedia conferencing, instant messaging and
presence.

SIP applications may involve at least five different resources that
may become scarce and congested during emergencies. These resources
include gateway resources, circuit-switched network resources, IP
network resources, receiving end system resources and SIP proxy
resources. IP network resources are beyond the scope of SIP
signaling and are therefore not considered here.

In order to improve emergency response, it may become necessary to
prioritize access to SIP-signaled resources during periods of
emergency-induced resource scarcity. We call this "resource
prioritization". The mechanism itself may well be in place at all
times, but only materially affect call handling during times of
resource scarcity.

Currently, SIP does not include a mechanism that allows a request
originator to indicate to a SIP element that it wishes the request to

Polk & Schulzrinne [page 3]
Internet-Draft SIP Resource Priority February 21st, 2005
invoke such resource prioritization. To address this need, this
document adds a SIP protocol element that labels certain SIP
requests.

This document defines (Section 3) a new SIP [RFC3261] header field for
communications resource priority, called 'Resource-Priority' 'Resource-Priority'. This
header field MAY be used by SIP user agents, including General
Switched Telephone

Schulzrinne & Polk Expires September 12, 2005 [Page 4]

Internet-Draft SIP Resource Priority March 2005

Switched Telephone Network (GSTN) gateways and terminals, and SIP
proxy servers to influence their treatment of SIP requests, including
the priority afforded to GSTN calls. For GSTN gateways, the behavior
translates into analogous schemes in the GSTN, for example the ITU
Recommendation Q.735.3 [Q.735.3] prioritization mechanism, in both
the GSTN-to-IP and IP-to-GSTN directions. ITU Recommendation I.255.3
[I.255.3] is another example.

The 'Resource-Priority' header field may be used in several
situations.

A SIP request with such an a 'Resource-Priority' indication can be treated
differently in these situations:

1. The request can be given elevated priority for access to GSTN
gateway resources such as trunk circuits.
2. The request can interrupt lower-priority requests at a user
terminal, such as an IP phone.
3. 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.
4. In SIP proxies and back-to-back user agents, requests of higher
priorities may delay, reject or error displace existing signaling requests
of or bypass
GSTN gateway capacity limits in effect for lower priorities.

This header field is related to, but differs in semantics from, the
'Priority' header field (RFC 3261 [RFC3261], ([RFC3261], Section 20.26). The 'Priority'
header field describes the importance that the SIP request should
have to the receiving human or its agent. For example, that header
may be factored into decisions about call routing to mobile devices
and assistants and call acceptance when the call destination is busy.
The 'Priority' header field does not affect the usage of GSTN gateway
or proxy resources, for example. In addition, any User Agent Client
(UAC) can assert any 'Priority' value, while access to
resource priority usage of
'Resource-Priority' header field values are is subject to authorization.

While the 'Resource-Priority' header field does not directly
influence the forwarding behavior of IP routers or the use of
communications resources such as packet forwarding priority,
procedures for using this header field to cause such influence may be
defined in other documents.

Existing implementations of RFC 3261 that do not participate in the

Polk & Schulzrinne [page 4]
Internet-Draft SIP Resource Priority February 21st, 2005
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." Thus, the use
of this mechanism is wholly invisible to existing implementations
unless the request includes the Require header field with the

Schulzrinne & Polk Expires September 12, 2005 [Page 5]

Internet-Draft SIP Resource Priority March 2005

resource-priority option tag.

The mechanism described here can be used for emergency preparedness
in emergency telecommunications systems, but is only a small part of
an emergency preparedness network and is not restricted to such use.

The mechanism aims to satisfy the requirements in [RFC3487]. It is
structured so that it works in all SIP and Real-Time Transport
Protocol (RTP) [RFC3550] transparent networks defined in [RFC3487].
In such networks, all network elements and SIP proxies let valid SIP
requests pass through unchanged. This is important since it is
likely that this mechanism will often be deployed in networks where
the edge networks are unaware of the resource priority mechanism and
provide no special privileges to such requests. The request then
reaches a GSTN gateway or set of SIP elements that are aware of the
mechanism.

For conciseness, we refer to SIP proxies and user agents (UAs) that
act on the 'Resource-Priority' header field as RP actors.

Government entities and standardization bodies have developed several
different priority levels for their networks. Users would like to be
able to obtain authorized priority handling in several of these
networks, without changing SIP clients. Also, a single call may
traverse SIP elements that are run by different administrations and
subject to different priority mechanisms. Since there is no global
ordering among those priorities, we allow each request to contain
more than one priority value drawn from these different priority
lists, called a namespace in this document. Typically, each SIP
element only supports one such namespace, but we discuss what happens
if an element needs to support multiple namespaces in Section 8.

Since gaining prioritized access to resources offers opportunities to
deny service to others, it is expected that all such prioritized
calls are subject to authentication and authorization, using standard
SIP security mechanisms (Section 11).

The remainder of this document is structured as follows. After
defining terminology in Section 2, we define the syntax for the two
new SIP header fields in Section 3 and then describe protocol
behavior in Section 4. The two principal mechanisms for
differentiated treatment of SIP requests, namely preemption and
queuing, are described in Section 4.4. Rejection messages 4.5. Error conditions are covered
in Section 4.5, error conditions in Section 4.6. Section 4.7 4.7.1 through Section 4.9 4.7.3 detail the
behavior of specific SIP elements. Third-party authentication is
briefly summarized in Section 5. Section 6 describes how this
feature affects existing systems that do not support it. Sections 7 and 8 delve into namespace issue,
namely their general properties, how to deal with

Schulzrinne & Polk Expires September 12, 2005 [Page 6]

Internet-Draft SIP Resource Priority March 2005

Since calls may traverse multiple administrative domains with
different namespaces on or multiple elements with the same SIP element and in namespace, it
is important that all such domains and elements apply the same SIP message,
as well
algorithms for the same namespace as enumerating otherwise the end-to-end
experience of privileged users may be compromised. For example, if
one element in the call path chooses to use preemption, while another
chooses queueing, calls may experience inconsistent service.

Section 9 enumerates the information that namespace registrations
need to provide. Section 8 discusses what happens if a request
contains multiple namespaces or an element can handle more than one
namespace. Section 10 defines the properties of five namespaces that
are registered through this document. Protocol examples are given in
Section 9. 7. Security issues are considered in Section 10, 11, but this
document does not define new security mechanisms. Section 12
discusses 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

Polk & Schulzrinne [page 5]
Internet-Draft SIP Resource Priority February 21st, 2005
implementations.

3. The Resource-Priority and Accept-Resource-Priority SIP Header Fields

This document section defines the 'Resource-Priority' and
'Accept-Resource-Priority' SIP header field syntax. Behavior is
described in Section 4..

The SIP element behavior is described for user agent clients (UACs)
in Section 4.7, for UAS in Section 4.8 and for SIP proxy servers in
Section 4.9. 4.

3.1 The 'Resource-Priority' Header Field

The 'Resource-Priority' request header field marks a SIP request as
desiring prioritized access to resource, as described in the
introduction. In
responses, the 'Resource-Priority' header fields indicates the actual
resource priority that was granted to the request. While it is
likely those responses contain the same 'Resource-Priority' header
field value as the requests, local policy MAY call for the UAS to
insert no header field or a different value.

There is no protocol requirement that all requests within a SIP
dialog or session use the 'Resource-Priority' header field. Local
administrative policy MAY mandate the inclusion of the 'Resource-
Priority'
'Resource-Priority' header field in all requests. Implementations of
this specification MUST allow inclusion to be either by explicit user
request or automatic. automatically for all requests.

The syntax of the 'Resource-Priority' header field is described
below. The "token-nodot" production is copied from [RFC3265].

Schulzrinne & Polk Expires September 12, 2005 [Page 7]

Internet-Draft SIP Resource Priority March 2005

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 'Resource-Priority' header field is shown below:

Resource-Priority: dsn.flash

The 'Resource-value' 'r-value' parameter in the 'Resource-Priority' header field
indicates the resource priority desired by the request originator.
Each resource value (r-value) is formatted as 'namespace' '.'
'priority value'. The value is drawn from the namespace identified
by the 'namespace' token. Namespaces and priorities are
case-insensitive ASCII tokens that do not contain periods. Thus, �dsn.flash�
"dsn.flash" and

Polk & Schulzrinne [page 6]
Internet-Draft SIP Resource Priority February 21st, 2005

�DSN.Flash�, "DSN.Flash", for example, are equivalent. Each
namespace has at least one priority value. Namespaces and priority
values within each namespace MUST be registered with IANA (Section 11).
12). Initial namespace registrations are described in Section 11.4. 12.5.

Since a request may traverse multiple administrative domains with
multiple different namespaces, it is necessary to be able to
enumerate several different namespaces within the same message.
However, a particular namespace MUST NOT appear more than once in the
same SIP message. These may be expressed equivalently as either
comma-separated lists within a single header field, as multiple
header fields or some combination. The ordering of r-values 'r-values' within
the header field has no significance. Thus, for example, the
following three header snippets are equivalent:

Resource-Priority: dsn.flash, wps.3

Resource-Priority: wps.3, dsn.flash

Resource-Priority: wps.3
Resource-Priority: dsn.flash

3.2 The 'Accept-Resource-Priority' Header Field

The 'Accept-Resource-Priority' response header field enumerates the
resource values (r-values) a SIP user agent server is willing to
accept. The syntax of the 'Accept-Resource-Priority' header field is
as follows:

Schulzrinne & Polk Expires September 12, 2005 [Page 8]

Internet-Draft SIP Resource Priority March 2005

Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON
[r-value *(COMMA r-value)]

An example is given below:

Accept-Resource-Priority: dsn.flash-override,
dsn.flash, dsn.immediate, dsn.priority, dsn.routine

Some administrative domains MAY choose to disable the use of the
Accept-Resource-Priority
'Accept-Resource-Priority' header as revealing too much information
about that domain in responses. However, this behavior is NOT
RECOMMENDED, as this header field aids in troubleshooting.

3.3 Usage of the 'Resource-Priority' and 'Accept-Resource-Priority'
Header Fields

The following table extends the values in Table 2 of RFC3261
[RFC3261]. (The PRACK method, labeled as PRA, is defined in
[RFC3262], the SUBSCRIBE (labeled SUB) and NOTIFY (labeled NOT)
methods in [RFC3265], the UPDATE (UPD) method in [RFC3311], the
MESSAGE (MSG) method in [RFC3428], the REFER (REF) method in

Polk & Schulzrinne [page 7]
Internet-Draft SIP Resource Priority February 21st, 2005
[RFC3515], the INFO (INF) method in [RFC2976], and the PUBLISH (PUB)
method is in [RFC3903].)

Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Resource-Priority r amdr o o o o o o o
Resource-Priority 200 amdr 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
Accept-Resource-Priority 420 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
Resource-Priority r amdr o o o o o o o
Resource-Priority 200 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 o
Accept-Resource-Priority 420 amdr o o o o o o o

Other request methods MAY define their own handling rules; unless
otherwise specified, recipients MAY ignore these header fields.
The 'Accept-Resource-Priority' SHOULD be returned in 420 (Bad
Extension) responses marked as 'o' in table above if the element
implements the resource priority mechanism with some other
namespaces or priority values, but does not implement the particular
namespace or priority value contained in this current request.

3.4 The 'resource-priority' Option Tag

This document also defines the "resource-priority" option tag. The
behavior is described in Section 4.2. 4.3. and the IANA registration is
in Section 11.2. 12.3.

4. Behavior of SIP Elements that Receive Prioritized Requests

Schulzrinne & Polk Expires September 12, 2005 [Page 9]

Internet-Draft SIP Resource Priority March 2005

4.1 Introduction

All SIP user agents and proxy servers that support this specification
share certain common behavior, which we describe below in Section 4.1.
4.2. The behavior when encountering a 'resource-
priority' 'resource-priority' option tag
in a 'Require' header field is describe in Section 4.2. 4.3. Section 4.3 4.4
describes the treatment of OPTIONS requests. The two fundamental
resource contention resolution mechanisms, preemption and queuing, queueing,
are described in Section 4.4.
Rejection 4.5. Section 4.6 explains what happens when
requests fail. Behavior specific to user agent clients is covered in
section 4.7, for user agent clients, servers and
proxy servers are covered in Section 4.8, while Section
4.9 deals with proxy behavior.

Polk & Schulzrinne [page 8]
Internet-Draft SIP Resource Priority February 21st, 2005

4.1 4.7.

4.2 General Rules

The Resource-Priority 'Resource-Priority' header field is potentially applicable to all
SIP request messages. At a minimum, implementations of the following
request types MUST support the Resource-Priority header to be in
compliance with this specification:

o INVITE [RFC3261]
2)
o ACK [RFC3261]
3)
o PRACK [RFC3262]
4)
o UPDATE [RFC3311]
5)
o REFER [RFC3515]

and

Implementations SHOULD support the Resource-Priority 'Resource-Priority' header field
in the following request types (if the SIP element does) to be in compliance with
this specification:

6) types:

o MESSAGE [RFC3428]
7)
o SUBSCRIBE [RFC3265]
8)
o NOTIFY [RFC3265]

Note that this does not imply that all implementations have to
support every
request method all requests methods listed.

If a SIP element receives the Resource-Priority 'Resource-Priority' header field in a Request
message
request other than what is those listed above, the header MAY be ignored,
according to the foundational rules of [RFC3261].

4.2 Usage of Require Header with Resource-Priority

Following standard SIP behavior,

In short, an RP actor performs the following steps when receiving a
prioritized request. Error behavior is described in Section 4.6.

1. Determine if system resources are currently sufficiently scarce
that an unprioritized requesst would be denied immediate
handling. If not, treat the request like a regular SIP request contains
and skip the
Require header field with remaining steps. If there are no namespaces
recognized by the �resource-priority� option tag, a SIP
element MUST respond with a 420 (Bad Extension) RP actor, treat the request as if it does not
support the SIP extensions described in this document. had no
'Resource-Priority' header field.

Schulzrinne & Polk Expires September 12, 2005 [Page 10]

Internet-Draft SIP Resource Priority March 2005

2. If the request does not contain appropriate credentials, request
such credentials, e.g., by challenging the user using Digest
authentication.
3. If the request is authenticated, select a resource priority value
with a namespace supported by the RP actor and determine if the
user is authorized to access that level. If not, reject the
request.
4. If the request is authorized, preempt other current requests or
insert 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 contains the
'Require' header field with the 'resource-priority' option tag, a SIP
element MUST respond with a 420 (Bad Extension) if it does not
support the SIP extensions described in this document. It then lists
�resource-priority�
"resource-priority" in the �Unsupported� 'Unsupported' header field included in the
response.

The use of the 'resource-priority' option tag in 'Proxy-Require'
header field is NOT RECOMMENDED.

4.3

4.4 OPTIONS Request with Resource-Priority

An OPTIONS request can be used to determine if an element supports
the mechanism. A compliant implementation MUST return a
'Accept-Resource-Priority' header field in OPTIONS responses
enumerating all valid resource values. An RP actor MAY be configured
not to return such values or only return them to authorized
requestors.

Note

Following standard SIP behavior, OPTIONS responses MUST include the
'Supported' header field that according includes the 'resource-priority' option
tag.

According to RFC 3261, Section 11, proxies reached that receive a request
with a Max-Forwards

Polk & Schulzrinne [page 9]
Internet-Draft SIP Resource Priority February 21st, 2005 'Max-Forwards' header field value of zero MAY answer the
OPTIONS request, allowing a UAC to discover the capabilities of both
proxy and user agent servers.

4.4 Alternatives

4.5 Algorithms for Preferential Treatment of Requests

SIP elements may use the resource priority mechanism to modify a
variety of behavior such as routing requests, authentication
requirements or logging. The resource priority mechanism may
influence the treatment of the request itself or of the session
created by the request. We (Here, we use the terms session and call

Schulzrinne & Polk Expires September 12, 2005 [Page 11]

Internet-Draft SIP Resource Priority March 2005

interchangeably in this document, both implying a continuous data
stream between two or more parties. Sessions are established by SIP
dialogs.
dialogs.)

Below, we define two common policies, algorithms, namely preemption and
priority
queuing. queueing. Preemption applies only to sessions created by
SIP requests, while both sessions and request handling can be subject
to priority queuing. queueing. Both policies algorithms can sometimes be combined in
the same element, although none of the namespaces described in this
document do this. Policies Algorithms can be defined for each namespace or,
in some cases, can be specific to an administrative domain.

Naturally, only SIP elements that understand this mechanism and the
namespace and resource value perform these policies. algorithms. Section 4.8 4.6.2
discusses what happens if an RP actor does not understand namespaces
or priority
values contained in a request.

4.4.1

4.5.1 Preemption Policy

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 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.

[I-D.ietf-sipping-reason-header-for-preemption] for contains more details
and examples of this behavior.

UAS behavior for preemption is discussed in Section 4.8.

4.4.2 4.7.2.

4.5.2 Priority Queuing Policy Queueing

In a priority queuing queueing policy, requests that find no available
resources are queued on a first-come, first-served basis 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, a the RP actor selects the request from the
highest-priority non-empty queue with according to the
highest priority is served. Each queue can hold a finite number of

Polk & Schulzrinne [page 10]
Internet-Draft SIP Resource Priority February 21st, 2005 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 queue for a newly
arriving request is full, the request is rejected immediately. In
addition, a priority queuing queueing policy MAY impose a residence waiting time limit. If a request exceeds limit
for each priority class, where requests that exceed a specified

Schulzrinne & Polk Expires September 12, 2005 [Page 12]

Internet-Draft SIP Resource Priority March 2005

waiting time, the RP actor then rejects time are ejected from the request queue and
removes it from a failure response is
returned to the queue. requestor.

In addition, an RP actor MAY impose a global queue size limit summed
across all queues and drop waiting lower-priority requests. This
does not imply preemption since the session has not been established
yet.

Often, normal, non-prioritized requests will not be queued, i.e.,

4.6 Error Conditions

4.6.1 Introduction

In this section, we describe the queue size for such requests is zero.

4.5 Rejection Messages

The following is a list of rejections to SIP messages error behavior that contain a
Resource-Priority header specifically because is shared among
multiple types of the contents RP actors, including various instances of the
header.

If a UA is currently occupied with another session UAS such
as trunk gateways, line gateways and receives a
dialog generating message IP phones, and proxies.

A request containing a valid Resource-Priority
header of equal or lower relative resource priority value, indication can fail for four
reasons: the response RP actor does not understand the priority value
(Section 4.6.2), the requestor is not authenticated (Section 4.6.3),
an authenticated requestor is not authorized to make such a request
(Section 4.6.4) or there are insufficient resources for an authorized
request (Section 4.6.5). We treat these error cases in the same as stated order
that they typically arise in section 13.3.1.3 the processing of [RFC3261]:

- a 486 (Busy Here) requests with
Resource-Priority headers. However, this order is returned if the UAS not mandated. For
example, an RP actor that knows it that a particular resource value
cannot be served or will
not accept the request,

- queued MAY, as a 600 (Busy Everywhere) is returned if matter of local policy, forego
authorization since it would only add processing load without
changing the UAS knows there are no
other SIP elements that can accept outcome.

4.6.2 No Known Namespace or Priority Value

If an RP actor does not understand any of the INVITE, and

- a 488 (Not Acceptable Here) if resource values in the UAS is rejecting
request, the INVITE.

[RFC3261] advises that a 488 response SHOULD include a warning 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 a reason for the rejection.

If default priority.
2. With the message from option tag, it MUST reject the UAC contains request with a known namespace, and 417
(Unknown Resource-Priority) response code.

Making case (1) the
priority-value is higher than is authorized, this error condition default is
addressed necessary since otherwise there would
be no way to successfully complete any calls in the next subsection (4.6).

In the case in which where a
proxy on the way to the UAS is currently occupied shares no common namespaces with another
session and receives an INVITE containing a valid Resource-Priority
header of higher relative priority than that of the current dialog,
this does not create an error condition. The UAS will act according
to UAC,
but the behaviors defined for that UAC and UAS do have such a namespace within that
administrative domain. Section 8.1.1 through 8.1.5 define the rules
for in common.

If a resource value is understood, the 5 namespaces resource values that are created with this document.

It can also not
understood MUST NOT be stated that if modified, deleted or cause a Proxy Server is currently
experiencing processing difficulties (perhaps due to overload
conditions), this is an error condition that will be addressed in

Polk & rejection of the

Schulzrinne [page 11] & Polk Expires September 12, 2005 [Page 13]

Internet-Draft SIP Resource Priority February 21st, March 2005

section 4.6.1.

4.6 Error Conditions

4.6.1 Known Namespace and Priority Value

Two error conditions

message.

In general, as noted, a SIP request can occur contain more than one
'Resource-Priority' header field. This is necessary if a request reaches an element that
supports
needs to traverse different administrative domains, each with their
own set of valid resource values. For example, the ETS namespace and resource priority. Elements receiving
requests with namespaces or priority values
might be enabled for United States government networks that they do not
understand act 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 rules in acceptable resource values.

4.6.3 Authentication Failure

If the next section.

Insufficient authorization: request is not authenticated, a 401 (Unauthorized) or 407
(Proxy Authentication Required) response is returned to allow the
requestor to insert appropriate credentials.

4.6.4 Authorization Failure

If the element RP actor receives a 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 resources: resource conditions can occur on proxy servers and user
agent servers, typically trunk gateways. If there are an RP actor receives an
authorized request, has insufficient resources at an
element for a given priority, a request might be delayed or
refused, depending on local policy or the definition of and the
namespace. If it request
neither preempts another request nor is refused, queued. A request can fail
either because the element returns a 503 (Service
Unavailable) response. The response MAY also include a 'Warning'
header with warning code 370 (Insufficient Bandwidth) if RP actor has insufficient processing capacity to
handle the SIP request failed due to or insufficient bandwidth or trunk capacity to
establish the requested session for session-creating SIP requests.

If the media streams,
rather than insufficient signaling capacity.

The 503 (Service Unavailable) response provides sufficient
indication to request fails since the originator to re-attempt RP actor cannot handle the signaling
load, the RP actor responds with a higher
appropriate resource priority 503 (Service Unavailable).

If there is not enough bandwidth or if no Resource-Priority header
was present in an insufficient number of trunks,
a 488 (Not Acceptable Here) response indicates that the RP actor is
rejecting the original request (which may be local policy
not to include one for normal level calls), to add reasons of media path availability, such as
insufficient gateway resources. In that case, [RFC3261] advises that
a resource
priority indication, if authorized.

4.6.2 Handling Unknown Namespaces and Priority Values

When handling requests with unknown namespaces or priority values,
elements will operate according to local policy. Some
administrative domains will openly reject with 488 response SHOULD include a 417 (Unknown
Resource-Priority) Response message regardless of whether the
namespace or 'Warning' header field (or both) are not known, giving no further
details to the requestor. Other administrative domains will return
417 (Unknown Resource-Priority) Response with an Accept-Resource-
Priority header indicating which valid namespace(s) and priority-
value(s) are "good" within that domain. As previously stated, a
single SIP message can have more than one Resource-Priority header.
If one header is understood, the remaining Resource-Priority headers
SHOULD NOT be modified, deleted or cause a rejection of the message.
The reason
for this is that there will be cases where multiple
namespaces will be necessary for end-to-end communications.
Allowing multiple instances of the header in the same message allows the message to traverse multiple administrative domains - without

Polk & rejection, with warning code 370 (Insufficient Bandwidth)
typical.

Schulzrinne [page 12] & Polk Expires September 12, 2005 [Page 14]

Internet-Draft SIP Resource Priority February 21st, March 2005

each having to know about the policy of

For systems implementing queueing, if the other(s) - all while
providing a valid resource-Priority per administrative domain. An
example of this request is queued, the case where the ETS namespace UAS
will be enabled
by return 408 (Request Timeout) if the US Government networks (used by very few individuals within
that administrative domain) that also support request exceeds the DSN and/or DRSN
namespaces for most (if not all) individuals maximum
configured waiting time in those domains.
These namespaces queue.

If the originator did not include a 'Resource-Priority' header field,
these error responses will be defined later in this document.

Some SIP elements MAY allow process messages provide the necessary indication to do so.
(In some administrative domains, requests with unknown Resource-
Priority headers without returning normal priority will
not include the 'Resource-Priority' header field.) In addition, if
authorized, the requestor may also attempt to use a 417. This higher resource
priority value.

4.6.6 Busy

Resource contention also occurs when a call request arrives at a UAS
that is unable to accept another call, either because the UAS has
just one line presence or has active calls on all line presences. If
the call request indicates an equal or lower priority value 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 408 (Request
Timeout) if the request exceeds the maximum configured waiting time
in the device queue.

If a matter of local
policy. 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) is received, response, the UAC
MAY attempt a subsequent request with the same combination
of namespace/priority-value, or the retry the request with a different set of namespace/priority combinations, drawing resource
value. If available, it SHOULD choose authorized resource values
from the set of values returned by in the 'Accept-Resource-Priority'
header field in
the response, if included, and if authorized for that user.

4.7.1 field.

4.7.1.1 User Agent Client Behavior with a Preemption Policy Algorithm

A UAC in an administrative domain that employs preemption MUST be
prepared to receive a BYE Request request with a Reason header explaining why
the session was terminated.

[I-D.ietf-sipping-reason-header-for-preemption] discusses this.

4.7.2 User Agent Client Behavior with a Priority Queue terminated, as discussed in

Schulzrinne & Polk Expires September 12, 2005 [Page 15]

Internet-Draft SIP Resource Priority March 2005

[I-D.ietf-sipping-reason-header-for-preemption].

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 has put the original request into a queue. This A UAC
SHOULD 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.8

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.

Polk & Schulzrinne [page 13]
Internet-Draft SIP Resource Priority February 21st, 2005

4.8.1

4.7.2.1 User Agent Servers and Preemption Policy 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 'Reason' header field indicating why/where 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.

[I-D.ietf-sipping-reason-header-for-preemption] 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).
That The
mechanisms in that document offers several reasons for allow to indicate where the termination
occurred ('at the UA', 'in the network', 'at a IP/PSTN gateway'), and
includes call flow examples of each reason.

4.8.2

4.7.2.2 User Agent Servers and Priority-Queue Queue-based Policy

A UAS compliant with this specification SHOULD generate a 182
(Queued) Response response if that element's resources are busy, until it is
able to handle the request and provide a final response.

Schulzrinne & Polk Expires September 12, 2005 [Page 16]

Internet-Draft SIP Resource Priority March 2005

Local policy will determine additional behaviors of a queue-based SIP
element. However, the frequency of provisional messages indicated in
[RFC3261] still need to apply to keep each session set-
up set-up active
until successful or rejected.

4.9

4.7.3 Proxy Behavior

SIP proxies MAY ignore or inspect the 'Resource-Priority' header field. SIP
proxies MAY reject any unauthenticated request bearing
the that header
field.

A compliant SIP Server experiencing a processing queue due to
excessive load MUST process messages containing higher relative
priority-values up to the queue

When the 'Require' header indicates on a FIFO basis
based on the arrival time of the message. It is conceivable
that priority-levels within a proxy are grouped to include more than
one level per queue. This is included in a matter of local policy. message, it ensures that
in parallel forking, only branches that support the resource-priority
mechanism succeed.

If a Proxy S/MIME encapsulation is expecting a message used according to have a 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 the header thus
is protected via S/MIME encapsulation in a SIP
message fragment [RFC3420], the Proxy MUST return an error response.
Therefore, exempted by the use of SIPFRAG integrity checking described in administrative domains with this
type Section 23.4.1.1
of policy is not recommended. RFC 3261. Since it may need to be inspected or modified by
proxies, the header field SHOULD also be placed in the "outer"
message. Similar considerations apply if parts of the message are
integrity-protected or encrypted as described in [RFC3420].

If no S/MIME is used, 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'

Polk & Schulzrinne [page 14]
Internet-Draft SIP Resource Priority February 21st, 2005
header if allowed by local policy.

This behavior is similar to that for any header field, as a UA can
decide to reject a request for the presence, absence or value of any
information in the request.

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 avoid that prevent colluding user agents
from artificially raise 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.

When the 'Require' header is included in a message, it ensures that
in parallel forking, only branches that support the resource-
priority mechanism succeed.

There are not additional no special considerations for proxies when forking requests that contain
containing a resource priority indication.

Otherwise, the proxy behavior is the same as for user agent servers
described in Section 4.7). 4.7.2.

5. Third-Party Authentication

In some cases, the RP actor may not be able to authenticate the

Schulzrinne & Polk Expires September 12, 2005 [Page 17]

Internet-Draft SIP Resource Priority March 2005

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 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.

Introducing 'Require' or 'Proxy-Require' would not help backwards
compatibility, as systems that do not support these mechanism

7. Examples

The SDP message body and the BYE and ACK exchanges are no
better off rejecting the request due same as in
RFC 3665 [RFC3665] and 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 feature failure. Since the

Polk & Schulzrinne [page 15]
Internet-Draft SIP Resource Priority February 21st, 2005

intent of User B directly. The
call from A to B is marked with a resource priority indications is to increase the
probability of call completion, adding failure modes appears
counterproductive.

7. Multiple Namespaces in a Message

There are two cases where multiple namespaces might occur. Namely,
a single RP actor may 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

Schulzrinne & Polk Expires September 12, 2005 [Page 18]

Internet-Draft SIP Resource Priority March 2005

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
Resource-Priority: dsn.flash
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
Resource-Priority: dsn.flash
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 more than one the "dsn"
namespace and thus returns a SIP
request may contain more than one resource value from different
namespaces. As noted earlier, 417 (Unknown Resource-Priority) status
code. We omit the order of resource values in a
SIP request is immaterial.

o If a message details for messages F5 through F7 since

Schulzrinne & Polk Expires September 12, 2005 [Page 19]

Internet-Draft SIP element understands multiple namespaces, it must create
a total ordering across all resource values from these
namespaces, maintaining the relative ordering within each
namespace. It is RECOMMENDED that Resource Priority March 2005

they are essentially the same ordering is used
across an administrative domain.

o If a 'Resource-Priority' header contains multiple namespaces, the
RP actor MUST select one resource value, typically the one with
the highest ranking.

o If a SIP element supports this specification and the request
includes a 'Require' header field with the 'Resource-Priority'
option tag, it MUST be possible to configure a UAS to copy the
Resource-Priority header value or values from the Request to the
Response without changing any field values (this means the
Offerer is in control of this header's value within an
administrative domain).

This rule MUST be followed even if multiple instances of the
Resource-Priority header exist as in a Request, unless the UAS lacks
the authorization to copy unknown header fields. first example.

User A User authorization
of priority-values within a namespace is outside the scope of this
document.

Here is a series of examples (both good and bad) of a SIP element
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
| |
| 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 (lowest).

The following are 3 lists of acceptable priority orders the SIP
element MAY process are:

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)

Polk & Schulzrinne [page 16]
Internet-Draft SIP Resource Priority February 21st, 2005

Bar.C (Highest Priority)
Foo.3 Bar.B <= both are equivalently processed FIFO)
or Foo.2 Bar.A <= both are equivalently processed FIFO)
Foo.1 (Lowest Priority)

Bar.C (Highest Priority)
Foo.3
or Foo.2
Foo.1 (Lowest Priority)
Where Bar.A and Bar.B are ignored within this example administrative
Domain;

Based on the stated priority order of each namespace above, the
following (non-inclusive list of) combinations 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

In Example 1 above, Bar.A is ordered higher than Bar.B - which is
not consistent within the order of the namespace of this section.

In Example 2 above, Bar.A is ordered higher than Bar.B and Bar.C -
which is not consistent within the order of the namespace of this
section.

In Example 3 above, Foo.1 is ordered higher than Foo.2 and Foo.3 -
which is not consistent within the order of the namespace of this
section.

In Example 4 above, Foo.1 is ordered higher than Foo.3 and Foo.2 is
ignored - which is not consistent within the order of the namespace
of this section.

Polk & Schulzrinne [page 17]
Internet-Draft SIP Resource Priority February 21st, 2005

8. Namespace Definitions

This specification defines five unique namespaces below: dsn, drsn,
q735, ets and wps, constituting their registration with IANA. Each
IANA registration contains:

1) The namespace label, a unique namespace label within the IANA
registry for the Resource-Priority header;

2) Number of Priority levels - the number of relative priority
levels the namespace has defined;

3) The "Intended Operation" - identifying whether the namespace is
to be used with priority queuing or preemption;

4) Any new Rejection codes or behaviors unique to the namespace
being defined

5) Any new Error codes specific to the namespace being defined

6) The IETF Reference document specifying the parameters and
specifications of the namespace, the listing of the priority-
values in relative order, any new rejection messages, and any new
error codes or error behaviors.

8.1 Namespace Descriptions

8.1.1 The "DSN" Namespace

The DSN namespace comes from the name of a US Government network
called "The Defense Switched Network".

The DSN namespace has a finite list of relative priority-values
listed here in the order of lowest priority to highest priority:

(lowest) dsn.routine
dsn.priority
dsn.immediate
dsn.flash
(highest) dsn.flash-override

In compliant administrative domains utilizing the dsn namespaces,
the UAS MUST copy the Resource-Priority header priority-values from
the Request to the Response for every header in the message unless
the UAS lacks local authorization to copy certain
namespace.priority-value combinations.

The dsn namespace introduces no new error behaviors.

The IANA Considerations section will have the following entry for
the DSN namespace:

Polk & Schulzrinne [page 18]
Internet-Draft SIP Resource Priority February 21st, 2005

Intended New New Error
Namespace Levels Operation Rej. code code Reference
--------- ------ ---------------- --------- ---- ---------
dsn 5 preemption-based no no [This RFC]

8.1.2 The "DRSN" Namespace

The DRSN namespace comes from the name of a US Government network
called "The Defense RED Switched Network".

The DRSN namespace has a finite list of relative priority-values
listed here in the order of lowest priority to highest priority:

(lowest) drsn.routine
drsn.priority
drsn.immediate
drsn.flash
drsn.flash-override
(highest) drsn.flash-override-override

One unique facet regarding the DRSN namespace relative to the DSN
and Q735 namespaces is the behavior of SIP elements with regard to
the 6th priority-value:

drsn.flash-override-override

This is the highest relative priority-value within the DRSN
namespace, but it is only to be used at this higher level in message
processing in SIP Proxies, and dialog establishment in SIP UAs
(including gateways). In any UAS, once the session is established
at the drsn.flash-override-override priority level, it defends that
dialog with a priority level of drsn.flash-override only; thus
allowing a new drsn.flash-override-override to preempt any existing
session. This behavior MUST be followed to be compliant with this
specification.

In compliant administrative domains utilizing the drsn namespaces,
the UAS MUST copy the Resource-Priority header priority-values from
the Request to the Response for every header in the message unless
the UAS lacks local authorization to copy certain (perhaps
restricted) namespace.priority-value combinations.

The drsn namespace operates on the preemption policy.

The drsn namespace introduces no new error behavior.

The IANA Considerations section will have the following entry for
the DRSN namespace:

Polk & Schulzrinne [page 19]
Internet-Draft SIP Resource Priority February 21st, 2005

Intended New New Error
Namespace Levels Operation Rej. code code Reference
--------- ------ ---------------- --------- ---- ---------
drsn 6 preemption-based no no [This RFC]

8.1.3 The "Q735" Namespace

The Q735 namespace is defined here as Q.735.3 was defined, namely as
operationally equivalent to the DSN specification for MLPP. Q.735.3
was created to be a commercial version of the same specification.

The Q735 namespace has a finite list of relative priority-values
listed here in the order of lowest priority to highest priority:

(lowest) q735.4
q735.3
q735.2
q735.1
(highest) q735.0

In compliant administrative domains utilizing the q735 namespaces,
the UAS MUST copy the Resource-Priority header priority-values from
the Request to the Response for every header in the message unless
the UAS lacks local authorization to copy certain (perhaps
restricted) namespace.priority-value combinations.

The q735 namespace operates according to the preemption policy.

The q735 namespace introduces no new error behaviors.

The IANA Considerations section will have the following entry for
the Q735 namespace:

Intended New New Error
Namespace Levels Operation Rej. code code Reference
--------- ------ ---------------- --------- ---- ---------
q735 5 preemption-based no no [This RFC]

8.1.4 The "ETS" Namespace

The ETS namespace derives its name indirectly from the name of the
US Government Telecommunications Service called "Government
Emergency Telecommunications Service" (or GETS), though the
organization responsible for the GETS service chose the acronym
"ETS" for its GETS over IP service, which stands for "Emergency
Telecommunications Service".

The ETS namespace has a finite list of relative priority-values
listed here in the order of lowest priority to highest priority:

Polk & Schulzrinne [page 20]
Internet-Draft SIP Resource Priority February 21st, 2005

(lowest) ets.4
ets.3
ets.2
ets.1
(highest) ets.0

The ets namespace operates according to the priority queuing policy.
ETS-based administrative domains will not queue normal, non-
prioritized requests.

ETS-based administrative domains will not queue normal, non-
prioritized messages. If a queue depth exists, the messages will be
rejected according to section 4.5.

A UAS within this type of administrative domain SHOULD be
configurable to limit the number of requests in a queue. One of two
different ways of limiting the queue depth is RECOMMENDED:

1) having a maximum number within a queue (perhaps with a different
number queued per priority-level), and

2) consider all requests above the default level to be in a single
queue on a FIFO basis (for example, based on the reception
timestamp of the request)

A UAS within this type of administrative domain SHOULD be
configurable to limit the time a request sits in a queue. One of
two different ways of limiting the time in queue is RECOMMENDED:

1) having a maximum time within a queue (perhaps with a different
time per priority-level) before a/each message moves into a
rejection condition discussed in section 4.5., and

2) considering all requests above the default level in a single
queue on a FIFO basis (for example, based on the reception
timestamp of the request), all with the same maximum time in
queue before a/each message moves into a rejection condition
discussed in section 4.5.

Local policy will determine additional behaviors of a queue-based
SIP element. However, the frequency of provisional messages
indicated in [RFC3261] still need to apply to keep each session set-
up active until successful or rejected.

A compliant SIP Server experiencing a processing queue due to
excessive load MUST move the messages containing higher relative
priority-values up to the queue the header indicates on a FIFO basis
based on the arrival time of the message (as there may be more than
one message at the same level already in queue). It is conceivable
that priority-levels within a proxy are grouped to include more than
one level per queue. This is a matter of local policy.

Polk & Schulzrinne [page 21]
Internet-Draft SIP Resource Priority February 21st, 2005

In compliant administrative domains utilizing the ets namespaces,
the UAS MUST copy the Resource-Priority header priority-values from
the Request to the Response for every header in the message unless
the UAS lacks local authorization to copy certain (perhaps
restricted) namespace.priority-value combinations.

Additional ETS policy is left to domain administrators, and to
future efforts.

The ets namespace does not define new error behaviors.

The IANA Considerations section will have the following entry for
the ETS namespace:

Intended New New Error
Namespace Levels Operation Rej. code code Reference
--------- ------ ---------------- --------- ---- ---------
ets 5 queue-based no no [This RFC]

8.1.5 The "WPS" Namespace

The WPS namespace derives its name from the "Wireless Priority
Service" defined in GSM and other wireless technologies.

Each namespace has a finite list of relative priority-values. Each
is listed here in the order of lowest priority to highest priority:

(lowest) wps.4
wps.3
wps.2
wps.1
(highest) wps.0

The wps namespace operates with the intended preferential treatment
of a queue-based policy (as defined in section 4), where higher
relative priority requests are queued ahead of lower relative
priority requests for processing at any point of scarce resource
constraints in an administrative domain.

WPS-based administrative domains will not queue normal, non-
prioritized messages. If a queue depth exists, the messages will be
rejected according to section 4.5.

A UAS within this type of administrative domain SHOULD be
configurable to limit the number of requests in a queue. One of two
different ways of limiting the queue depth is RECOMMENDED:

1) having a maximum number within a queue (perhaps with a different
number queued per priority-level), and

Polk & -> 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

Schulzrinne [page 22] & Polk Expires September 12, 2005 [Page 20]

Internet-Draft SIP Resource Priority February 21st, March 2005

2) consider all requests above the default level to be in a single
queue on a FIFO basis (for example, based on the reception
timestamp of the request)

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 UAS within this type of administrative domain SHOULD be
configurable to reject a queued lower priority request in lieu of
the newly arrived higher priority level request if the maximum
aggregate queue depth has been reached for that element. This
behavior is not considered a "preemption event" because the session
had not been previously established. This bumping will result in
the lower level request being rejected (discussed in section 4.5) -> 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 UAS within this type of administrative domain SHOULD be
configurable to limit -> 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 time a request sits in a queue. One of
two different ways case
where an RP actor then selects one of limiting the time in queue is RECOMMENDED:

1) having a maximum time within a queue (perhaps remainining resource values
for processing, usually choosing the one with a different
time per priority-level) before a/each message moves into a
rejection condition discussed in section 4.5., and

2) considering all requests above the default level in a single
queue on highest relative
priority.

Schulzrinne & Polk Expires September 12, 2005 [Page 21]

Internet-Draft SIP Resource Priority March 2005

If an RP actor understands multiple namespaces, it must create a FIFO basis (for example, based on
local total ordering across all resource values from these
namespaces, maintaining the reception
timestamp of relative ordering within each namespace.
It is RECOMMENDED that the request), all with same ordering is used across an
administrative domain. However, there is no requirement that such
ordering be the same maximum time in
queue before a/each message moves into a rejection condition
discussed in section 4.5.

Local policy will determine additional behaviors across all administrative domains.

8.2 Examples of Valid Orderings

Below are a queue-based
SIP element. However, the frequency set of provisional messages
indicated in [RFC3261] still need to apply to keep each session set-
up active until successful 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 rejected.

A compliant SIP Server experiencing a processing queue due to
excessive load MUST move the messages containing higher relative
priority-values up to the queue Foo.2
Foo.1 (lowest priority)

In the header indicates on a FIFO basis
based last example above, Bar.A and Bar.B are ignored.

8.3 Examples of Invalid Orderings

Based on the arrival time priority order of the message (as there may be more than
one message at namespaces above, the same level already in queue). It is conceivable
that priority-levels within a proxy following
combinations are grouped to include more than
one level per queue. This is a matter examples of local policy.

In compliant administrative domains utilizing the wps namespaces,
the UAS MUST copy the Resource-Priority header priority-values from
the Request to the Response for every header in the message unless
the UAS lacks local authorization to copy certain (perhaps
restricted) namespace.priority-value combinations.

Additional WPS policy is left to domain administrators, and to
future efforts.

The wps namespace operates according to the priority queuing policy orderings that are NOT acceptable and will not queue normal, non-prioritized messages.

The wps namespace defines no new error behaviors.

Polk &
MUST NOT be configurable:

Schulzrinne [page 23] & Polk Expires September 12, 2005 [Page 22]

Internet-Draft SIP Resource Priority February 21st, March 2005

The IANA Considerations section will have the following entry for
the WPS namespace:

Intended New New Error
Namespace Levels Operation Rej. code code Reference

Example 1 Example 2 Example 3
--------- ------ ---------------- --------- ---- ---------
wps 5 queue-based no no [This RFC]

8.2 Future Namespace Considerations
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 if an existing combination of namespace and
priority-values meets the their needs. For example, emergency first
responders around the world are discussing utilizing this mechanism
for preferential treatment in future networks. There should not be a
unique namespace for different jurisdictions. 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 specification of any future namespace, several facets need steps necessary to
be done or included:

1) register new namespaces.

New namespace/priority-value combinations proposed in the future namespaces MUST be defined in a Standards Track RFC 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 (e.g.,) unconstrained integers or tokens.

Schulzrinne & Polk Expires September 12, 2005 [Page 23]

Internet-Draft SIP Resource Priority March 2005

o The priority algorithm (Section 4.5), identifying whether the
namespace is to be used with priority queueing ("queue") or
preemption ("preemption"); if queueing is used, the namespace MAY
indicate whether normal-priority requests are queued. If there is
a new "intended algorithm" other than preemption priority
queueing, the algorithm must be described, taking into account all
RP actors (UAC, UAS, proxies).
o A namespace may either reference an
augmentation existing list of priority
values or define a new finite list of priority values in relative
priority order for IANA registration within the sip-parameters
Resource-Priority priority-values registry. New priority-values
MUST NOT be added to any previously IANA-registered list
associated with a particular namespace, this will cause
interoperability problems.
o Any new SIP response codes unique to this new namespace need to be
explained and registered.
o The reference document must specify and describe any new Warning
header field warn-codes (RFC 3261, Section 27.2).
o The document needs to specify a new row for the following table offered to
that summarize the features of the namespace and are included into
IANA for Registration: Resource-Priority Namespace registration:

Intended New New Error resp.
Namespace Levels Operation Rej. code algorithm warn-code code Reference
--------- ------ ---------------- --------- ---- -------- ---------
<new
<label> <# of <preemption <new error warn <new Rej <which
namespace> Levels> resp. <RFC>
levels> or queue> code> code> IETF doc>

- as well as list the finite set of priority values in relative
priority order (with no wildcards) for IANA Registration.

2) New priority-values MUST NOT be added to any previously (IANA)
registered list associated with a particular namespace. This
will cause interoperability problems.

If there is a information on new "intended behavior" (other than preemption-
based response codes, rejection codes or priority queue-based), error
behaviors is omitted, it is to be assumed that the namespace defines
no new parameters for or behaviors.

10. Namespace Definitions

10.1 Introduction

This specification defines five unique namespaces below: DSN, DRSN,
Q735, ETS and WPS, constituting their registration with IANA. Each
IANA registration contains the facets defined in Section 9. For
recognizability, we label the namespaces in capital letters, but note
that behavior
must be provided namespace names are case-insensitive and how said behavior affects different types of
RP actors.

4) Any new Response Codes unique to this new customarily rendered as
lowercase in protocol requests.

10.2 The "DSN" Namespace

The DSN namespace need to be
explained.

Polk & comes from the name of a US Government network
called "The Defense Switched Network".

Schulzrinne [page & Polk Expires September 12, 2005 [Page 24]

Internet-Draft SIP Resource Priority February 21st, March 2005

5) Any new Rejection Codes or changes to existing rejections codes
as

The DSN namespace has a result finite list of relative priority-values
listed below in the creation order of lowest priority to highest priority:

(lowest) dsn.routine
dsn.priority
dsn.immediate
dsn.flash
(highest) dsn.flash-override

The DRSN namespace uses the preemption algorithm (Section 4.5.1).

10.3 The "DRSN" Namespace

The DRSN namespace need comes from the name of a US Government network
called "The Defense RED Switched Network".

The DRSN namespace defines the following resource values, listed in
order of lowest priority to be offered
and explained.

9. Examples highest priority:

(lowest) drsn.routine
drsn.priority
drsn.immediate
drsn.flash
drsn.flash-override
(highest) drsn.flash-override-override

The SDP message body and the BYE and ACK exchanges are DRSN namespace uses the same as preemption algorithm (Section 4.5.1).

The DRSN namespace differs in
RFC 3665 [RFC3665] one algorithmic aspect from the DSN and omitted for brevity.

9.1 Simple Call

In this scenario, User A completes a call to User B directly.
Q735 namespaces. The
call behavior for the 'flash-override-override'
priority value differs from A to B is marked with the other values. Normally, requests do
not preempt those of equal priority, but a resource newly arriving
'flash-override-override' request will displace another one of equal
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

Polk & Schulzrinne [page 25]
Internet-Draft SIP Resource Priority February 21st, 2005

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
Resource-Priority: dsn.flash
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Length: 0

F3 200 OK User B -> User A

...

9.2 Receiver Does Not Understand if there are insufficient resources. This can also be
expressed as saying that 'flash-override-override' requests defends
themselves as 'flash-override' only.

10.4 The "Q735" Namespace

In this example, the receiving UA does not understand the "dsn"
namespace and thus returns

Q.735.3 [Q.735.3] was created to be a 417 (Unknown Resource-Priority) status
code. We omit commercial version of the message details
operationally equivalent DSN specification for messages F5 through F7 since
they are essentially the same as multi-layer priority
preemption (MLPP). The Q735 namespace is defined here 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 |
|----------------------->|
| |

Polk & Schulzrinne [page 26]
Internet-Draft SIP Resource Priority February 21st, 2005

| 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
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 Resource-Priority failed
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

F4 INVITE User A -> User B

Polk & same
manner.

The Q735 namespace defines the following resource values, listed in
order of lowest priority to highest priority:

Schulzrinne [page 27] & Polk Expires September 12, 2005 [Page 25]

Internet-Draft SIP Resource Priority February 21st, March 2005

Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Resource-Priority:

(lowest) q735.4
q735.3
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>

Content-Type: application/sdp
Content-Length: ...
...

10.
q735.2
q735.1
(highest) q735.0

The Q735 namespace operates according to the preemption (Section
4.5.1) algorithm.

10.5 The "ETS" Namespace

The ETS namespace derives its name indirectly from the name of the US
Government Telecommunications Service called "Government Emergency
Telecommunications Service" (or GETS), though the organization
responsible for the GETS service chose the acronym "ETS" for its GETS
over IP service, which stands for "Emergency Telecommunications
Service".

The ETS namespace defines the following resource values, listed in
order of lowest priority to highest priority:

(lowest) ets.4
ets.3
ets.2
ets.1
(highest) ets.0

The ETS namespace operates according to the priority queuing
algorithm (Section 4.5.2).

10.6 The "WPS" Namespace

The WPS namespace derives its name from the "Wireless Priority
Service" defined in GSM and other wireless technologies.

The WPS namespace defines the following resource values, listed in
order of lowest priority to highest priority:

(lowest) wps.4
wps.3
wps.2
wps.1
(highest) wps.0

The WPS namespace operates according to the priority queuing
algorithm (Section 4.5.2).

Schulzrinne & Polk Expires September 12, 2005 [Page 26]

Internet-Draft SIP Resource Priority March 2005

11. Security Considerations

11.1 General Remarks

Any resource priority mechanism can be abused to obtain resources and
thus deny service to other users. An adversary may be able to take
over a particular gateway, cause additional congestion during PSTN
emergencies or deny service to legitimate users. In the Internet,
or any IP domain, this mechanism can cause certain messages or
sessions (calls) to be given a higher relative priority of
processing within a SIP element (move adversary may be able to take
over a particular GSTN gateway, cause additional congestion during
emergencies affecting the head of the line
scenario), GSTN or deny service to the point of prematurely terminating an existing
session in favor of a newer one. legitimate users.
In some administrative domains, SIP end system such as IP phones, this will be the expected behavior for authenticated mechanism could
inappropriately terminate existing sessions and authorized
users (see section 8). Unauthorized users MUST NOT be given this
opportunity to abuse network/element resources.

While calls.

Thus, while the indication itself does not have to provide separate
authentication, any SIP request containing this header has higher
authentication requirements than regular requests.

A poor implementation of authentication and authorization will
likely cause illegitimate higher priority messages to process
without being successfully challenged for the privilege to do so.
While this will not likely have a great affect on the performance of
SIP Servers, this could have some (to a great) impact on the
premature termination of existing sessions. Those domains wishing
to utilize a namespace with an operation of preemption of lower
relative priority sessions should use caution to ensure only the
proper usage of this header is granted.

Care should be taken on 3 fronts:

1) To the domain that enables usage of the Resource-Priority header
such that adequate control exists to prevent unwanted
preferential message treatment from internal users.

Without an authentication and authorization mechanism to validate
each user request, unwanted usage (and potentially user hacked
settings) can have undesired affects on any internal network.

2) To the domain that enables usage of the Resource-Priority header
such that inadequate control exists to prevent unwanted
preferential message treatment from SIP messages from outside the

Polk & Schulzrinne [page 28]
Internet-Draft SIP Resource Priority February 21st, 2005

domain coming into the domain (and outside the area of direct AAA
control).

3) In the choosing of a namespace itself, to make sure the desired
behavior of SIP elements have equivalent behaviors defined in this
document to ensure interoperability and no surprises.

An example of this is choosing a namespace throughout a domain regular, non-prioritized requests.

This authentication and
configuring it for preferential treatment with no preemption, even
though a neighbor domain uses it as it is IANA defined (with
preemption as one expected behavior), resulting in poor performance
of fist domain's calls into authorization requirements extends to users
within the second administrative domain's
network. domain, as later interconnection with other
administrative domains may invalidate earlier assumptions on the
trustworthiness of users.

Below, we describe authentication and authorization aspects,
confidentiality and privacy requirements, protection against denial
of service attacks and anonymity requirements. Naturally, the
general discussion in RFC 3261 [RFC3261] applies.

All user agents and proxy servers which support this extension MUST
implement SIP over TLS [RFC3546] and the sips: 'sips' URI scheme as
described in Section 26.2 of RFC 3261, and Digest Authentication
[RFC2617] as described in Section 22 of RFC 3261. In addition, user
agents which support this extension SHOULD also implement S/MIME
[RFC2633] as described in Section 23 of RFC 3261 to allow for signing
and verification of signatures over requests which use this
extension.

10.1

11.2 Authentication and Authorization

Prioritized access to network and end system resources imposes
particularly stringent requirements on authentication and
authorization mechanisms since access to prioritized resources may
impact overall system stability and performance, not just result in
theft of, say, a single phone call.

Under certain emergency conditions, the network infrastructure,
including its authentication and authorization mechanism, may be
under attack.

Given the urgency during emergency events, normal statistical fraud
detection may be less effective, thus placing a premium on reliable

Schulzrinne & Polk Expires September 12, 2005 [Page 27]

Internet-Draft SIP Resource Priority March 2005

authentication.

Common requirements for authentication mechanisms apply, such as
resistance to replay, cut-and-paste and bid-down attacks.

Authentication MAY be SIP-based or use other mechanisms. Use of
Digest authentication and/or S/MIME is RECOMMENDED for UAS
authentication. Digest authentication requires that the parties
share a common secret, thus limiting its use across administrative

Polk & Schulzrinne [page 29]
Internet-Draft SIP Resource Priority February 21st, 2005
domains. SIP systems employing resource priority SHOULD implement S/
MIME at least for integrity, as described in Section 23 of [RFC3261].
However, in some environments, receipt of asserted identity [RFC3325]
from a trusted entity may be sufficient authorization. Section 5
describes third-party authentication.

Trait-based authorization [I-D.ietf-sipping-trait-authz] "entails an
assertion by a authorization service of attributes associated with an
identity" and may be appropriate for this application. With
trait-based authorization, a network element can directly determine,
by inspecting the certificate, that a request is authorized to obtain
a particular type of service, without having to consult a mapping
mechanism that converts user identities to authorizations.

Authorization may be based on factors beyond the identity of the
caller, such as the requested destination. Namespaces MAY also
impose particular authentication or authorization consideration that
are stricter than the baseline described here.

10.2

11.3 Confidentiality and Integrity

Calls which use elevated resource priority levels provided by the
'Resource-Priority' header field are likely to be sensitive and often
need to be protected from intercept and alteration. In particular,
requirements for protecting the confidentiality of communications
relationships may be higher than for normal commercial service. For
SIP, the 'To', 'From', 'Organization' and 'Subject' header fields are
examples of particularly sensitive information. 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 field can be carried in the SIP
message header or can be encapsulated in a message fragment carried
in the SIP message body [RFC3420]. To be considered valid
authentication for the purposes of this specification, S/MIME signed
SIP messages or fragments MUST contain, at a minimum, the Date, To,
From, Call-ID, and Resource-Priority header fields. Encapsulation in

Schulzrinne & Polk Expires September 12, 2005 [Page 28]

Internet-Draft SIP Resource Priority March 2005

S/MIME body parts allows the user to protect this header field
against inspection or modification by proxies. However, in many
cases, proxies will need to authenticate and authorize the request,
so that encapsulation is undesirable.

Removal of a Resource-Priority header field or downgrading its
priority value affords no additional opportunities to an adversary
since that man-in-the-middle could simply drop or otherwise
invalidate the SIP request and thus prevent call completion.

Only SIP elements within the same administrative trust domain
employing a secure channel between their SIP elements will trust a

Polk & Schulzrinne [page 30]
Internet-Draft SIP Resource Priority February 21st, 2005
Resource-Priority header field that is not appropriately signed.
Others will need to authenticate the request independently. Thus,
insertion of a Resource-Priority header field or upgrading the
priority value has no further security implications except causing a
request to fail (see discussion in the previous paragraph).

10.3

11.4 Anonymity

Some users may wish to remain anonymous to the request destination.
Anonymity for requests with resource priority is no different than
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 desire resource priority
treatment. The authentication may be based on capabilities and noms,
not necessarily their civil name. Clearly, they may remain anonymous
towards the request destination, using the network-asserted identity
and general privacy mechanism described in [RFC3323].

10.4

11.5 Denial-of-Service Attacks

As noted, systems described here are likely to be subject to
deliberate denial-of-service (DoS) attacks during certain types of
emergencies. DoS attacks may be launched on the network itself as
well as its authentication and authorization mechanism. As noted,
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.

11.

12. IANA Considerations

12.1 Introduction

This section defines two new SIP headers (11.1), (Section 12.2), one SIP
OPTION tag
(11.2), (Section 12.3), one new 4XX 4xx error code (11.3), (Section 12.4), a
new registry within the sip-parameters section of IANA for

Schulzrinne & Polk Expires September 12, 2005 [Page 29]

Internet-Draft SIP Resource Priority March 2005

Resource-Priority namespaces
(11.4) (Section 12.5) and a new registry within
the sip-parameters section of IANA for Resource-Priority and
priority-values (11.5). (Section 12.6).

Additional namespaces and priority values MUST be registered with
IANA. Within each namespace, the registration MUST indicate the
relative priority levels, expressed as an ordered list. New
priority-values MUST NOT be added to existing namespace registries.
The registration MUST describe, in the registration itself, how SIP
elements should treat requests from that namespace in 'operation',
e.g., whether preemption or only preferential queuing are allowed.

The SIP Change Process [RFC 3427] [RFC3427] establishes a policy for the
registration of new SIP extension headers. Resource priority
namespaces and priority values have similar interoperability
requirements to those of SIP extension headers. Consequently,
registration of new resource priority namespaces and priority values

Polk & Schulzrinne [page 31]
Internet-Draft SIP Resource Priority February 21st, 2005
requires documentation in an RFC using the extension header approval
process specified in RFC 3427.

11.1

Registration policies for new namespaces are defined in Section 9.

12.2 IANA Registration of 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields

[NOTE TO RFC EDITOR: Replace RFC XXXX with RFC number of this
document.]

The following is the registration for the 'Resource-Priority' header
field:

RFC number: XXXX
Header name: 'Resource-Priority'
Compact form: none

The following is the registration for the 'Accept-Resource-Priority'
header field:

RFC number: XXXX
Header name: Accept-Resource-Priority
Compact form: none

11.2

12.3 IANA Registration for Option Tag resource-priority

RFC number: XXXX

Schulzrinne & Polk Expires September 12, 2005 [Page 30]

Internet-Draft SIP Resource Priority March 2005

Name of option tag: 'resource-priority'
Descriptive text: Indicates or requests support for the resource
priority mechanism.

11.3

12.4 IANA Registration for Response Code 417

RFC number: XXXX
Response code: 417
Default reason phrase: Unknown Resource-Priority

11.4

12.5 IANA Resource-Priority Namespace and Priority-Value Registrations Registration

A new registry ("Resource-Priority Namespaces") in the sip-parameters
section of IANA is to be created taking a form similar to this table
below:

Intended New warn- New Error resp.
Namespace Levels Operation Rej. Algorithm code code Reference
--------- ------ ---------------- --------- ---- --------- ---------
dsn 5 preemption no no [This RFC] [XXXX]

drsn 6 preemption no no [This RFC]

Polk & Schulzrinne [page 32]
Internet-Draft SIP Resource Priority February 21st, 2005 [XXXX]

q735 5 preemption no no [This RFC] [XXXX]

ets 5 priority-queue queue no no [This RFC] [XXXX]

wps 5 priority-queue queue no no [This RFC] [XXXX]

Legend
------
Namespace = the unique string of identifying the namespace
Levels = the number of priority-values within the namespace
Operation
Algorithm = Intended (or expected) operational behavior of SIP elements encountering
implementing this namespace
New Rej. Code Warn code = New Rejection Warning Codes (warn-codes) introduced for by
this namespace
New Error Code Resp. code = New Error Codes SIP response codes introduced for by this namespace
Reference = IETF Document document reference for this namespace

11.5

12.6 IANA Priority-Value Registrations

A new registry ("Resource-Priority Priority-values") in the
sip-parameters section of IANA is to be created taking a form similar
to this table below (Reference [XXXX] XXXX is this RFC):

Schulzrinne & Polk Expires September 12, 2005 [Page 31]

Internet-Draft SIP Resource Priority March 2005

Namespace: drsn
Reference: [XXXX] RFC XXXX
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override", "flash-override-override"

Namespace: dsn
Reference: [XXXX] RFC XXXX
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override", "flash-override"

Namespace: q735
Reference: [XXXX] RFC XXXX
Priority values (least to greatest): "4", "3", "2", "1", "0"

Namespace: ets
Reference: [XXXX] RFC XXXX
Priority values (least to greatest): "4", "3", "2", "1", "0"

Namespace: wps
Reference: [XXXX] RFC XXXX
Priority values (least to greatest): "4", "3", "2", "1", "0"

12.

13. Acknowledgments

Ben Campbell, Ken Carlberg, Paul Kyzivat, Rohan Mahy, Allison Mankin,
Piers O'Hanlon, Mike Pierce, and Samir Srivastava and Allison Mankin provided helpful
comments.

Polk & Schulzrinne [page 33]
Internet-Draft SIP Resource Priority February 21st, 2005

Dean Willis provided much help with this effort.

Martin Dolly, An Nguyen and Niranjan Sandesara assisted with the
ets ETS
and wps WPS namespaces.

Janet Gunn helped improve the queue-based policy text.

13. improve the text on queueing-based priority.

14. References

13.1

14.1 Normative References

[I-D.ietf-sipping-reason-header-for-preemption]
Polk, J., "Extending the Session Initiation Protocol
Reason Header for Preemption Events",
draft-ietf-sipping-reason-header-for-preemption-02 (work
in progress), August 2004.

[I.255.3] International Telecommunications Union, "Integrated
Services Digital Network (ISDN) - General Structure and
Service Capabilities - Multi-Level Precedence and

Schulzrinne & Polk Expires September 12, 2005 [Page 32]

Internet-Draft SIP Resource Priority March 2005

Preemption", Recommendation I.255.3, July 1990.

[Q.735.3] International Telecommunications Union, "Stage 3
description for community of interest supplementary
services using Signaling Signalling System No. 7: Multi-level
precedence and preemption", Recommendation Q.735.3, March
1993.

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.

[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., "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.

[I-D.ietf-sipping-reason-header-for-preemption]
Polk, J., "Reason Header for Preemption within the Session

Polk & Schulzrinne [page 34]
Internet-Draft SIP Resource Priority February 21st, 2005

Initiation Protocol (SIP)",
draft-ietf-sipping-reason-header-for-preemption-02 (work
in progress), August 2004

13.2

14.2 Informative References

[I-D.ietf-ieprep-framework]
Carlberg, K., Brown, I. and C. Beard, "Framework for
Supporting ETS in IP Telephony",
draft-ietf-ieprep-framework-09 (work in progress), April
2004.

[RFC3893]

[I-D.ietf-sip-authid-body]
Peterson, J., "SIP Authenticated Identity Body (AIB)
Format", RFC 3893, May 2004.

[RFC3903] Niemi, A., "An Event State Publication Extension to the
Session Initiation Protocol (SIP)", RFC3903, draft-ietf-sip-authid-body-03 (work in progress),
May 2004.

[I-D.ietf-sipping-trait-authz]
Peterson, J., "Trait-based Authorization Requirements for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-trait-authz-01 (work in progress),
February 2005.

Schulzrinne & Polk Expires September 12, 2005 [Page 33]

Internet-Draft SIP Resource Priority March 2005

[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.

[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, 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.

[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, 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

Polk & Schulzrinne [page 35]
Internet-Draft SIP Resource Priority February 21st, 2005
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.

[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004.

Schulzrinne & Polk Expires September 12, 2005 [Page 34]

Internet-Draft SIP Resource Priority March 2005

[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.

Authors' Addresses

James Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX 75082
USA

EMail: jmpolk@cisco.com

Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
US

Phone: +1 212 939 7042 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu

James Polk
Cisco
2200 East President George Bush Turnpike
Richardson, TX 75082
US

EMail: jmpolk@cisco.com

Schulzrinne & Polk Expires September 12, 2005 [Page 35]

Internet-Draft SIP Resource Priority March 2005

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of

Polk & Schulzrinne [page 36]
Internet-Draft SIP Resource Priority February 21st, 2005
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

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.

Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Polk &

Schulzrinne [page 37] & Polk Expires September 12, 2005 [Page 36]

----