GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4412

Network Working Group H. Schulzrinne Request for Comments: 4412 Columbia U. Category: Standards Track J. Polk

                                                         Cisco Systems
                                                         February 2006
               Communications Resource Priority for
               the Session Initiation Protocol (SIP)

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document defines two new Session Initiation Protocol (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 SIP
 proxies.  It does not directly influence the forwarding behavior of
 IP routers.

Table of Contents

 1. Introduction ....................................................3
 2. Terminology .....................................................6
 3. The Resource-Priority and Accept-Resource-Priority SIP
    Header Fields ...................................................6
    3.1. The 'Resource-Priority' Header Field .......................6
    3.2. The 'Accept-Resource-Priority' Header Field ................8
    3.3. Usage of the 'Resource-Priority' and
         'Accept-Resource-Priority' .................................8
    3.4. The 'resource-priority' Option Tag .........................9
 4. Behavior of SIP Elements That Receive Prioritized Requests ......9
    4.1. Introduction ...............................................9
    4.2. General Rules ..............................................9
    4.3. Usage of Require Header with Resource-Priority ............10
    4.4. OPTIONS Request with Resource-Priority ....................10

Schulzrinne & Polk Standards Track [Page 1] RFC 4412 SIP Resource Priority February 2006

    4.5. Approaches for Preferential Treatment of Requests .........11
         4.5.1. Preemption .........................................11
         4.5.2. Priority Queueing ..................................12
    4.6. Error Conditions ..........................................12
         4.6.1. Introduction .......................................12
         4.6.2. No Known Namespace or Priority Value ...............13
         4.6.3. Authentication Failure .............................13
         4.6.4. Authorization Failure ..............................14
         4.6.5. Insufficient Resources .............................14
         4.6.6. Busy ...............................................14
    4.7. Element-Specific Behaviors ................................15
         4.7.1. User Agent Client Behavior .........................15
         4.7.2. User Agent Server Behavior .........................15
         4.7.3. Proxy Behavior .....................................16
 5. Third-Party Authentication .....................................17
 6. Backwards Compatibility ........................................17
 7. Examples .......................................................17
    7.1. Simple Call ...............................................18
    7.2. Receiver Does Not Understand Namespace ....................19
 8. Handling Multiple Concurrent Namespaces ........................21
    8.1. General Rules .............................................21
    8.2. Examples of Valid Orderings ...............................21
    8.3. Examples of Invalid Orderings .............................22
 9. Registering Namespaces .........................................23
 10. Namespace Definitions .........................................24
    10.1. Introduction .............................................24
    10.2. The "DSN" Namespace ......................................24
    10.3. The "DRSN" Namespace .....................................25
    10.4. The "Q735" Namespace .....................................25
    10.5. The "ETS" Namespace ......................................26
    10.6. The "WPS" Namespace ......................................26
 11. Security Considerations .......................................27
    11.1. General Remarks ..........................................27
    11.2. Authentication and Authorization .........................27
    11.3. Confidentiality and Integrity ............................28
    11.4. Anonymity ................................................29
    11.5. Denial-of-Service Attacks ................................29
 12. IANA Considerations ...........................................30
    12.1. Introduction .............................................30
    12.2. IANA Registration of 'Resource-Priority' and
          'Accept-Resource-Priority' Header Fields .................30
    12.3. IANA Registration for Option Tag resource-priority .......31
    12.4. IANA Registration for Response Code 417 ..................31
    12.5. IANA Resource-Priority Namespace Registration ............31
    12.6. IANA Priority-Value Registrations ........................32
 13. Acknowledgements ..............................................32
 14. References ....................................................33

Schulzrinne & Polk Standards Track [Page 2] RFC 4412 SIP Resource Priority February 2006

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.
 Even if the resources at the SIP element itself are not scarce, a SIP
 gateway may mark outgoing calls with an indication of priority, e.g.,
 on an ISUP (ISDN User Part) IAM (Initial Address Message) originated
 by a SIP gateway with the Public Switched Telephone Network (PSTN).
 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 may 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.

Schulzrinne & Polk Standards Track [Page 3] RFC 4412 SIP Resource Priority February 2006

 This document defines (Section 3) two new SIP header fields for
 communications resource priority, called 'Resource-Priority' and
 'Accept-Resource-Priority'.  The 'Resource-Priority' header field MAY
 be used by SIP user agents, including Public Switched Telephone
 Network (PSTN) gateways and terminals, and SIP proxy servers to
 influence their treatment of SIP requests, including the priority
 afforded to PSTN calls.  For PSTN gateways, the behavior translates
 into analogous schemes in the PSTN, for example, the ITU
 Recommendation Q.735.3 [Q.735.3] prioritization mechanism, in both
 the PSTN-to-IP and IP-to-PSTN directions.  ITU Recommendation I.255.3
 [I.255.3] is another example.
 A SIP request with a 'Resource-Priority' indication can be treated
 differently in these situations:
 1.  The request can be given elevated priority for access to PSTN
     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
     PSTN gateway capacity limits in effect for lower priorities.
 This header field is related to, but differs in semantics from, the
 'Priority' header field ([RFC3261], Section 20.26).  The 'Priority'
 header field describes the importance that the SIP request should
 have for the receiving human or its agent.  For example, that header
 may be factored into decisions about call routing to mobile devices
 and assistants and about call acceptance when the call destination is
 busy.  The 'Priority' header field does not affect the usage of PSTN
 gateway or proxy resources, for example.  In addition, any User Agent
 Client (UAC) can assert any 'Priority' value, and usage of 'Resource-
 Priority' header field values 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.

Schulzrinne & Polk Standards Track [Page 4] RFC 4412 SIP Resource Priority February 2006

 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.
 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 PSTN 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.
 It is likely to be common that the same SIP element will handle
 requests that bear the 'Resource-Priority' header fields and those
 that do not.
 Government entities and standardization bodies have developed several
 different priority schemes 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 (Section 11) or other appropriate mechanisms.

Schulzrinne & Polk Standards Track [Page 5] RFC 4412 SIP Resource Priority February 2006

 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
 queueing) are described in Section 4.5.  Error conditions are covered
 in Section 4.6.  Sections 4.7.1 through 4.7.3 detail the behavior of
 specific SIP elements.  Third-party authentication is briefly
 summarized in Section 5.  Section 6 describes how this feature
 affects existing systems that do not support it.
 Since calls may traverse multiple administrative domains with
 different namespaces or multiple elements with the same namespace, it
 is strongly suggested that all such domains and elements apply the
 same algorithms for the same namespace, as otherwise the end-to-end
 experience of privileged users may be compromised.
 Protocol examples are given in Section 7.  Section 8 discusses what
 happens if a request contains multiple namespaces or an element can
 handle more than one namespace.  Section 9 enumerates the information
 that namespace registrations need to provide.  Section 10 defines the
 properties of five namespaces that are registered through this
 document.  Security issues are considered in Section 11, but this
 document 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
 implementations.

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

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

