SIP Working Group                                         H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: April 25th, 2005                                        J. Polk
                                                                   Cisco
                                                      October 25th, 2004



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


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I 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 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.

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

   This Internet-Draft will expire on April 25th, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


Abstract

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




Schulzrinne & Polk                                             [Page 1]


Internet-Draft         SIP Resource Priority         October 25th, 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  The Resource-Priority and Accept-Resource-Priority SIP
       Header Fields  . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1   The 'Resource-Priority' Header Field . . . . . . . . . . .  5
     3.2   The 'Accept-Resource-Priority' Header Field  . . . . . . .  6
     3.3   Usage of the 'Resource-Priority' and
           'Accept-Resource-Priority' Header Fields . . . . . . . . .  7
     3.4   The 'resource-priority' Option Tag . . . . . . . . . . . .  8
   4.  Behavior of SIP Elements that Receive Prioritized Requests . .  8
     4.1   General Rules  . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.1 Policy Guidelines Involving Preemption Policy  . . . . .  9
     4.2   Rejection Messages . . . . . . . . . . . . . . . . . . . .  9
     4.3   Error Conditions . . . . . . . . . . . . . . . . . . . . . 10
       4.3.1   Known Namespace and Priority Value . . . . . . . . . . 10
       4.3.2   Handling Unknown Namespaces and Priority Values  . . . 11
       4.3.3   Strict Mode  . . . . . . . . . . . . . . . . . . . . . 11
       4.3.4   Semi-Strict Mode . . . . . . . . . . . . . . . . . . . 12
       4.3.5   Loose Mode . . . . . . . . . . . . . . . . . . . . . . 14
     4.4   User Agent Client Behavior . . . . . . . . . . . . . . . . 14
     4.5   User Agent Server Behavior . . . . . . . . . . . . . . . . 14
       4.5.1 User Agent Servers and Preemption Policy . . . . . . . . 15
     4.6   Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 15
       4.6.1 Proxies and Preemption Policy  . . . . . . . . . . . . . 16
   5.  Third-Party Authentication . . . . . . . . . . . . . . . . . . 16
   6.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 16
   7.  Namespace Description  . . . . . . . . . . . . . . . . . . . . 17
     7.1 Multiple Namespaces in a Message . . . . . . . . . . . . . . 19
   8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.1   Simple Call  . . . . . . . . . . . . . . . . . . . . . . . 21
     8.2   Receiver Does Not Understand Namespace . . . . . . . . . . 22
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
     9.1   Authentication and Authorization . . . . . . . . . . . . . 25
     9.2   Confidentiality and Integrity  . . . . . . . . . . . . . . 26
     9.3   Anonymity  . . . . . . . . . . . . . . . . . . . . . . . . 27
     9.4   Denial-of-Service Attacks  . . . . . . . . . . . . . . . . 27
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
     10.1  IANA Registration of 'Resource-Priority' and
           'Accept-Resource-Priority' Header Fields . . . . . . . . . 27
     10.2  IANA Registration for Option Tag resource-priority . . . . 28
     10.3  IANA Registration for Response Code 417  . . . . . . . . . 28
     10.4  IANA Namespace Registrations . . . . . . . . . . . . . . . 28
     10.5  IANA Priority-Value Registrations  . . . . . . . . . . . . 29
   11.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 29
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 30
   12.1  Normative References . . . . . . . . . . . . . . . . . . . . 30
   12.2  Informative References . . . . . . . . . . . . . . . . . . . 30
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
       Intellectual Property and Copyright Statements . . . . . . . . 32


Schulzrinne & Polk                                             [Page 2]


Internet-Draft         SIP Resource Priority         October 25th, 2004



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
   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' This
   header field MAY be used by SIP user agents, including General
   Switched Telephone Network (GSTN) gateways and terminals, and SIP


Schulzrinne & Polk                                             [Page 3]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   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 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 displace existing signaling requests 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], 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 values are subject to authorization.

   While the 'Resource-Priority' header 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 to cause such influence may be defined in other
   documents.

   Existing implementations of RFC 3261 that do not participate in the
   resource priority mechanism follow the normal rules of RFC 3261,
   Section 8.2.2:  "If a UAS does not understand a header field in a
   request (that is, the header field is not defined in this
   specification or in any supported extension), the server MUST ignore
   that header field and continue processing the message." Thus, the use
   of this mechanism is wholly invisible to existing implementations
   unless the request includes the Require header field with the
   resource-priority option tag.


Schulzrinne & Polk                                             [Page 4]


Internet-Draft         SIP Resource Priority         October 25th, 2004


   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.

   We define the header field syntax in Section 3 and then describe the
   behavior of user agents and proxies in Section 4.3 through Section
   4.5.  Section 6 briefly describes how this feature affects existing
   systems that do not support it.  Third-party authentication is
   discussed in Section 5, while general security issues are enumerated
   in Section 8.  This specification does not propose any new SIP
   security mechanisms.  Examples can be found in Section 7.


