SIP WG Janet Gunn Internet-Draft CSC Martin Dolly Expires: May 12, 2008 AT&T Labs Tim Dwight Verizon November 9, 2007 Requirements for SIP Resource Priority Header in SIP Responses draft-gunn-sip-req-for-rph-in-responses-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 9th, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. The Internet Draft "Allowing SIP Resource Priority Header in SIP Responses" (draft-polk-sip-rph-in-responses-00) describes a modification to RFC4412 to permit RPH in responses. This document describes one of the requirements associated with systems using RPH, that could be satisfied by the modification of RFC 4412 to permit RPH on responses, and is not easily met by other methods. This ID provides Gunn Expires May 9th, 2008 [Page 1] Internet-Draft Requirements for SIP RPH in Responses November 2007 additional motivation for SIP RPH in Responses. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction The Session Initiation Protocol (SIP) Resource Priority Header (RPH) [RFC4412], in its current form, is ignored by SIP entities if in SIP responses. It was a design choice during RFC 4412's development that only stateful SIP elements would grant SIP messages preferential treatment. Limiting servers which process the RPH to only being transaction stateful is now considered a bad design choice in certain scenarios, such as those entities within trusted networks. This document describes in greater detail a requirement, within a trusted network, which cannot be met by RFC 4412 in its current form, without RPH on responses. The requirement can be met if RPH on responses is permitted. As stated in RFC 3487 [RFC3487] and RFC 4412, one of the motivation for RPH is to support the migration of the Government Emergency Telecommunications Service (GETS) and Wireless Priority Service (WPS) from the service providers' Circuit Switched Networks to the same service providers' Packet Switched Networks, using IP and SIP. The ets and wps name spaces, each with 5 priority values, are intended to support this. We have simplified the description of the GETS/WPS service and call flow, in order to focus on the facet that is most directly related to the need for RPH in responses. In the GETS/WPS paradigm, each authorized user (a "Service User") is assigned a priority (out of 5) when GETS/WPS is invoked, for times in which congestion may be experienced, reducing the probability of successful communications. GETS/WPS treatment is especially important for resources in the access networks where bottlenecks are most likely. The user does NOT submit the priority level when requesting GETS/WPS service- in fact, in many cases, the Service User does not know his/her priority level, and nor does the User Equipment (UE) at which s/he is subscribed. This paradigm introduces some requirements that are not met by RFC 4412 without RPH in responses. Note that this is different from the MLPP paradigm associated with the dsn and dsrn namespaces. In the MLPP paradigm, the user requests a specific priority level. The authentication/ authorization process then determines whether the user is entitled to the requested priority level. Gunn Expires May 9th, 2008 [Page 2] Internet-Draft Requirements for SIP RPH in Responses November 2007 2. Problem Statement The high level call flow (whether in the circuit switched network or the IP network) for a GETS/WPS call is that the user initiates a call requesting the GETS/WPS service (but not specifying the priority level). (In the current system this is indicated in the "dialed digits". In SIP this will be reflected in the URI.) The specialized GETS/WPS server (referred to as the GETS Application Server, or GETS AS) then determines whether the user and/or equipment are authenticated and authorized to use GETS/WPS. If so, it extracts the user's priority level from a data base. The GETS AS also extracts or generates the URI for the called party. In the SIP domain, the wps namespace (with the user's priority value), in conjunction with the ets namespace, in the RPH is used to convey the priority value extracted from the data base. The rest of this requirement statement will focus on the wps namespace with the user's priority value. (In the circuit switched domain, using SS7, the Calling Party Category (CPC) setting is used to indicate a request for priority service, and the Precedence Parameter is used to indicate the priority level extracted from the database- without implying any preemption.) The network then proceeds to allocate/reserve resources in both the originating and terminating access networks, whether IP or circuit switched. In the IP network it would typically use preconditions, as described in RFC 3312 [RFC3312]. At a PSTN gateway, the indication that it is a GETS/WPS call, and the priority level, would be translated into the appropriate ISUP parameters, and the legacy GETS/WPS mechanisms would be used to ensure a high probability of completion in the ISUP network. In either case, the user's priority level is needed in allocating resources in both the originating and terminating access networks. The INVITE that is sent toward the called party's UA will contain the RPH with the calling user's priority level. The same information needs to be sent toward the calling party, so it can be used in the originating access network. Typically, the messages sent back toward the calling party (once the priority value has been extracted from the data base, but before the bearer path is established) would be responses (e.g., 183) rather than requests. 2.1 Sample Call Flow Figure 1 shows the call flow for basic session establishment using preconditions (as described in RFC 3312). Gunn Expires May 9th, 2008 [Page 3] Internet-Draft Requirements for SIP RPH in Responses November 2007 A B | | |-------------(1) INVITE SDP1--------------->| | | |<------(2) 183 Session Progress SDP2--------| | *** *** | |--*R*-----------(3) PRACK-------------*R*-->| | *E* *E* | |<-*S*-------(4) 200 OK (PRACK)--------*S*---| | *E* *E* | | *R* *R* | | *V* *V* | | *A* *A* | | *T* *T* | | *I* *I* | | *O* *O* | | *N* *N* | | *** *** | | *** | | *** | |-------------(5) UPDATE SDP3--------------->| | | |<--------(6) 200 OK (UPDATE) SDP4-----------| | | |<-------------(7) 180 Ringing---------------| | | |-----------------(8) PRACK----------------->| | | |<------------(9) 200 OK (PRACK)-------------| | | | | | | |<-----------(10) 200 OK (INVITE)------------| | | |------------------(11) ACK----------------->| | | | | Figure 1: Basic session establishment using preconditions Figure 2 shows the addition of the GETS AS, to authenticate and authorize the GETS/WPS request, and to extract the user's priority level from the database. Note that the GETS AS is B2BUA that remains in the call/session path in order to monitor call/session progress and initiate subsequent call processing. It also shows the addition of the RPH with the wps namespace in subsequent requests. In this case, A knows that GETS/WPS service has been requested, but does no know the user's priority level. Based on the information included in the initial INVITE, the GETS Application server authenticates the user, and looks up the user's priority level in the co-located Gunn Expires May 9th, 2008 [Page 4] Internet-Draft Requirements for SIP RPH in Responses November 2007 A GETS AS B | | | |-----------(1) INVITE SDP1----->| | | Look up in data base for | | priority level (=3) | | | | | |----(2) INVITE SDP1 RPH wps.3-->| | | | | |<-(3) 183 Session Progress SDP2-| |<-(4) 183 Session Progress SDP2-| | | *** | | |--*R*---------(5) PRACK-------->| *** | | *E* |---(6) PRACK RPH wps.3----*R*-->| | *S* | *E* | | *E* |<--(7) 200 OK (PRACK)-----*S*---| |<-*R*-----(8) 200 OK (PRACK)----| *E* | | *V* | *R* | | *A* | *V* | | *T* | *A* | | *I* | *T* | | *O* | *I* | | *N* | *O* | | *** | *N* | | *** | *** | | *** | *** | |--(9) UPDATE SDP3-------------->| | | |-(10) UPDATE SDP3 RPH wps.3--->| | | | | |<---(11) 200 OK (UPDATE) SDP4---| |<--(12) 200 OK (UPDATE) SDP4----| | | | | | |<---------(13) 180 Ringing------| |<-------(14) 180 Ringing--------| | | | | |--------------(15) PRACK------->| | | |------(16) PRACK RPH wps.3----->| | | | | |<--(17) 200 OK (PRACK)----------| |<--------(18) 200 OK (PRACK)----| | | | | | | | | | | | |<--(19) 200 OK (INVITE)---------| |<-----(20) 200 OK (INVITE)------| | | | | |---------------(21) ACK-------->| | | |-------(22) ACK RPH wps.3------>| | | | Figure 2: Modified session establishment using preconditions, with addition of GETS AS Gunn Expires May 9th, 2008 [Page 5] Internet-Draft Requirements for SIP RPH in Responses November 2007 database. In this case it determines that the user priority corresponds to wps priority level 3. The GETS AS therefore inserts an RPH with "wps.3" in the INVITE (2) it sends on to B. When B receives the INVITE with the RPH, it uses the "wps priority level 3" information, in addition to the information in SDP1, in making the reservation at the B end. B then sends 183 Session Progress back to A, by way of the GETS AS. In order to properly set up the reservation at the "A" end, A also needs to know that it should use "wps priority level 3" in setting up the reservation. If The RPH can be included in the 183 (4) response sent from the GETS AS to A, then A will have the information it needs. If the RPH cannot be included in the response, it is not clear how A will get the "wps priority level 3" information. This call flow illustrates the requirement that cannot be met by RPH without RPH in responses. There are of course, a number of other possible call flows, but the problem of conveying "wps.3" to A remains. 3. Potential Solution Approaches Connected Identity, or other approaches using "UPDATE" have been suggested as a solution to conveying the user's priority level back to A. The UPDATE method described in RFC 3311 [RFC3311] is used to modify a session after the initial dialog has been established, but before the initial INVITE has been accepted (e.g., before the call is answered). In principle this could be used to convey the user's priority level. However the UPDATE can not be sent until after the dialog is established. In the example given, the dialog is established by the 183 which contains the SDP. So, by the time you could send an UPDATE, it is already too late, the reservation process has begun. Another theoretical possibility would be to modify the SDP contained in the 183. However, it is undesirable to modify a separate protocol (SDP) to satisfy a SIP requirement. Another would be to somehow modify the 183 to indicate that the UA should "wait for an UPDATE" before beginning the reservation/ allocation process. However, it is counterproductive, and not acceptable for this service, to introduce additional delay, and introduce additional error/failure conditions (what happens if the promised UPDATE doesn't arrive?) when the network is congested. The use of distinct logical ports has been suggested as a way to identify the priority of a response. While this may address some of the other proposed uses of RPH in Responses, it does not address this requirement, because the response use the same logical port as the request that triggered it. That will only work when Gunn Expires May 9th, 2008 [Page 6] Internet-Draft Requirements for SIP RPH in Responses November 2007 the UA sending the request already knows the priority level. 4. Acknowledgements Thanks to Keith Drage, Dean Willis, Brian Rosen, Jeroen van Bemmel, Henry Sinnreich, Joel Halpern, and John Elwell for useful discussion on the list. Thanks to James Polk for assistance in understanding the issues and presenting the requirement. Thanks to John Rosenburg for background discussions about the importance of resolving this issue. 5. IANA Considerations IANA considerations are discussed in [RPHresp]. 6. Security Considerations The Security considerations that apply to RFC 4412 [RFC4412] and those discussed in [RPHresp] apply here. There are legitimate security concerns about using RPH in responses to update the user's priority value. There is no way to challenge responses. In an open network, it is not easy to prevent "Joe End User" from arbitrarily adding an RPH with wps.0 (the highest priority level) to his responses. First of all, the requirement described here does not apply to the open Internet network. This requirement only applies to closely managed networks, for which the Service Provider has contracted to provide GETS service. Solutions, never the less, must also work in unmanaged networks Secondly, while there may be other reasons for wanting RPH in responses, the requirement describe here only applies to the UA that is going to be reserving resources, and only when the RPH is in a response coming from a pre-identified device (e.g., the GETS AS), probably via a secure connection. This UA can (and should) be configured to ignore the priority level conveyed in the RPH in other responses (coming from other sources, or not via a secure connection) in terms of updating the user's priority level. Other UAs, which do not reserve resources, can, and probably should, be configured to ignore the priority level in the RPH in a response coming from any source, over a secure or insecure connection. Due to the potential for fraud, SIP devices are advised to ignore RPH in responses unless they are certain that the response came from a trusted source from which, based on local policy, they are authorized to receive such information. The definition of trusted device is a matter of network policy. Gunn Expires May 9th, 2008 [Page 7] Internet-Draft Requirements for SIP RPH in Responses November 2007 7. References 7.1 Informative References [RFC3487] H. Schulzrinne, "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003. [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE Method," RFC 3311, September 2002. [RPHresp] J. Polk,"Allowing SIP Resource Priority Header in SIP Responses", draft-polk-sip-rph-in-responses-00 (work in Progress) , June 2007 7.2 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4411, Feb 2006 Author's Addresses Janet Gunn CSC 15000 Conference Center Drive Chantilly, VA 20151 USA Phone: +1-703-818-4725 Fax: +1-703-818-5947 Email: jgunn6@csc.com Tim Dwight Verizon 2400 North Glenville Drive Richardson, TX 75082 USA Phone: +1-972-729-5199 Fax : +1-972-729-5392 Email: timothy.dwight@verizon.com Gunn Expires May 9th, 2008 [Page 8] Internet-Draft Requirements for SIP RPH in Responses November 2007 Martin Dolly AT&T Labs Middletown Township, New Jersey 07748 USA Phone: +1-732-420-4574 Email: mdolly@att.com Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Gunn Expires May 9th, 2008 [Page 9] Internet-Draft Requirements for SIP RPH in Responses November 2007 Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Gunn Expires May 9th, 2008 [Page 10]