3.1. The 'Resource-Priority' Header Field

 The 'Resource-Priority' request header field marks a SIP request as
 desiring prioritized access to resources, as described in the
 introduction.

Schulzrinne & Polk Standards Track [Page 6] RFC 4412 SIP Resource Priority February 2006

 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' header field in all requests.  Implementations of
 this specification MUST allow inclusion to be either by explicit user
 request or automatic for all requests.
 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: dsn.flash
 The '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" and "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 12).  Initial namespace registrations are described in
 Section 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 as some combination.  The ordering of '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

Schulzrinne & Polk Standards Track [Page 7] RFC 4412 SIP Resource Priority February 2006

   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
 process.  (This does not imply that a call with such values will find
 sufficient resources and succeed.)  The syntax of the 'Accept-
 Resource-Priority' header field is as follows:
    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' header for 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 RFC 3261
 [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 [RFC3903].)
    Header field             where proxy INV ACK CAN BYE REG OPT PRA
    ----------------------------------------------------------------
    Resource-Priority        R     amdr   o   o   o   o   o   o   o
    Accept-Resource-Priority 200   amdr   o   -   o   o   o   o   o
    Accept-Resource-Priority 417   amdr   o   -   o   o   o   o   o
    Header field             where proxy SUB NOT UPD MSG REF INF PUB
    ----------------------------------------------------------------
    Resource-Priority        R     amdr   o   o   o   o   o   o   o
    Accept-Resource-Priority 200   amdr   o   o   o   o   o   o   o
    Accept-Resource-Priority 417   amdr   o   o   o   o   o   o   o

Schulzrinne & Polk Standards Track [Page 8] RFC 4412 SIP Resource Priority February 2006

 Other request methods MAY define their own handling rules; unless
 otherwise specified, recipients MAY ignore these header fields.

3.4. The 'resource-priority' Option Tag

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

4. Behavior of SIP Elements That Receive Prioritized Requests

4.1. Introduction

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

4.2. General Rules

 The '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]
 o  ACK [RFC3261]
 o  PRACK [RFC3262]
 o  UPDATE [RFC3311]
 o  REFER [RFC3515]
 Implementations SHOULD support the 'Resource-Priority' header field
 in the following request types:
 o  MESSAGE [RFC3428]
 o  SUBSCRIBE [RFC3265]
 o  NOTIFY [RFC3265]

Schulzrinne & Polk Standards Track [Page 9] RFC 4412 SIP Resource Priority February 2006

 Note that this does not imply that all implementations have to
 support all request methods listed.
 If a SIP element receives the 'Resource-Priority' header field in a
 request other than those listed above, the header MAY be ignored,
 according to the rules of [RFC3261].
 In short, an RP actor performs the following steps when receiving a
 prioritized request.  Error behavior is described in Section 4.6.
 1.  If the RP actor recognizes none of the name spaces, it treats the
     request as if it had no 'Resource-Priority' header field.
 2.  It ascertains that the request is authorized according to local
     policy to use the priority levels indicated.  If the request is
     not authorized, it rejects it.  Examples of authorization
     policies are discussed in Security Considerations (Section 11).
 3.  If the request is authorized and resources are available (no
     congestion), it serves the request as usual.  If the request is
     authorized but resources are not available (congestion), it
     either preempts other current sessions or inserts 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
 user agent MUST respond with a 420 (Bad Extension) if it does not
 support the SIP extensions described in this document.  It then lists
 "resource-priority" in the 'Unsupported' header field included in the
 response.
 The use of the 'resource-priority' option tag in 'Proxy-Require'
 header field is NOT RECOMMENDED.

4.4. OPTIONS Request with Resource-Priority

 An OPTIONS request can be used to determine if an element supports
 the mechanism.  A compliant implementation SHOULD return an 'Accept-
 Resource-Priority' header field in OPTIONS responses enumerating all
 valid resource values, but an RP actor MAY be configured not to
 return such values or only to return them to authorized requestors.
 Following standard SIP behavior, OPTIONS responses MUST include the
 'Supported' header field that includes the 'resource-priority' option
 tag.

Schulzrinne & Polk Standards Track [Page 10] RFC 4412 SIP Resource Priority February 2006

 According to RFC 3261, Section 11, proxies that receive a request
 with a 'Max-Forwards' header field value of zero MAY answer the
 OPTIONS request, allowing a UAC to discover the capabilities of both
 proxy and user agent servers.