2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant
   implementations.


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

   This document defines the 'Resource-Priority' and
   'Accept-Resource-Priority' SIP header fields.

   The SIP element behavior is described for user agent clients (UACs)
   in Section 4.3, for UAS in Section 4.4 and for SIP proxy servers in
   Section 4.5.


3.1  The 'Resource-Priority' Header Field

   The 'Resource-Priority' header field marks a SIP request as desiring
   prioritized resource access, as described in the introduction.  In
   responses, the 'Resource-Priority' header fields indicates the actual


Schulzrinne & Polk                                             [Page 5]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   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 requirement that all requests within a SIP dialog or
   session use the 'Resource-Priority' header field.  Again, local
   policy dictates the appropriate behavior; thus, implementations MUST
   be configurable accordingly.

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

   Resource-Priority  = "Resource-Priority" HCOLON
                        r-value *(COMMA r-value)
   r-value            = namespace "." r-priority
   namespace          = token-nodot
   r-priority         = token-nodot
   token-nodot        = 1*( alphanum / "-"  / "!" / "%" / "*"
                               / "_" / "+" / "`" / "'" / "~" )

   An example 'Resource-Priority' header field is shown below:

      Resource-Priority: q735.1, dsn.flash

   The 'Resource-value' parameter in the 'Resource-Priority' header
   indicates the resource priority desired by the request originator.
   Since a request may traverse multiple administrative domains with
   multiple different namespaces, it is necessary to be able to
   enumerate several different namespaces.  However, each namespace MUST
   NOT appear more than once in a SIP message.

   Each resource 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.  Each
   namespace has at least one priority value.  Namespaces and priority
   values within each namespace MUST be registered with IANA (Section
   9).  Initial namespace registrations are described in Section 9.5.

   There may be multiple resource values or, equivalently, multiple
   'Resource-Priority' header field instances.


3.2  The 'Accept-Resource-Priority' Header Field

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

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



Schulzrinne & Polk                                             [Page 6]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   An example is given below:

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


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
   [RFC3515], the INFO (INF) method in [RFC2976], and the PUBLISH (PUB)
   method in [I-D.ietf-sip-publish].)

   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   c   c   c   c   c   c   c
   Resource-Priority        200   -      o   -   o   o   o   o   o
   Accept-Resource-Priority 200   -      o   o   o   o   o   o   o
   Accept-Resource-Priority 417   -      m   -   m   m   m   m   m
   Accept-Resource-Priority 420   -      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   c   c   c   c   c   c   c
   Resource-Priority        200   -      o   o   o   o   o   o   o
   Accept-Resource-Priority 200   -      o   o   o   o   o   o   o
   Accept-Resource-Priority 417   -      m   m   m   m   m   m   m
   Accept-Resource-Priority 420   -      o   o   o   o   o   o   o

   Section 4 will change this table depending on the 'mode' a SIP
   element is operating under.

   Other request methods MAY define their own handling rules; unless
   otherwise specified, recipients MAY ignore these header fields.
   'Accept-Resource-Priority' MUST be returned in 420 (Not Supported)
   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 the request.

   While all methods listed above allow the optional use of the
   'Resource-Priority' header fields, only request methods that start a
   dialog or deliver content, such as MESSAGE, are likely to benefit
   from this mechanism and other methods SHOULD NOT use them.  This
   consideration also applies to methods not listed above.



Schulzrinne & Polk                                             [Page 7]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   The 'Resource-Priority' header field included in a Request message
   MUST be copied in the SIP response, subject to further rules in each
   mode of operation (listed in section 4 of this document).


3.4  The 'resource-priority' Option Tag

   This document also defines the "resource-priority" option tag. The
   behavior is described in Section 4.2.2 and the IANA registration is
   in Section 9.2.


4.  Behavior of SIP Elements that Receive Prioritized Requests

   All SIP user agents and proxy servers that support this
   specification share certain common behavior, which we describe
   below.  Behavior specific to user agent clients is covered in
   section 4.4, for user agent servers in Section 4.5, while Section
   4.6 deals with proxy behavior.


4.1  General Rules

   The Resource-Priority header field is potentially applicable to all
   SIP request messages. As a minimum, implementations of this
   specification supporting any of the following request types MUST
   support the use of this specification for those request types:

      1) INVITE [RFC3261]
      2) ACK [RFC3261]
      3) PRACK [RFC3262]
      4) MESSAGE [RFC3428]
      5) UPDATE [RFC3311]
      6) SUBSCRIBE [RFC3265]
      7) NOTIFY [RFC3265]
      8) REFER [RFC3515]

   Note that this does not require all implementations to support every
   request type listed.

   If a SIP element receives the Resource-Priority header in a Request
   message other than what is listed above, the header MAY be ignored,
   but not the message because the header was present (but could be for
   other reasons not listed here).

   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 implementation MAY reveal
   this capability only to authorized UACs.

   Note that an overloaded UAS may not be able to provide this


