ECRIT Working Group M. Patel Internet-Draft Nortel Intended status: Standards Track September 12, 2008 Expires: March 16, 2009 SOS Uniform Resource Identifier (URI) parameter for marking of Session Initiation Protocol (SIP) requests related to emergency services draft-patel-ecrit-sos-parameter-00.txt 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 March 16, 2009. Abstract This memo describes requirements and protocol conventions for a new SIP (Session Initiation Protocol) URI parameter intended for marking SIP requests and responses related to emergency services. This proposal addresses issues that exist in the current 3rd Generation Partnership Project IP Multimedia Subsystem (IMS) Emergency services solution, but is not precluded from being used by other SIP-based emergency services solutions. It is not intended as a replacement for the service URN. Patel Expires March 16, 2009 [Page 1] Internet-Draft SOS URI Parameter for SIP Emergency September 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Requirements for additional emergency indication . . . . . 3 4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Proposed URI parameter . . . . . . . . . . . . . . . . . . 5 4.3. Proposed use of "sos" parameter . . . . . . . . . . . . . . 5 4.3.1. REGISTER request . . . . . . . . . . . . . . . . . . . 5 4.3.2. Requests for emergency call initiation . . . . . . . . 5 4.3.3. Call back from PSAP . . . . . . . . . . . . . . . . . . 6 4.3.4. SIP responses . . . . . . . . . . . . . . . . . . . . . 6 5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Patel Expires March 16, 2009 [Page 2] Internet-Draft SOS URI Parameter for SIP Emergency September 2008 1. Introduction This document describes a number of requirements addressing issues that exist in the 3GPP IMS emergency services solution, and a proposed solution for marking SIP requests related to emergency services. SIP-based emergency calls can be distinguished by the presence of the Service URN as defined in I-D-ietf-ecrit-phonebcp [I-D.ietf-ecrit-phonebcp] and RFC 5031 [RFC5031]. The emergency services solution in the 3GPP IP Multimedia Subsystem (IMS), as described in 3GPP TS 23.167 [3GPP.23.167]specifies that the User Equipment (UE) performs emergency registration prior to or during the initiation of an emergency call which can be useful in specific scenarios such as roaming. Marking of the emergency registration is a requirement described in this document that can not be fulfilled by the use of Service URN. A further requirement for proposing a new method for marking requests related to emergency calls is to identify the call back from a PSAP. Identification of the call back can aid in suppressing network-based and UA-based services. A further requirement for proposing a new method for marking responses is the case where a UE did not recognize the request as an emergency service request. Identification of the session as a emergency service session can aid in suppressing UA-based services or preventing transmission of a BYE request as required in some jurisdictions. The requirements for marking emergency call related messages are explored in this document and a new URI parameter is proposed to fulfill these requirements. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] 3. Requirements 3.1. General This section defines the requirements for introducing a new URI parameter to be used for marking emergency call related SIP requests. 3.2. Requirements for additional emergency indication [REQ 1] Indication in REGISTER request: 3GPP requires that a UE performs emergency registration under Patel Expires March 16, 2009 [Page 3] Internet-Draft SOS URI Parameter for SIP Emergency September 2008 specific circumstances, such as roaming, as described in 3GPP TS 23.167 [3GPP.23.167]. Marking the REGISTER request to indicate an emergency registration is necessary to inform the registrar that the contact address and AOR being registered is to be used for emergency calls, and roaming and barring restrictions should not be applied for the registered AOR. A call back from a PSAP would be routed to the registered contact address. Further requirements for the emergency registration are specified in 3GPP TS 23.167 [3GPP.23.167]. [REQ 2] Indication of IMS Emergency call origination: The Service URN in the Request URI is considered to be the primary method for marking the INVITE request for emergency call initiation. However, it is considered necessary to add another marking to the emergency request, particularly if the Service URN in the Request-URI is replaced by a network entity (in the case of 3GPP, such actions are performed at the Emergency Call Session Control Function (E-CSCF)). This can result in inappropriate handling at SIP entities prior to interworking the SIP request to ISUP at a PSTN gateway UA at the edge of the SIP network for routing towards the PSAP in the PSTN. [REQ 3] Indicating to the UA that an emergency call has been initiated: In the case that the UA is not emergency aware or no service URN for the requested emergency type is known, it will not populate the emergency INVITE with the service URN. Upon the network identifying the Request URI as an emergency number, the Request URI can be replaced with the Service URN. The UA is still unaware that an emergency call was initiated. A backwards indication to the UA from the network can ensure proper handling of the emergency call at the UA, i.e. no services such as call hold are applied to the emergency call. [REQ 4] Marking the PSAP call back: Identifying a call back from a PSAP can allow the network to apply special handling of the call back. Network-based services can be suppressed and the call can be routed to the contact address from which the emergency call was initiated. Additionally, special handling of the call back can occur at the UA. PhoneBCP [I-D.ietf-ecrit-phonebcp]suggests one possible method by which a call back can be identified, based upon the domain of the PSAP which answers the outgoing emergency call. This is possible if the PSAP is located in an IP network and is capable of communicating using SIP signaling. However, if the PSAP is located in the PSTN, attempting to identify the call back based upon the PSAP domain name Patel Expires March 16, 2009 [Page 4] Internet-Draft SOS URI Parameter for SIP Emergency September 2008 is not possible. 4. Proposed solution 4.1. General This section provides an overview of the proposed new URI parameter to be used for marking requests related to emergency services. 4.2. Proposed URI parameter A new URI parameter "sos" is defined in this document. The "sos" parameter is appended to an AOR consistent with RFC 3261 [RFC3261]. It is proposed that use of this URI parameter is restricted to the Contact header for request and responses related to an emergency call only. The "sos" URI parameter MUST not be considered as a replacement for the Service URN for emergency calls originated by a UA. 4.3. Proposed use of "sos" parameter 4.3.1. REGISTER request It is proposed that when the UA sends a REGISTER request for emergency registration, the "sos" URI parameter SHALL be appended to the AOR in the Contact header. This serves as an indication to the registrar that the request is for emergency registration. The "sos" URI parameter SHALL be present in the Contact header in the 200 (OK) response sent upon successful registration, thus indicating to the UA that this contact address will be included in the Contact header of an INVITE for emergency call initiation. 4.3.2. Requests for emergency call initiation When an emergency aware UA initiates an emergency call, the UA SHOULD include the "sos" URI parameter, appended to the contact address, in the Contact header in the INVITE request. An entity in the network that specifically handles emergency calls (in the case of 3GPP this is the E-CSCF), SHOULD append the "sos" URI parameter to the contact address in the Contact header in the event that the "sos" URI parameter is not present in the Contact header. This serves as an indication that this is an emergency call even in the case when the Service URN is removed by a network entity. Patel Expires March 16, 2009 [Page 5] Internet-Draft SOS URI Parameter for SIP Emergency September 2008 4.3.3. Call back from PSAP The call back from the PSAP SHOULD include the "sos" URI parameter in the Contact header of the INVITE request. If the PSAP is SIP capable, then the "sos" URI parameter SHOULD be included by the PSAP. If the PSAP is located in the PSTN, the PSTN gateway UA at the edge of the SIP network SHOULD append the "sos" parameter to the contact address in the Contact header of the generated INVITE request that is routed back to the emergency caller. This serves as an indication to network entities and to the UE to apply special call handling such as to suppress services that would normally be applied to a terminating call. 4.3.4. SIP responses The "sos" URI parameter MAY be included in provisional responses and 2xx responses to initial INVITE request for emergency call. This can serve as an indication to a UA that is not "emergency aware" that an emergency call has been initiated, thus allowing the UA to provide special handling of such a call. Suppressing call hold or multi- party call initiation during the emergency call to the PSAP are examples of special handling. It is RECOMMENDED that in such a response, the "sos" URI parameter is included in the Contact header, appended to contact address. 5. Formal syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 [RFC2234] uri-parameter = *(";"value) value = sos 6. IANA Considerations This specification defines one new SIP URI parameter, as per the registry created by RFC 3969 [RFC3969] Parameter Name: sos Predefined Values: none Reference: [RFCXXXX] [NOTE TO IANA: Please replace XXXX with the RFC number of this Patel Expires March 16, 2009 [Page 6] Internet-Draft SOS URI Parameter for SIP Emergency September 2008 specification.] 7. Security Considerations The "sos" URI parameter does not appear to raise any particular security issue. Misuse of the "sos" URI parameter, by including it in a request or response not related to an emergency call SHOULD be monitored by a network entity. 8. Acknowledgements The author would like to thank Keith Drage, Milo Orsic, John-Luc Bakker, Andrew Allen, Hiroshi Ishikawa, Sean Schneyer, Peter Leis, Georg Mayer, Marvin Bienn, Ricky Kaura, Steve Norreys, Laura Liess, AC Mahendran, Roozbeh Atarius, Ramachandran Subramanian and Sandeep Sharma for the discussions and contributions that lead to this work. 9. Normative References [I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", draft-ietf-ecrit-phonebcp-05 (work in progress), July 2008. [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. [3GPP.23.167] 3GPP, "IP Multimedia Subsystem (IMS) emergency sessions", 3GPP TS 23.167 7.9.0, June 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3969] Camarillo, G., "The Internet Assigned Number Authority Patel Expires March 16, 2009 [Page 7] Internet-Draft SOS URI Parameter for SIP Emergency September 2008 (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004. Author's Address Milan Patel Nortel Maidenhead Office Park, Westacott Way Maidenhead, Berkshire, UK Email: milanpa@nortel.com Patel Expires March 16, 2009 [Page 8] Internet-Draft SOS URI Parameter for SIP Emergency September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Patel Expires March 16, 2009 [Page 9]