4.5. Approaches for Preferential Treatment of Requests

 SIP elements may use the resource priority mechanism to modify a
 variety of behaviors, such as routing requests, authentication
 requirements, override of network capacity controls, or logging.  The
 resource priority mechanism may influence the treatment of the
 request itself, the marking of outbound PSTN calls at a gateway, or
 of the session created by the request.  (Here, we use the terms
 session and call interchangeably, both implying a continuous data
 stream between two or more parties.  Sessions are established by SIP
 dialogs.)
 Below, we define two common algorithms, namely, preemption and
 priority queueing.  Preemption applies only to sessions created by
 SIP requests, while both sessions and request handling can be subject
 to priority queueing.  Both algorithms can sometimes be combined in
 the same element, although none of the namespaces described in this
 document do this.  Algorithms can be defined for each namespace or,
 in some cases, can be specific to an administrative domain.  Other
 behavior, such as request routing or network management controls, is
 not defined by this specification.
 Naturally, only SIP elements that understand this mechanism and the
 namespace and resource value perform these algorithms.  Section 4.6.2
 discusses what happens if an RP actor does not understand priority
 values contained in a request.

4.5.1. Preemption

 An RP actor following a preemption policy may disrupt an existing
 session to make room for a higher-priority incoming session.  Since
 sessions may require different amounts of bandwidth or a different
 number of circuits, a single higher-priority session may displace
 more than one lower-priority session.  Unless otherwise noted,
 requests do not preempt other requests of equal priority.  As noted
 above, the processing of SIP requests itself is not preempted.  Thus,
 since proxies do not manage sessions, they do not perform preemption.
 [RFC4411] contains more details and examples of this behavior.
 UAS behavior for preemption is discussed in Section 4.7.2.1.

Schulzrinne & Polk Standards Track [Page 11] RFC 4412 SIP Resource Priority February 2006

4.5.2. Priority Queueing

 In a priority queueing policy, requests that find no available
 resources are queued to the queue assigned to the priority value.
 Unless otherwise specified, requests are queued in first-come, first-
 served order.  Each priority value may have its own queue, or several
 priority values may share a single queue.  If a resource becomes
 available, the RP actor selects the request from the highest-priority
 non-empty queue according to the queue service policy.  For first-
 come, first-served policies, the request from that queue that has
 been waiting the longest is served.  Each queue can hold a finite
 number of pending requests.  If the per-priority-value queue for a
 newly arriving request is full, the request is rejected immediately,
 with the status codes specified in Section 4.6.5 and Section 4.6.6.
 In addition, a priority queueing policy MAY impose a waiting time
 limit for each priority class, whereby requests that exceed a
 specified waiting time are ejected from the queue and a 408 (Request
 Timeout) failure response is returned to the requestor.
 Finally, an RP actor MAY impose a global queue size limit summed
 across all queues and drop waiting lower-priority requests with a 408
 (Request Timeout) failure response.  This does not imply preemption,
 since the session has not been established yet.
 UAS behavior for queueing is discussed in Section 4.7.2.2.

4.6. Error Conditions

4.6.1. Introduction

 In this section, we describe the error behavior that is shared among
 multiple types of RP actors (including various instances of UAS such
 as trunk gateways, line gateways, and IP phones) and proxies.
 A request containing a resource priority indication can fail for four
 reasons:
 o  the RP actor does not understand the priority value
    (Section 4.6.2),
 o  the requestor is not authenticated (Section 4.6.3),
 o  an authenticated requestor is not authorized to make such a
    request (Section 4.6.4), or
 o  there are insufficient resources for an authorized request
    (Section 4.6.5).

Schulzrinne & Polk Standards Track [Page 12] RFC 4412 SIP Resource Priority February 2006

 We treat these error cases in the order that they typically arise in
 the processing of requests with Resource-Priority headers.  However,
 this order is not mandated.  For example, an RP actor that knows that
 a particular resource value cannot be served or queued MAY, as a
 matter of local policy, forgo authorization, since it would only add
 processing load without changing the outcome.

4.6.2. No Known Namespace or Priority Value

 If an RP actor does not understand any of the resource values in the
 request, the treatment depends on the presence of the 'Require'
 'resource-priority' option tag:
 1.  Without the option tag, the RP actor treats the request as if it
     contained no 'Resource-Priority' header field and processes it
     with default priority.  Resource values that are not understood
     MUST NOT be modified or deleted.
 2.  With the option tag, it MUST reject the request with a 417
     (Unknown Resource-Priority) response code.
 Making case (1) the default is necessary since otherwise there would
 be no way to successfully complete any calls in the case where a
 proxy on the way to the UAS shares no common namespaces with the UAC,
 but the UAC and UAS do have such a namespace in common.
 In general, as noted, a SIP request can contain more than one
 'Resource-Priority' header field.  This is necessary if a request
 needs to traverse different administrative domains, each with its own
 set of valid resource values.  For example, the ETS namespace might
 be enabled for United States government networks that also support
 the DSN and/or DRSN namespaces for most individuals in those domains.
 A 417 (Unknown Resource-Priority) response MAY, according to local
 policy, include an 'Accept-Resource-Priority' header field
 enumerating the acceptable resource values.

4.6.3. Authentication Failure

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

Schulzrinne & Polk Standards Track [Page 13] RFC 4412 SIP Resource Priority February 2006

4.6.4. Authorization Failure

 If the RP actor receives an authenticated request with a namespace
 and priority value it recognizes but the originator is not authorized
 for that level of service, the element MUST return a 403 (Forbidden)
 response.