Schulzrinne & Polk                                             [Page 8]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   information at all times.)

   Note that according to RFC 3261, proxies reached with a Max-Forwards
   value of zero answer the OPTIONS request, allowing a UAC to discover
   the capabilities of both proxy and user agent servers.


4.1.1 Policy Guidelines Involving Preemption Policy

   Not every implementation of the Resource Priority Header involves
   preemption.  In fact, it is expected that a minority of domains
   implementing this specification will enable preemption, though
   critical in those domains; thus preemption policies cannot be
   minimized.  With that said, a word or two is needed to address the
   expected general behavior of a policy that includes preemption of
   resources for SIP elements supporting this specification:

      SIP messages themselves are not preempted due to this header.

   For SIP elements compliant with this specification, SIP messages
   containing a valid Resource Priority header are prioritized higher
   or lower than other messages.  Since [RFC3261] states SIP headers
   not understood are ignored, the presence of this header SHOULD NOT
   adversely affect SIP elements that are not aware of, nor supports
   this specification.  If the presence of this header is supported,
   but either the namespace or the priority value are not recognized,
   section 4.3 of this document addresses appropriate error responses.

   SIP messages that create or have created a dialog can cause
   preemption of another dialog with the usage of this specification.
   The specific behaviors of SIP elements with regard to preemption
   policy is included in 4.5 for UAS and gateway behavior, and section
   4.6 for Proxy Servers.


   4.2 Rejection Messages

   The following is a list of rejections to SIP messages that contain a
   Resource-Priority header specifically because of the contents of the
   header.

   If a UA is currently occupied with another session and receives a
   dialog generating message containing a valid Resource-Priority
   header of equal or lower relative priority value, the response is
   the same as stated in section 13.3.1.3 of [RFC3261]:

   - a 486 (Busy Here) is returned if the UAS knows it cannot or will
     not accept the request,

   - a 600 (Busy Everywhere) if the UAS knows there are no other SIP
     elements that can accept the INVITE, and



Schulzrinne & Polk                                             [Page 9]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   - a 488 (Not Acceptable Here) if the UAS is rejecting the INVITE.

   [RFC3261] advises that a 488 response SHOULD include a warning
   header with a reason for the rejection.

   If the message from the UAC contains a known namespace, and the
   priority-value is higher than is authorized, this error condition is
   addressed in the next subsection (4.3).

   In the case in which a UA is currently occupied with another session
   and receives an INVITE containing a valid Resource-Priority header
   of higher relative priority than that of the current dialog, the
   current dialog is rejected with a BYE Request as per
   [I-D. ietf-sipping-reason-header-for-preemption] and the new Request
   is successful responded to.

   If a Proxy Server is currently experiencing process difficulties
   (perhaps due to overload), this is an error condition that will be
   addressed in section 4.3.1.


4.3  Error Conditions

4.3.1  Known Namespace and Priority Value

   Two error conditions can occur if a request reaches an element that
   supports the namespace and resource priority. Elements receiving
   requests with namespaces or priority values that they do not
   understand act according to the rules in the next section.

   Insufficient authorization: If the element receives a 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.

   Insufficient resources: If there are insufficient resources at an
      element for a given priority, a request might be delayed or
      refused, depending on local policy or the definition of the
      namespace.  If it is refused, the element returns a 503 (Service
      Unavailable) response.  The response MAY also include a 'Warning'
      header with warning code 370 (Insufficient Bandwidth) if the
      request failed due to insufficient capacity for the media streams,
      rather than insufficient signaling capacity.

      The 503 (Service Unavailable) response provides sufficient
      indication to the originator to re-attempt with a higher
      appropriate resource priority or to add a resource priority
      indication, if authorized.






Schulzrinne & Polk                                            [Page 10]


Internet-Draft         SIP Resource Priority         October 25th, 2004

4.3.2  Handling Unknown Namespaces and Priority Values

   When handling requests with unknown namespaces or priority values,
   elements can operate in one of three modes, "strict", "semi-strict"
   and "loose".  'Strict' and 'semi-strict' are identified by the
   presence or absence of a 'Require' header field with the 'Resource-
   Priority' option tag.  'Loose' mode does not contain a Require
   header.  If the request includes a 'Require' header field with the
   'Resource-Priority' option tag, a UAS MUST follow the strict or
   semi-strict mode rules, otherwise UAS and proxies MUST operate in
   loose mode.  Stating the presence of the Require header (with the
   'Resource-Priority' option tag) in a SIP message explicitly
   determines adherence to one of two modes seems counterintuitive;
   however, the differences are slight between the two modes and are
   detailed below.

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


