Internet-Draft Columbia U. Expires: April 25th, 2005 Cisco October 25th, 2004

Transcription

1 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 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 The list of Internet-Draft Shadow Directories can be accessed at This Internet-Draft will expire on April 25th, 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] Table of Contents 1. Introduction Terminology The Resource-Priority and Accept-Resource-Priority SIP Header Fields The Resource-Priority Header Field The Accept-Resource-Priority Header Field Usage of the Resource-Priority and Accept-Resource-Priority Header Fields The resource-priority Option Tag Behavior of SIP Elements that Receive Prioritized Requests.. 8

2 4.1 General Rules Policy Guidelines Involving Preemption Policy Rejection Messages Error Conditions Known Namespace and Priority Value Handling Unknown Namespaces and Priority Values Strict Mode Semi-Strict Mode Loose Mode User Agent Client Behavior User Agent Server Behavior User Agent Servers and Preemption Policy Proxy Behavior Proxies and Preemption Policy Third-Party Authentication Backwards Compatibility Namespace Description Multiple Namespaces in a Message Examples Simple Call Receiver Does Not Understand Namespace Security Considerations Authentication and Authorization Confidentiality and Integrity Anonymity Denial-of-Service Attacks IANA Considerations IANA Registration of Resource-Priority and Accept-Resource-Priority Header Fields IANA Registration for Option Tag resource-priority IANA Registration for Response Code IANA Namespace Registrations IANA Priority-Value Registrations Acknowledgments References Normative References Informative References Authors Addresses Intellectual Property and Copyright Statements Schulzrinne & Polk [Page 2] 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.

3 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] 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 [Q.735.3] prioritization mechanism, in both the GSTN-to-IP and IP-to-GSTN directions. ITU Recommendation I [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 [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

4 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] 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 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 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]

5 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] 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)

6 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 o - o o o o o Accept-Resource-Priority o o o o o o o Accept-Resource-Priority m - m m m m m Accept-Resource-Priority 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 o o o o o o o Accept-Resource-Priority o o o o o o o Accept-Resource-Priority m m m m m m m Accept-Resource-Priority 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] 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 and the IANA registration is in Section 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

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

8 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 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] - 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 Error Conditions 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.

9 Schulzrinne & Polk [Page 10] 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 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 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 m - m m m m m Schulzrinne & Polk [Page 11] 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.

10 Following standard SIP behavior (Section 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 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] 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 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 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:

11 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 newlyavailable circuit before anyone else has knowledge of it becoming free. [RFC3487] is based on this GETS-type service. Schulzrinne & Polk [Page 13] 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.

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

13 Schulzrinne & Polk [Page 15] 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) 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] 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

14 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] 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 semistrict 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

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

16 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] 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) or Bar.C (highest) Foo.3 Bar.B <= these 2 are considered equivalent) 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 or Bar.C Foo.1 Bar.B 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.

17 Schulzrinne & Polk [Page 20] 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 F > 180 Ringing F2 < OK F3 < ACK F > 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: @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/ Ringing Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hg4bk74bf9 ;received= From: BigGuy <sip:usera@atlanta.example.com>;tag=9fxced76sl To: LittleGuy <sip:userb@biloxi.example.com>;tag= Call-ID: @atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Schulzrinne & Polk [Page 21] Contact: <sip:userb@client.biloxi.example.com;transport=tcp> Content-Length: 0 F3 200 OK User B -> User A SIP/ OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hg4bk74bf9 ;received=

18 From: BigGuy To: LittleGuy Call-ID: CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: <sip:userb@client.biloxi.example.com;transport=tcp> Content-Type: application/sdp Content-Length: 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 F > 417 R-P failed F2 < ACK F > INVITE F > 180 Ringing F5 < OK F6 < ACK F > Both Way RTP Media <======================> F1 INVITE User A -> User B INVITE sip:userb@biloxi.example.com SIP/2.0 Schulzrinne & Polk [Page 22] 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: @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/ Resource-Priority failed Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hg4bk74bf9 ;received= From: BigGuy <sip:usera@atlanta.example.com>;tag=9fxced76sl To: LittleGuy <sip:userb@biloxi.example.com>;tag= Call-ID: @atlanta.example.com CSeq: 1 INVITE

19 Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4 Contact: 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= Call-ID: @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: @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] Content-Length: 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

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