4.6.5. Insufficient Resources

 Insufficient resource conditions can occur on proxy servers and user
 agent servers, typically trunk gateways, if an RP actor receives an
 authorized request, has insufficient resources, and the request
 neither preempts another session nor is queued.  A request can fail
 because the RP actor has either insufficient processing capacity to
 handle the SIP request or insufficient bandwidth or trunk capacity to
 establish the requested session for session-creating SIP requests.
 If the request fails because the RP actor cannot handle the signaling
 load, the RP actor responds with 503 (Service Unavailable).
 If there is not enough bandwidth, or if there is an insufficient
 number of trunks, a 488 (Not Acceptable Here) response indicates that
 the RP actor is rejecting the request due to media path availability,
 such as insufficient gateway resources.  In that case, [RFC3261]
 advises that a 488 response SHOULD include a 'Warning' header field
 with a reason for the rejection; warning code 370 (Insufficient
 Bandwidth) is typical.
 For systems implementing queueing, if the request is queued, the UAS
 will return 408 (Request Timeout) if the request exceeds the maximum
 configured waiting time in the queue.

4.6.6. Busy

 Resource contention also occurs when a call request arrives at a UAS
 that is unable to accept another call, because the UAS either has
 just one line appearance or has active calls on all line appearances.
 If the call request indicates an equal or lower priority value when
 compared to all active calls present on the UAS, the UAS returns a
 486 (Busy here) response.
 If the request is queued instead, the UAS will return a 408 (Request
 Timeout) if the request exceeds the maximum configured waiting time
 in the device queue.
 If a proxy gets 486 (Busy Here) responses on all branches, it can
 then return a 600 (Busy Everywhere) response to the caller.

Schulzrinne & Polk Standards Track [Page 14] RFC 4412 SIP Resource Priority February 2006

4.7. Element-Specific Behaviors

4.7.1. User Agent Client Behavior

 SIP UACs supporting this specification MUST be able to generate the
 'Resource-Priority' header field for requests that require elevated
 resource access priority.  As stated previously, the UAC SHOULD be
 able to generate more than one resource value in a single SIP
 request.
 Upon receiving a 417 (Unknown Resource-Priority) response, the UAC
 MAY attempt a subsequent request with the same or different resource
 value.  If available, it SHOULD choose authorized resource values
 from the set of values returned in the 'Accept-Resource-Priority'
 header field.

4.7.1.1. User Agent Client Behavior with a Preemption Algorithm

 A UAC that requests a priority value that may cause preemption MUST
 understand a Reason header field in the BYE request explaining why
 the session was terminated, as discussed in [RFC4411].

4.7.1.2. User Agent Client Behavior with a Queueing Policy

 By standard SIP protocol rules, a UAC MUST be prepared to receive a
 182 (Queued) response from an RP actor that is currently at capacity,
 but that has put the original request into a queue.  A UAC MAY
 indicate this queued status to the user by some audio or visual
 indication to prevent the user from interpreting the call as having
 failed.

4.7.2. User Agent Server Behavior

 The precise effect of the 'Resource-Priority' indication depends on
 the type of UAS, the namespace, and local policy.

4.7.2.1. User Agent Servers and Preemption Algorithm

 A UAS compliant with this specification MUST terminate a session
 established with a valid namespace and lower-priority value in favor
 of a new session set up with a valid namespace and higher relative
 priority value, unless local policy has some form of call-waiting
 capability enabled.  If a session is terminated, the BYE method is
 used with a 'Reason' header field indicating why and where the
 preemption took place.
 Implementors have a number of choices in how to implement preemption
 at IP phones with multiple line presences, i.e., with devices that