4.3.3  Strict Mode

   Strict Mode is for administrative domains (or realms) that require
   the presence of the Resource-Priority Header with a known namespace
   and priority-value in all SIP messages listed in section 4.1.  UACs
   will include a Requires header of 'Resource-Priority' in all such
   SIP Requests to ensure all Responses include the 'Resource-Priority'
   header.  Domains that require inclusion of the 'Resource-Priority'
   header in these message types have a proactive mechanism for
   preferential treatment of SIP messages even in congestion instances.

   When operating in strict mode, a SIP element MAY provide
   preferential processing treatment of messages regardless of
   processing load.

   The following table extends the values in Table 2 of RFC3261
   [RFC3261] operating in 'strict mode'.  This table supercedes the
   table in section 3.2 of this document.

   Header field             where proxy INV ACK CAN BYE REG OPT PRA
   ----------------------------------------------------------------
   Resource-Priority        R     amdr   m   m   m   m   m   m   m
   Resource-Priority        r     amdr   c   c   c   c   c   c   c
   Resource-Priority        200   -      m   -   m   m   m   m   m

   Header field             where proxy SUB NOT UPD MSG REF INF PUB
   ----------------------------------------------------------------
   Resource-Priority        R     amdr   m   m   m   m   m   m   m
   Resource-Priority        r     amdr   c   c   c   c   c   c   c
   Resource-Priority        200   -      m   -   m   m   m   m   m




Schulzrinne & Polk                                            [Page 11]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   The 'Resource-Priority' header field included in a Request message
   MUST be copied in the reply unchanged in 'strict' mode.

   SIP elements in this mode will verify the namespace contained in the
   SIP message is exactly as the domain expects, as well the supplied
   priority-value MUST be one of the known priority-values for that
   namespace (registered via IANA).

   If a SIP element receives a Resource-Priority with unknown values
   for either the namespace or priority-value, an error message of 417
   (Unknown Resource-Priority) MUST be returned without exception.

   Following standard SIP behavior (Section 8.2.2.3 of [RFC3261]), a UAS
   operating in strict mode MUST reject a request with response code
   420 (Bad Extension) if it does not support the 'Resource-Priority'
   option tag.

      For example, a gateway that is unaware of a resource priority
      namespace might accept a request at non-elevated priority, but
      then the request could later be preempted by other requests.
      Also, use of the 'Require' restriction ensures that in parallel
      forking, only branches that support the resource-priority
      mechanism succeed.

   In strict mode operations, any failure response MUST NOT include an
   'Accept-Resource-Priority' header field on the final hop of
   signaling.  In other words, if an 'Accept-Resource-Priority' header
   field is included in a SIP failure Response message, it MUST be
   removed by the last Proxy (generally element in the second to last
   Via entry).  Revelation of this information to an unauthorized UAC
   is not to occur as it would provide too much information to a UA
   that might not be authorized to access that network.

   UAS and Proxy implementations SHOULD support returning a 'Accept-
   Resource-Priority' header field enumerating all the resource values
   that the server is willing to process.  This is particularly useful
   for operational testing of systems supporting resource priority, as
   otherwise it might be difficult to detect under non-overload
   conditions whether an element supports the functionality or not.


4.3.4 Semi-Strict Mode

   Semi-Strict Mode SHOULD be the operational mode when strict
   adherence to the usage of the Resource-Priority header is granted
   to authorized personnel in an otherwise public domain. In this mode,
   the Resource-Priority header MUST only be used when a user is
   authorized for preferential treatment of their SIP messages.

   The following table extends the values in Table 2 of RFC3261
   [RFC3261] operating in 'semi-strict mode' for the authorized UAC.
   This table supercedes the table in section 3.2 of this document.  A


Schulzrinne & Polk                                            [Page 12]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   UAS will copy the 'Resource-Priority' header into the SIP Response
   message from an authorized Request message.  It is not expected that
   a UAS can authenticate the Request, but the Response needs to be
   given the same preferential treatment possibilities as the Request.

   Header field             where proxy INV ACK CAN BYE REG OPT PRA
   ----------------------------------------------------------------
   Resource-Priority        R     amdr   m   m   m   m   m   m   m
   Resource-Priority        r     amdr   c   c   c   c   c   c   c
   Resource-Priority        200   -      m   -   m   m   m   m   m

   Header field             where proxy SUB NOT UPD MSG REF INF PUB
   ----------------------------------------------------------------
   Resource-Priority        R     amdr   m   m   m   m   m   m   m
   Resource-Priority        r     amdr   c   c   c   c   c   c   c
   Resource-Priority        200   -      m   -   m   m   m   m   m


   The 'Resource-Priority' header field included in a Request message
   MUST be copied in the reply unchanged in 'semi-strict' mode.

   One of the following MUST be included to differentiate the normal
   users of a domain from those that will receive preferential
   treatment:

      1) Inclusion of the authorization header, or

      2) What will come out of the Trait-Based Authorization
         [I-D.ietf-sipping-trait-authz] effort currently under way

   Semi-strict mode differs from Strict mode in that it is not required
   that every SIP message have a Resource-Priority header.  When the
   Resource-Priority header is used, is MUST be exactly as is expected
   by the SIP elements within a domain - otherwise a 417 (Unknown
   Resource Priority) error is the response.  If no Resource-Priority
   header is present, the message does not receive preferential
   treatment.  Thus, the modified table 2 above would be filled with
   '-' in each column for all Methods for the unauthorized UA.

   An example usage of this mode is the US-based Government Emergency
   Telephone Service (GETS), in which a very small number of
   individuals have the ability to authorize with a centralized service
   to provide to them preferential access for their next voice call.
   This includes the ability to camp on a busy trunk group or circuit
   in a Class 5 or Tandem switch until any one of the circuits becomes
   free.  The authorized user then is given access to the newly-
   available circuit before anyone else has knowledge of it becoming
   free.  [RFC3487] is based on this GETS-type service.






Schulzrinne & Polk                                            [Page 13]


Internet-Draft         SIP Resource Priority         October 25th, 2004

4.3.5 Loose Mode

   In loose mode, unknown priority values or namespaces are ignored and
   the request is treated as if these values were not included.  If
   there are no valid priority values or namespaces, the request is
   treated as if it had no 'Resource-Priority' header field.  Thus, no
   417 (Unknown Resource-Priority) is generated.  There is no
   modification to the [RFC3261] table 2 extension in section 3.3 of
   this document for loose mode.

   Loose mode maintains the value extension table in section 3.3 of
   this document (which is an extension of Table 2 of RFC3261).


4.4  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 valid 'Resource-Priority' header
   field in a single SIP Request, depending on the nature of the SIP
   message.

   If the request is returned with 417 (Unknown Resource-Priority), the
   UAC MAY retry the request with a different set of namespace/priority
   combinations, drawing from the values returned by the
   'Accept-Resource-Priority' header field in the response, if included.


4.5  User Agent Server Behavior

   If the UAS understands the resource value, but refuses to honor the
   request with elevated priority for this particular user, it returns
   the 403 (Forbidden) response code.  It MAY include the list of
   resource values that the user is allowed to use in the
   'Accept-Resource-Priority' response header field.  If the UAS
   refuses to honor the request for a reason other than the Resource
   Priority header, the proper response is a 488 (Not Acceptable Here).
   A warning header MAY be included.

      The lookup of the authorized values may take significant resources
      since it may involve an AAA interaction.  Thus, it seems imprudent
      to require that the list is customized to the user.  In general,
      legitimate users know their highest resource value that they are
      entitled to.

   The precise effect of the 'Resource-Priority' indication depends on
   the type of UAS, the namespace and local policy.  For example, a
   circuit-switched telephony gateway might move requests with elevated
   priority to the front of the queue of requests waiting for outbound
   lines, it may utilize additional resources or it may preempt existing
   calls.  For a terminal, such as a SIP phone, requests with elevated


Schulzrinne & Polk                                            [Page 14]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   priority might trigger a special alert tone or preempt other,
   lower-priority existing calls.  The generic protocol mechanism
   described here does not mandate the particular element behavior, but
   namespace definitions, such as the ones in Section 9.5, MUST describe
   the desired behavioral properties of user agents and proxy servers.