Schulzrinne & Polk Standards Track [Page 15] RFC 4412 SIP Resource Priority February 2006

 can handle multiple simultaneous sessions.  Naturally, if that device
 has exhausted the number of simultaneous sessions, one of the
 sessions needs to be replaced.  If the device has spare sessions, an
 implementation MAY choose to alert the callee to the arrival of a
 higher-priority call.  Details may also be set by local or namespace
 policy.
 [RFC4411] provides additional information in the case of purposeful
 or administrative termination of a session by including the Reason
 header in the BYE message that states why the BYE was sent (in this
 case, a preemption event).  The mechanisms in that document allow
 indication of where the termination occurred ('at the UA', 'within a
 reservation', 'at a IP/PSTN gateway') and include call flow examples
 of each reason.

4.7.2.2. User Agent Servers and Queue-Based Policy

 A UAS compliant with this specification SHOULD generate a 182
 (Queued) response if that element's resources are busy, until it is
 able to handle the request and provide a final response.  The
 frequency of such provisional messages is governed by [RFC3261].

4.7.3. Proxy Behavior

 SIP proxies MAY ignore the 'Resource-Priority' header field.  SIP
 proxies MAY reject any unauthenticated request bearing that header
 field.
 When the 'Require' header field is included in a message, it ensures
 that in parallel forking, only branches that support the resource-
 priority mechanism succeed.
 If S/MIME encapsulation is used according to Section 23 of RFC 3261,
 special considerations apply.  As tabulated in Section 3.3, the
 'Resource-Priority' header field can be modified by proxies and thus
 is exempted from the integrity checking described in Section 23.4.1.1
 of RFC 3261.  Since it may need to be inspected or modified by
 proxies, the header field MUST also be placed in the "outer" message
 if the UAC would like proxy servers to be able to act on the header
 information.  Similar considerations apply if parts of the message
 are integrity protected or encrypted as described in [RFC3420].
 If S/MIME is not used, or if the 'Resource-Priority' header field is
 in the "outer" header, SIP proxies MAY downgrade or upgrade the
 'Resource-Priority' of a request or insert a new 'Resource-Priority'
 header if allowed by local policy.

Schulzrinne & Polk Standards Track [Page 16] RFC 4412 SIP Resource Priority February 2006

 If a stateful proxy has authorized a particular resource priority
 level, and if it offers differentiated treatment to responses
 containing resource priority levels, the proxy SHOULD ignore any
 higher value contained in responses, to prevent colluding user agents
 from artificially raising the priority level.
 A SIP proxy MAY use the 'Resource-Priority' indication in its routing
 decisions, e.g., to retarget to a SIP node or SIP URI that is
 reserved for a particular resource priority.
 There are no special considerations for proxies when forking requests
 containing a resource priority indication.
 Otherwise, the proxy behavior is the same as for user agent servers
 described in Section 4.7.2.

5. Third-Party Authentication

 In some cases, the RP actor may not be able to authenticate the
 requestor or determine whether an authenticated user is authorized to
 make such a request.  In these circumstances, the SIP entity may
 avail itself of general SIP mechanisms that are not specific to this
 application.  The authenticated identity management mechanism
 [RFC3893] allows a third party to verify the identity of the
 requestor and to certify this towards an RP actor.  In networks with
 mutual trust, the SIP-asserted identity mechanism [RFC3325] can help
 the RP actor determine the identity of the requestor.

6. Backwards Compatibility

 The resource priority mechanism described in this document is fully
 backwards compatible with SIP systems following [RFC3261].  Systems
 that do not understand the mechanism can only deliver standard, not
 elevated, service priority.  User agent servers and proxies can
 ignore any 'Resource-Priority' header field just like any other
 unknown header field and then treat the request like any other
 request.  Naturally, the request may still succeed.

7. Examples

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

Schulzrinne & Polk Standards Track [Page 17] RFC 4412 SIP Resource Priority February 2006

7.1. Simple Call

 User A                  User B
   |                        |
   |       INVITE F1        |
   |----------------------->|
   |    180 Ringing F2      |
   |<-----------------------|
   |                        |
   |       200 OK F3        |
   |<-----------------------|
   |         ACK F4         |
   |----------------------->|
   |   Both Way RTP Media   |
   |<======================>|
   |                        |
 In this scenario, User A completes a call to User B directly.  The
 call from A to B is marked with a resource priority indication.
 F1 INVITE User A -> User B
 INVITE sip:UserB@biloxi.example.com SIP/2.0
 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 Max-Forwards: 70
 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
 To: LittleGuy <sip:UserB@biloxi.example.com>
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Resource-Priority: dsn.flash
 Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
 Content-Type: application/sdp
 Content-Length: ...
 ...
 F2 180 Ringing User B -> User A
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   ;received=192.0.2.101
 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
 To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
 Content-Length: 0

Schulzrinne & Polk Standards Track [Page 18] RFC 4412 SIP Resource Priority February 2006

 F3 200 OK User B -> User A
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   ;received=192.0.2.101
 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
 To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
 Content-Type: application/sdp
 Content-Length: ...
 ...

7.2. Receiver Does Not Understand Namespace

 In this example, the receiving UA does not understand the "dsn"
 namespace and thus returns a 417 (Unknown Resource-Priority) status
 code.  We omit the message details for messages F5 through F7, since
 they are essentially the same as in the first example.
 User A                  User B
   |                        |
   |       INVITE F1        |
   |----------------------->|
   | 417 R-P failed F2      |
   |<-----------------------|
   |         ACK F3         |
   |----------------------->|
   |                        |
   |       INVITE F4        |
   |----------------------->|
   |    180 Ringing F5      |
   |<-----------------------|
   |       200 OK F6        |
   |<-----------------------|
   |         ACK F7         |
   |----------------------->|
   |                        |
   |   Both Way RTP Media   |
   |<======================>|

Schulzrinne & Polk Standards Track [Page 19] RFC 4412 SIP Resource Priority February 2006

 F1 INVITE User A -> User B
 INVITE sip:UserB@biloxi.example.com SIP/2.0
 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 Max-Forwards: 70
 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
 To: LittleGuy <sip:UserB@biloxi.example.com>
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Require: resource-priority
 Resource-Priority: dsn.flash
 Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
 Content-Type: application/sdp
 Content-Length: ...
 ...
 F2 417 Resource-Priority failed  User B -> User A
 SIP/2.0 417 Unknown Resource-Priority
 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   ;received=192.0.2.101
 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
 To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4
 Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
 Content-Type: application/sdp
 Content-Length: 0
 F3 ACK User A -> User B
 ACK sip:UserB@biloxi.example.com SIP/2.0
 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
 Max-Forwards: 70
 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
 To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 ACK
 Content-Length: 0

Schulzrinne & Polk Standards Track [Page 20] RFC 4412 SIP Resource Priority February 2006

 F4 INVITE User A -> User B
 INVITE sip:UserB@biloxi.example.com SIP/2.0
 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 Max-Forwards: 70
 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
 To: LittleGuy <sip:UserB@biloxi.example.com>
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 2 INVITE
 Require: resource-priority
 Resource-Priority: q735.3
 Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
 Content-Type: application/sdp
 Content-Length: ...
 ...

8. Handling Multiple Concurrent Namespaces

8.1. General Rules

 A single SIP request MAY contain resource values from multiple
 namespaces.  As noted earlier, an RP actor disregards all namespaces
 it does not recognize.  This specification only addresses the case
 where an RP actor then selects one of the remaining resource values
 for processing, usually choosing the one with the highest relative
 priority.
 If an RP actor understands multiple namespaces, it MUST create a
 local total ordering across all resource values from these
 namespaces, maintaining the relative ordering within each namespace.
 It is RECOMMENDED that the same ordering be used across an
 administrative domain.  However, there is no requirement that such
 ordering be the same across all administrative domains.

8.2. Examples of Valid Orderings

 Below are a set of examples of an RP actor that supports two
 namespaces, foo and bar.  Foo's priority-values are 3 (highest), then
 2, and then 1 (lowest), and bar's priority-values are C (highest),
 then B, and then A (lowest).

Schulzrinne & Polk Standards Track [Page 21] RFC 4412 SIP Resource Priority February 2006

 Below are five lists of acceptable priority orders the SIP element
 may use:
     Foo.3        Foo.3       Bar.C    (highest priority)
     Foo.2        Bar.C       Foo.3
     Foo.1   or   Foo.2   or  Foo.2
     Bar.C        Bar.B       Foo.1
     Bar.B        Foo.1       Bar.B
     Bar.A        Bar.A       Bar.A    (lowest priority)
            Bar.C       (highest priority)
         Foo.3  Bar.B   (both treated with equal priority (FIFO))
  or     Foo.2  Bar.A   (both treated with equal priority (FIFO))
            Foo.1       (lowest priority)
         Bar.C     (highest priority)
         Foo.3
  or     Foo.2
         Foo.1     (lowest priority)
 In the last example above, Bar.A and Bar.B are ignored.

8.3. Examples of Invalid Orderings

 Based on the priority order of the namespaces above, the following
 combinations are examples of orderings that are NOT acceptable and
 MUST NOT be configurable:
        Example 1    Example 2   Example 3
        ---------    ---------   ---------
          Foo.3        Foo.3       Bar.C
          Foo.2        Bar.A       Foo.1
          Foo.1   or   Foo.2   or  Foo.3
          Bar.C        Bar.B       Foo.2
          Bar.A        Foo.1       Bar.A
          Bar.B        Bar.C       Bar.B
               Example 4
               ---------
                 Bar.C
              Foo.1  Bar.B
       or     Foo.3  Bar.A
                 Foo.2

Schulzrinne & Polk Standards Track [Page 22] RFC 4412 SIP Resource Priority February 2006

 These examples are invalid since the following global orderings are
 not consistent with the namespace-internal order:
 o  In Example 1, Bar.A is ordered higher than Bar.B.
 o  In Example 2, Bar.A is ordered higher than Bar.B and Bar.C.
 o  In Example 3, Foo.1 is ordered higher than Foo.2 and Foo.3.
 o  In Example 4, Foo.1 is ordered higher than Foo.3 and Foo.2.

9. Registering Namespaces

 Organizations considering the use of the Resource-Priority header
 field should investigate whether an existing combination of namespace
 and priority-values meets their needs.  For example, emergency first
 responders around the world are discussing utilizing this mechanism
 for preferential treatment in future networks.  Jurisdictions SHOULD
 attempt to reuse existing IANA registered namespaces where possible,
 as a goal of this document is not to have unique namespaces per
 jurisdiction serving the same purpose, with the same usage of
 priority levels.  This will greatly increase interoperability and
 reduce development time, and probably reduce future confusion if
 there is ever a need to map one namespace to another in an
 interworking function.
 Below, we describe the steps necessary to register a new namespace.
 A new namespace MUST be defined in a Standards Track RFC, following
 the 'Standards Action' policy in [RFC2434], and MUST include the
 following facets:
 o  It must define the namespace label, a unique namespace label
    within the IANA registry for the SIP Resource-Priority header
    field.
 o  It must enumerate the priority levels (i.e., 'r-priority' values)
    the namespace is using.  Note that only finite lists are
    permissible, not unconstrained integers or tokens, for example.
 o  The priority algorithm (Section 4.5), identifying whether the
    namespace is to be used with priority queueing ("queue") or
    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 or priority
    queueing, the algorithm must be described, taking into account all
    RP actors (UAC, UAS, proxies).

Schulzrinne & Polk Standards Track [Page 23] RFC 4412 SIP Resource Priority February 2006

 o  A namespace may either reference an existing list of priority
    values or define a new finite list of priority values in relative
    priority order for IANA registration within the sip-parameters
    Resource-Priority priority-values registry.  New priority-values
    SHOULD NOT be added to a previously IANA-registered list
    associated with a particular namespace, as this may cause
    interoperability problems.  Unless otherwise specified, it is
    assumed that all priority values confer higher priority than
    requests without a priority value.
 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
    that summarizes the features of the namespace and is included into
    IANA Resource-Priority Namespace registration:
                       Intended          New     New resp.
 Namespace  Levels     algorithm      warn-code    code    Reference
 ---------  ------  ----------------  ---------  --------  ---------
  <label>   <# of    <preemption     <new warn  <new resp.  <RFC>
           levels>    or queue>        code>      code>
 If information on new response codes, rejection codes, or error
 behaviors is omitted, it is to be assumed that the namespace defines
 no new parameters 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 namespace names are case insensitive and are customarily
 rendered as lowercase in protocol requests.

10.2. The "DSN" Namespace

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

Schulzrinne & Polk Standards Track [Page 24] RFC 4412 SIP Resource Priority February 2006

 The DSN namespace has a finite list of relative priority-values,
 listed below from lowest priority to highest priority:
    (lowest)  dsn.routine
              dsn.priority
              dsn.immediate
              dsn.flash
    (highest) dsn.flash-override
 The DSN namespace uses the preemption algorithm (Section 4.5.1).

10.3. The "DRSN" Namespace

 The DRSN namespace comes from the name of a US government network,
 called "The Defense RED Switched Network".
 The DRSN namespace defines the following resource values, listed from
 lowest priority to highest priority:
    (lowest)  drsn.routine
              drsn.priority
              drsn.immediate
              drsn.flash
              drsn.flash-override
    (highest) drsn.flash-override-override
 The DRSN namespace uses the preemption algorithm (Section 4.5.1).
 The DRSN namespace differs in one algorithmic aspect from the DSN and
 Q735 namespaces.  The behavior for the 'flash-override-override'
 priority value differs from the other values.  Normally, requests do
 not preempt those of equal priority, but a newly arriving 'flash-
 override-override' request will displace another one of equal
 priority if there are insufficient resources.  This can also be
 expressed as saying that 'flash-override-override' requests defend
 themselves as 'flash-override' only.

10.4. The "Q735" Namespace

 Q.735.3 [Q.735.3] was created to be a commercial version of the
 operationally equivalent DSN specification for Multi-Level Precedence
 and Preemption (MLPP).  The Q735 namespace is defined here in the
 same manner.

Schulzrinne & Polk Standards Track [Page 25] RFC 4412 SIP Resource Priority February 2006

 The Q735 namespace defines the following resource values, listed from
 lowest priority to highest priority:
    (lowest)  q735.4
              q735.3
              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 from
 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 queueing
 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 from
 lowest priority to highest priority:
    (lowest)  wps.4
              wps.3
              wps.2
              wps.1
    (highest) wps.0

Schulzrinne & Polk Standards Track [Page 26] RFC 4412 SIP Resource Priority February 2006

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

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 PSTN gateway, cause additional congestion during
 emergencies affecting the PSTN, or deny service to legitimate users.
 In SIP end systems, such as IP phones, this mechanism could
 inappropriately terminate existing sessions and calls.
 Thus, while the indication itself does not have to provide separate
 authentication, SIP requests containing this header are very likely
 to have higher authentication requirements than those without.
 These authentication and authorization requirements extend to users
 within the administrative 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 that support this extension MUST
 implement SIP over TLS [RFC3546], the 'sips' URI scheme as described
 in Section 26.2 of RFC 3261, and Digest Authentication [RFC2617] as
 described in Section 22 of RFC 3261.  In addition, user agents that
 support this extension SHOULD also implement S/MIME [RFC3851] as
 described in Section 23 of RFC 3261 to allow for signing and
 verification of signatures over requests that use this extension.

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

Schulzrinne & Polk Standards Track [Page 27] RFC 4412 SIP Resource Priority February 2006

 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 [TRAIT] "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 besides the identity of the
 caller, such as the requested destination.  Namespaces MAY also
 impose particular authentication or authorization considerations that
 are stricter than the baseline described here.

11.3. Confidentiality and Integrity

 Calls that 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 those 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

Schulzrinne & Polk Standards Track [Page 28] RFC 4412 SIP Resource Priority February 2006

 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 encapsulation would be 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).

11.4. Anonymity

 Some users may wish to remain anonymous to the request destination.
 Anonymity for requests with resource priority is no different from
 that 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].

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

Schulzrinne & Polk Standards Track [Page 29] RFC 4412 SIP Resource Priority February 2006

12. IANA Considerations

12.1. Introduction

 This section defines two new SIP headers (Section 12.2), one SIP
 option tag (Section 12.3), one new 4xx error code (Section 12.4), a
 new registry within the sip-parameters section of IANA for Resource-
 Priority namespaces (Section 12.5), and a new registry within the
 sip-parameters section of IANA for Resource-Priority and priority-
 values (Section 12.6).
 Additional namespaces and priority values MUST be registered with
 IANA, as described in Section 9.
 The SIP Change Process [RFC3427] 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.
 Registration policies for new namespaces are defined in Section 9.

12.2. IANA Registration of 'Resource-Priority' and 'Accept-Resource-

     Priority' Header Fields
 The following is the registration for the 'Resource-Priority' header
 field:
 RFC number: 4412
 Header name: 'Resource-Priority'
 Compact form: none
 The following is the registration for the 'Accept-Resource-Priority'
 header field:
 RFC number: 4412
 Header name: Accept-Resource-Priority
 Compact form: none

Schulzrinne & Polk Standards Track [Page 30] RFC 4412 SIP Resource Priority February 2006