4.5.1 User Agent Servers and Preemption Policy

   Within a UAS, the priority value (if higher in relative priority)
   MUST cause a session to be terminated in favor of a newly signaled
   session set-up (in strict mode). Consistent SIP termination
   indications will be sent in these cases (using the BYE Method).
   [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 what happened (in this case, a preemption event).  That
   document offers several reasons for where the termination occurred
   ('at the UA', 'in the network', 'at a IP/PSTN gateway'), and
   includes call flow examples of each reason.


4.6  Proxy Behavior

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

   If there are multiple namespace or priority choices available to the
   user agent client, a proxy MAY return the request with an appropriate
   'Accept-Resource-Priority' header field.  Details are a matter of
   local policy.

   If a Proxy is expecting a message to have a 'Resource-Priority'
   header and the header is protected via S/MIME encapsulation in a SIP
   message fragment [RFC3420], the Proxy MUST error this message.  This
   MUST always be the case in 'strict-mode' (in which all messages will
   have a valid 'Resource-Priority' header).  Therefore, the use of
   SIPFRAG in 'strict-mode' is not recommended.  In 'semi-strict' mode,
   SIP elements do not expect the 'Resource-Priority' header, so there
   will not be any preferential treatment of that message by that SIP
   element.

   If no S/MIME is used, SIP proxies MAY downgrade or upgrade the
   'Resource-Priority' of a request or insert a new 'Resource-Priority'
   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. The session policy mechanism does not
   fit well, as user agents may not have a choice in the namespace or
   priority available to them, there are no privacy concerns and the


Schulzrinne & Polk                                            [Page 15]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   resource priority mechanism does not involve message bodies or
   session descriptions.

   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 colluding user
   agents artificially raise the priority level.

   It is unlikely that the resource priority value in responses will
   have any influence on response handling.

   A SIP proxy MAY use the 'Resource-Priority' indication in its
   routing decisions, e.g., to retarget to a SIP node or SIP URI that
   is reserved for a particular resource priority.

   There do not appear to be any special considerations when forking
   requests containing a resource priority indication.

   Otherwise, the proxy behavior is the same as for user agent servers
   Section 4.4).


4.6.1 Proxies and Preemption Policy

   Within a SIP Server, a preemption policy means (authorized) messages
   with higher priority values MUST be processed before messages
   containing lower priority values.  It does not mean the lower
   priority SIP messages are deleted because they contain lower
   priority values.  That said, see section 4.3 for the error codes to
   be returned to a UAC if the request had an insufficient priority to
   be processed.


5.  Third-Party Authentication

   In some case, the RP actor may not be able to authenticate the
   requestor or determine whether an authenticated user is authorized to
   make such a request.  In these circumstances, the SIP entity may
   avail itself of general SIP mechanisms that are not specific to this
   application.  The authenticated identity management mechanism
   [RFC3893] allows a third party to verify the identity of the
   requestor and 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


Schulzrinne & Polk                                            [Page 16]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   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 are no
   better off rejecting the request due to feature failure.  Since the
   intent of resource priority indications is to increase the
   probability of call completion, adding failure modes appears
   counterproductive.


7.  Namespace Description

   A 'Resource-Priority' namespace MUST be unique with respect to other
   'Resource-Priority' namespaces.  There are 5 unique namespaces
   defined in this specification.  This section will define each, as
   well as their individual parameters.  The case insensitive
   namespaces are as follows:

     - dsn
     - drsn
     - q735
     - ets
     - wps

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

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

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

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

   (lowest)   ets.4
              ets.3
              ets.2


Schulzrinne & Polk                                            [Page 17]


Internet-Draft         SIP Resource Priority         October 25th, 2004

              ets.1
   (highest)  ets.0

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

   More than one namespace listed here adheres to a 'strict mode' of
   operation (dsn, drsn and q735).  More than one adheres to a 'semi-
   strict mode' of operation (ets and wps).  No namespaces listed here
   operate under 'loose mode'.

   The dsn, drsn and q735 namespaces operate under a policy of
   providing preferential message treatment to the point of preempting
   lower relative priority requests in favor of processing higher
   relative priority requests.

   In SIP Servers, this translates to giving preferential processing
   treatment to those messages containing higher priority values (a
   "move to the front of the line" scenario).  During light to medium
   processing loads, this should not be evident at all to other
   messages.  During heavier loads on servers, these labels provide for
   a domain ensuring (by their own configuration) a certain
   classification(s) of messages are processed before other
   classification(s) of messages.

   In UAs, just as in SIP servers, this translates to giving
   preferential processing treatment to those messages containing
   higher priority values (a "move to the front of the line" scenario).
   But for dialog requests, this behavior translates into preemption of
   dialog events if a new INVITE is received that is indicating a
   higher priority value than the one assigned to the current dialog.

   The ets and wps namespaces operate with preferential treatment but
   without preemption.  These namespaces operate under a policy of
   provide preferential treatment to higher relative priority requests
   instead of processing lower relative priority requests.  Messages
   are not preempted, or deleted, except under extreme loads in which
   all available processing is taken up with higher priority messages.

   An example of this is at a IP/PSTN gateway with all of the PSTN side
   circuits utilized.  In strict mode one of the lower priority
   circuits would be freed using preemption.  In semi-strict mode, the
   SIP request May be granted access to the next available circuit
   based on this header's presence in the authorized message,
   regardless of how many other "regular" requests are received at that
   gateway.

   There are no unique rejection messages to a SIP message containing
   any one of these namespaces (outside of the rules within the mode


Schulzrinne & Polk                                            [Page 18]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   SIP elements adhere to).

   The 417 (Unknown Resource Priority) error message is the proper
   response to any SIP request (authorized if that domain requires it,
   and it SHOULD) if the namespace is unknown to that SIP element in
   strict or semi-strict mode.  A 417 is also the proper error response
   in the case the namespace is known, but the priority-value is either
   unknown, or does not correspond to the list of priority-values
   associated with that particular namespace in strict or semi-strict
   mode.

   The following table will be repeated in the IANA considerations
   section as the new registry for 'Resource-Priority' in the SIP
   parameters section.

                                           New   New Error
Namespace  Levels   Mode    Operation   Rej. code  code    Reference
---------  ------   ----    ---------   ---------  ----    ---------
   dsn       5     strict   preemption      no      417    [This RFC]

   drsn      6     strict   preemption      no      417    [This RFC]

   q735      5     strict   preemption      no      417    [This RFC]

   ets       5  semi-strict preferential    no      417    [This RFC]

   wps       5  semi-strict preferential    no      417    [This RFC]

                   Table 1. Namespace Parameters

   New namespace/priority-value combinations proposed in the future
   MUST be defined in a Standards Track RFC and MUST include an
   augmentation to Table 1 of this document in that effort, as well as
   list the finite set of priority values in relative priority order
   (with no wildcards) for IANA Registration.  New priority-values MUST
   NOT be added to any previously (IANA) registered finite list
   associated with a particular namespace.  This will cause
   interoperability problems.


7.1 Multiple Namespaces in a Message

   The only rules stipulated here regarding more than one namespace in
   a SIP message are:

   o  There MUST be one order of priorities a SIP element has to
      process to.

   o  It MUST be configurable to have more than zero namespaces be
      ignored, while the SIP element adheres to any number of Resource-
      Priority headers (if placed in one overall relative order).



Schulzrinne & Polk                                            [Page 19]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   o  The header order in the message of which Resource-Priority header
      is chosen MUST not matter. SIP elements MUST parse to any header
      location it has visibility to.

   o

   For example, if a SIP element supports two namespaces (foo and bar).
   Foo's priority-values are 1, 2 and 3 (lowest to highest), and bar's
   priority-values are A , B and C (lowest to highest).

   The following (not all inclusive list of) acceptable priority orders
   the SIP element MAY process are:

         Foo.3        Foo.3       Bar.C (highest)
         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)

                Bar.C (highest)
             Foo.3  Bar.B <= these 2 are considered equivalent)
      or     Foo.2  Bar.A <= these 2 are considered equivalent)
                Foo.1 (lowest)

             Bar.C (highest)
             Foo.3
      or     Foo.2
             Foo.1 (lowest)
   Where Bar.A and Bar.B are ignored


   The following (not all inclusive list) are not acceptable priority
   orders the SIP element MUST NOT process are:

         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

                Bar.C
             Foo.1  Bar.B
      or     Foo.3  Bar.A
                Foo.2

   Local policy determines which namespace/priority-value combinations
   are acceptable (if more than one is authorized for use within a
   domain).  The relative order of priority of the priority-values
   within the same namespace MUST never change.



Schulzrinne & Polk                                            [Page 20]


Internet-Draft         SIP Resource Priority         October 25th, 2004

8.  Examples

   The SDP message body and the BYE and ACK exchanges are the same as in
   RFC 3665 [RFC3665] and omitted for brevity.

8.1  Simple Call

   User A                  User B
     |                        |
     |       INVITE F1        |
     |----------------------->|
     |    180 Ringing F2      |
     |<-----------------------|
     |                        |
     |       200 OK F3        |
     |<-----------------------|
     |         ACK F4         |
     |----------------------->|
     |   Both Way RTP Media   |
     |<======================>|
     |                        |

   In this scenario, User A completes a call to User B directly. The
   call from A to B is marked with a resource priority indication.

   F1 INVITE User A -> User B

   INVITE sip:UserB@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Max-Forwards: 70
   From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
   To: LittleGuy <sip:UserB@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 INVITE
   Resource-Priority: dsn.flash
   Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
   Content-Type: application/sdp
   Content-Length: ...

   ...

   F2 180 Ringing User B -> User A


   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
     ;received=192.0.2.101
   From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
   To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 INVITE
   Resource-Priority: dsn.flash


Schulzrinne & Polk                                            [Page 21]


Internet-Draft         SIP Resource Priority         October 25th, 2004

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

   ...


8.2  Receiver Does Not Understand Namespace

   In this example, the receiving UA does not understand the "dsn"
   namespace and thus returns a 417 (Unknown Resource-Priority) status
   code.  We omit the message details for messages F5 through F7 since
   they are essentially the same as in the first example.

   User A                  User B
     |                        |
     |       INVITE F1        |
     |----------------------->|
     | 417 R-P failed F2      |
     |<-----------------------|
     |         ACK F3         |
     |----------------------->|
     |                        |
     |       INVITE F4        |
     |----------------------->|
     |    180 Ringing F5      |
     |<-----------------------|
     |       200 OK F6        |
     |<-----------------------|
     |         ACK F7         |
     |----------------------->|
     |                        |
     |   Both Way RTP Media   |
     |<======================>|

   F1 INVITE User A -> User B

   INVITE sip:UserB@biloxi.example.com SIP/2.0