12.3. IANA Registration for Option Tag resource-priority

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

12.4. IANA Registration for Response Code 417

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

12.5. IANA Resource-Priority Namespace Registration

 A new registry ("Resource-Priority Namespaces") in the sip-parameters
 section of IANA has been created, taking a form similar to this table
 below:
                       Intended       New warn-    New resp.
 Namespace  Levels     Algorithm      code         code      Reference
 ---------  ------  ----------------  ---------    --------- ---------
    dsn       5        preemption        no           no     [RFC4412]
    drsn      6        preemption        no           no     [RFC4412]
    q735      5        preemption        no           no     [RFC4412]
    ets       5        queue             no           no     [RFC4412]
    wps       5        queue             no           no     [RFC4412]
 Legend
 ------
 Namespace        The unique string identifying the namespace.
 Levels           The number of priority-values within the namespace.
 Algorithm        Intended operational behavior of SIP elements
                  implementing this namespace.
 New Warn code    New Warning Codes (warn-codes) introduced by
                  this namespace.
 New Resp. code   New SIP response codes introduced by this namespace.
 Reference        IETF document reference for this namespace.

Schulzrinne & Polk Standards Track [Page 31] RFC 4412 SIP Resource Priority February 2006

12.6. IANA Priority-Value Registrations

 A new registry ("Resource-Priority Priority-values") in the sip-
 parameters section of IANA has been created, taking a form similar to
 this table below:
 Namespace: drsn
 Reference: RFC 4412
 Priority-Values (least to greatest): "routine", "priority",
    "immediate", "flash", "flash-override", "flash-override-override"
 Namespace: dsn
 Reference: RFC 4412
 Priority-Values (least to greatest): "routine", "priority",
    "immediate", "flash", "flash-override"
 Namespace: q735
 Reference: RFC 4412
 Priority values (least to greatest): "4", "3", "2", "1", "0"
 Namespace: ets
 Reference: RFC 4412
 Priority values (least to greatest): "4", "3", "2", "1", "0"
 Namespace: wps
 Reference: RFC 4412
 Priority values (least to greatest): "4", "3", "2", "1", "0"