Schulzrinne & Polk                                            [Page 22]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   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

   ACK sip:UserB@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   Max-Forwards: 70
   From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
   To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 ACK
   Content-Length: 0

   F4 INVITE User A -> User B

   INVITE sip:UserB@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Max-Forwards: 70
   From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
   To: LittleGuy <sip:UserB@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Resource-Priority: q735.3
   Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>

   Content-Type: application/sdp


Schulzrinne & Polk                                            [Page 23]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   Content-Length: ...
   ...


9.  Security Considerations

   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 to the head of the line
   scenario), to the point of prematurely terminating an existing
   session in favor of a newer one.  In some domains, this will be the
   expected behavior for authenticated and authorized users (see
   section 7). Unauthorized users MUST NOT be given this opportunity to
   abuse network/element resources.

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


Schulzrinne & Polk                                            [Page 24]


Internet-Draft         SIP Resource Priority         October 25th, 2004


   An example of this is choosing a namespace throughout a domain 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 the second domain's network.

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


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


Schulzrinne & Polk                                            [Page 25]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   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.


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




Schulzrinne & Polk                                            [Page 26]


Internet-Draft         SIP Resource Priority         October 25th, 2004

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

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


10. IANA Considerations

   This section defines two new SIP headers (10.1), one SIP OPTION tag
   (10.2), one new 4XX error code (10.3), and a new registry within the
   sip-parameters section of IANA for Resource-Priority namespaces and
   priority-values (10.4).

   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] 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
   requires documentation in an RFC using the extension header approval
   process specified in RFC 3427.


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

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


Schulzrinne & Polk                                            [Page 27]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   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


10.2 IANA Registration for Option Tag resource-priority

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


10.3 IANA Registration for Response Code 417

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


10.4 IANA Namespace and Priority-Value Registrations

   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:

                                           New   New Error
Namespace  Levels   Mode    Operation   Rej. code  code    Reference
---------  ------   ----    ---------   ---------  ----    ---------
   dsn       5     strict   preemption      no      417    [This RFC]

   drsn      6     strict   preemption      no      417    [This RFC]

   q735      5     strict   preemption      no      417    [This RFC]

   ets       5  semi-strict preferential    no      417    [This RFC]

   wps       5  semi-strict preferential    no      417    [This RFC]




Schulzrinne & Polk                                            [Page 28]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   Legend
   ------
   Namespace      = the name of the namespace
   Levels         = the number of priority-values within the namespace
   Operation      = Expected operational behavior of this namespace
   New Rej. Code  = New Rejection Codes introduced for this namespace
   New Error Code = New Error Codes introduced for this namespace
   Reference      = Document reference for this namespace


10.5 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] is this RFC):

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

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

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

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

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


11.  Acknowledgments

   Ben Campbell, Janet Gunn, Paul Kyzivat, Rohan Mahy, Mike Pierce,
   Samir Srivastava and Allison Mankin provided helpful comments.

   Dean Willis provided much help with this effort.

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






Schulzrinne & Polk                                            [Page 29]


Internet-Draft         SIP Resource Priority         October 25th, 2004

12.  References

12.1  Normative References

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

   [Q.735.3]  International Telecommunications Union, "Stage 3
              description for community of interest supplementary
              services using Signaling 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.

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


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




Schulzrinne & Polk                                            [Page 30]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   [RFC3893]  Peterson, J., "SIP Authenticated Identity Body (AIB)
              Format", RFC 3893, May 2004.

   [I-D.ietf-sip-publish]
              Niemi, A., "An Event State Publication Extension to the
              Session Initiation Protocol  (SIP)",
              draft-ietf-sip-publish-04 (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-00 (work in progress),
              February 2004.

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

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

   [RFC3487]  Schulzrinne, H., "Requirements for Resource Priority
              Mechanisms for the Session Initiation Protocol (SIP)", RFC
              3487, February 2003.

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, April 2003.

   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.


Schulzrinne & Polk                                            [Page 31]


Internet-Draft         SIP Resource Priority         October 25th, 2004


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


Authors' Addresses

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

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


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

   EMail: jmpolk@cisco.com


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 can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any


Schulzrinne & Polk                                            [Page 32]


Internet-Draft         SIP Resource Priority         October 25th, 2004

   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 Statement

   Copyright (C) The Internet Society (2004). 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.

























Schulzrinne & Polk                                            [Page 33]