13. Acknowledgements

 Ben Campbell, Ken Carlberg, Paul Kyzivat, Rohan Mahy, Allison Mankin,
 Xavier Marjou, Piers O'Hanlon, Mike Pierce, Samir Srivastava, and
 Dale Worley provided helpful comments.
 Dean Willis provided much help with this effort.
 Martin Dolly, An Nguyen, and Niranjan Sandesara assisted with the ETS
 and WPS namespaces.
 Janet Gunn helped improve the text on queueing-based priority.

Schulzrinne & Polk Standards Track [Page 32] RFC 4412 SIP Resource Priority February 2006

14. References

14.1. Normative References

 [I.255.3]  International Telecommunications Union, "Integrated
            Services Digital Network (ISDN) - General Structure and
            Service Capabilities - Multi-Level Precedence and
            Preemption", Recommendation I.255.3, July 1990.
 [Q.735.3]  International Telecommunications Union, "Stage 3
            description for community of interest supplementary
            services using Signalling System No. 7: Multi-level
            precedence and preemption", Recommendation Q.735.3,
            March 1993.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 2434,
            October 1998.
 [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP:  Session Initiation Protocol", RFC 3261,
            June 2002.
 [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
            Provisional Responses in Session Initiation Protocol
            (SIP)", RFC 3262, June 2002.
 [RFC3265]  Roach, A.B., "Session Initiation Protocol (SIP)-Specific
            Event Notification", RFC 3265, June 2002.
 [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
            UPDATE Method", RFC 3311, October 2002.
 [RFC3420]  Sparks, R., "Internet Media Type message/sipfrag", RFC
            3420, November 2002.
 [RFC3428]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
            and D. Gurle, "Session Initiation Protocol (SIP) Extension
            for Instant Messaging", RFC 3428, December 2002.
 [RFC4411]  Polk, J., "Extending the Session Initiation Protocol (SIP)
            Reason Header for Preemption Events", RFC 4411, February
            2006.

Schulzrinne & Polk Standards Track [Page 33] RFC 4412 SIP Resource Priority February 2006

14.2. Informative References

 [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
            Leach, P., Luotonen, A., and L. Stewart, "HTTP
            Authentication: Basic and Digest Access Authentication",
            RFC 2617, June 1999.
 [RFC2976]  Donovan, S., "The SIP INFO Method", RFC 2976, October
            2000.
 [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
            Initiation Protocol (SIP)", RFC 3323, November 2002.
 [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
            Extensions to the Session Initiation Protocol (SIP) for
            Asserted Identity within Trusted Networks", RFC 3325,
            November 2002.
 [RFC3427]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
            and B. Rosen, "Change Process for the Session Initiation
            Protocol (SIP)", BCP 67, RFC 3427, December 2002.
 [RFC3487]  Schulzrinne, H., "Requirements for Resource Priority
            Mechanisms for the Session Initiation Protocol (SIP)", RFC
            3487, February 2003.
 [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
            Method", RFC 3515, April 2003.
 [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
            and T. Wright, "Transport Layer Security (TLS)
            Extensions", RFC 3546, June 2003.
 [RFC3550]  Schulzrinne, H.,  Casner, S., Frederick, R., and V.
            Jacobson, "RTP: A Transport Protocol for Real-Time
            Applications", STD 64, RFC 3550, July 2003.
 [RFC3665]  Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and
            K. Summers, "Session Initiation Protocol (SIP) Basic Call
            Flow Examples", BCP 75, RFC 3665, December 2003.
 [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
            Extensions (S/MIME) Version 3.1 Message Specification",
            RFC 3851, July 2004.
 [RFC3893]  Peterson, J., "Session Initiation Protocol (SIP)
            Authenticated Identity Body (AIB) Format", RFC 3893,
            September 2004.

Schulzrinne & Polk Standards Track [Page 34] RFC 4412 SIP Resource Priority February 2006

 [RFC3903]  Niemi, A., "Session Initiation Protocol (SIP) Extension
            for Event State Publication", RFC 3903, October 2004.  for
            Event State Publication", RFC 3903, October 2004.
 [TRAIT]    Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,
            "Trait-based Authorization Requirements for the Session
            Initiation Protocol (SIP)", Work in Progress,
            February 2005.

Authors' Addresses

 Henning Schulzrinne
 Columbia University
 Department of Computer Science
 450 Computer Science Building
 New York, NY  10027
 US
 Phone: +1 212 939 7004
 EMail: hgs@cs.columbia.edu
 URI:   http://www.cs.columbia.edu
 James Polk
 Cisco Systems
 2200 East President George Bush Turnpike
 Richardson, TX  75082
 US
 EMail: jmpolk@cisco.com

Schulzrinne & Polk Standards Track [Page 35] RFC 4412 SIP Resource Priority February 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 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.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 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 procedures with respect to rights in 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
 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.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Schulzrinne & Polk Standards Track [Page 36]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4412.txt · Last modified: 2006/02/22 17:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki