Network Working Group H. Schulzrinne Internet-Draft Columbia U. Expires:
August 8, 2004 February 8, 2004April 26, 2006 October 23, 2005 Emergency Services URI for the Session Initiation Protocol draft-ietf-sipping-sos-00draft-ietf-sipping-sos-01 Status of this Memo This documentBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is an Internet-Draftaware have been or will be disclosed, and isany of which he or she becomes aware will be disclosed, in full conformanceaccordance with all provisions ofSection 106 of RFC2026.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. 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.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 August 8, 2004.April 26, 2006. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved.(2005). Abstract As part of an overall architecture for supporting emergency calling for the Session Initiation Protocol (SIP), this document defines universal emergency SIP URIs, sip:sos@domain and sips:sos@domain, that allows SIP user agents to contact the local emergency call center. It also defines conventions that increase the high probability of reaching the appropriate emergency call center. The document does not define any SIP protocol extensions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 43 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 53 4. Emergency URIs . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 SIP URIs for4 5. Identifying the Local Emergency Calls . . . . .Numbers . . . . . . . . . . 5 6. Request Handling . . 6 4.2 Tel URIs for Emergency Calls. . . . . . . . . . . . . . . . . 7 5. Request Handling. . . 6 7. Alternative Approaches Considered . . . . . . . . . . . . . 6 8. Media Feature Tag Registration: Service . . . . . . . 8 6. Identifying the Local Emergency Numbers. . . 7 9. IANA Considerations . . . . . . . . 9 7. Alternative Identifiers Considered. . . . . . . . . . . . 8 10. Security Considerations . . 10 8. IANA Considerations. . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . 11 9. Security Considerations. . . . . . . . . . . . . . . . . 9 12. References . . 12 10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 139 12.1 Normative References . . . . . . . . . . . . . . . . . . . . . 149 12.2 Informative References . . . . . . . . . . . . . . . . . . . . 1510 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 1510 Intellectual Property and Copyright Statements . . . . . . . . 1611 1. Introduction Using the public switched telephone network (PSTN), emergency help can often be summoned at a designated, widely known number, regardless of where the telephone was purchased. However, this number differs between localities, even though it is often the same for a country or continent-size region (such as many countries in the European Union or North America). For end systems based on the Session Initiation Protocol (SIP) [RFC3261], it is desirable to have a universal identifier, independent of location, to simplify the user experience and to allow the device to perform appropriate processing. Here, we define a common user identifier, "sos", as the contact mechanism for emergency assistance. This identifier is meant to be used in addition to any local emergency numbers. This document specifies only a small part of a comprehensive set of recommendations for operating emergency services. The overall architecture is described in [schulzrinne-sipping-emergency-arch].[I-D.schulzrinne-sipping-emergency- arch]. That document describes, for example, how a device that identifies a call as an emergency call can route it to the appropriate emergency call center (ECC). This document does not introduce any new SIP header fields, request methods, status codes, message bodies, or events. User agents unaware of the recommendations in this draft can place emergency calls, but may not be able to provide the same user interface functionality. The document suggests behavior for proxy servers, in particular outbound proxy servers. The solution described here is not as general as the alternative approach, service URNs [I-D.schulzrinne-sipping-service], but requires no changes to end systems or proxies. 2. Terminology In this document, the key words "MUST", "MUSTNOT","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. Requirements o It should be possible for devices to provide user interfaces that can directly cause an emergency call, without the user having to "dial" or type a specific address. o Even as each country is likely to operate their emergency calling infrastructure differently, SIP devices should be able to reach emergency help and, if possible, be located in any country. o While traveling, users mustshould be able to use their familiar "home" emergency identifier.number. Users shouldmust also be able to dial the local emergency number in the country they are visiting. o Any mechanism must be deployable incrementally and work even if not all SIP entities support emergency calling. User agents conforming to the SIP specification [RFC3261], but unaware of this document, must be able to place emergency calls, possibly with restricted functionality. o Given incremental deployment, emergency call functionality should be testable by the user without causing an emergency response. o Emergency calling mechanisms must support existing emergency call centers based on circuit-switched technology as well as future ECC that are SIP-capable. 4. Emergency URIs AHaving a single, global (set of) identifiersidentifier for emergency services is highly desirable, as it allows end system and network devices to be built that recognize such services and can act appropriately. Such actions may include restricting the functionality of the end system, providing special features, overriding user service constraints or routing session setup messages. SIP user agents (UAs) that determine that a dialog or transaction relates to an emergency MUST use an emergency call identifier in the Request-URI. The Request-URI MUST be eitheran emergency SIP URI defined in Section Section 4.1 or an emergency tel URI defined in Section Section 4.2. 4.1 SIP URIs for Emergency Callsbelow as the Request-URI and "To" header field. It is RECOMMENDED that SIP-based [RFC3261] end systems and proxy servers support a uniform emergency call identifier, namely the SIP and SIPS URIs with the reserved user name "sos" within any domain, e.g., sip:email@example.com sips:firstname.lastname@example.org The reserved name is case-insensitive. The host part of the emergency URI SHOULD be the host portion of the address-of-record of the caller. The "sips" form SHOULD be used to ensure integrity and confidentiality.confidentiality; the "sip" form MAY be used if a "sips" call fails with status code 416 (Unsupported URI Scheme). All SIP requests with URIs of this form are assumed to be emergency calls. (TheThe domain-of-record was chosen since a SIP user agent may not be able to determine the local domain it is visiting. This also allows each user to test this facility, as the user can ensure that such services are operational in his home domain. An outbound proxy in the visited domain can handle the call if it believes to be in a position to provide appropriate emergency services.)services. In addition, we reserve user addresses beginning with the string "sos." forsome cases, end users or, more likely, emergency service routing proxies may want to request specific emergency services: sos.fire fire brigade sos.rescue ambulance (rescue) sos.marine marine guard sos.police police (law enforcement) sos.mountain mountain rescueservices. We support this feature by leveraging the caller preferences [RFC3841] extension and define a new media feature tag, service, in Section 8. The sub-addresses are also case-insensitive. Additional subaddresses can be registered with IANA (Section Section 8). (In some areas, these emergency services use different numbers.) The SIP URI user name "sos" and user names starting with "sos." MUSTNOTSIP URI user name "sos" MUST NOT be assigned to any regular user. 4.2 Tel URIs for Emergency Calls User agents SHOULD determine the local emergency numbers, either by consulting their manual configuration for devices that do not move across national borders, by DHCP, DNS NAPTR or some other configuration mechanism [schulzrinne-sipping-emergency-arch]. If a user agent has no knowledge of local emergency numbers, it MUST also recognize the digit strings 000, 08, 112, 110, 118, 119, 911 and 999 as emergency numbers. (SIP user agents, such as Ethernet deskphones, that are unlikely to move frequently across national borders can easily implement a local dialing plan that recognizes local emergency numbers. Mobile devices, including PDAs and laptops, may not have a reliable way of determining their current location. Using automatic configuration avoids collisions with extensions that equal one of the eight numbers above. If a local network does not have an outbound proxy server, local dial plans also do not apply, so the problem of number collision does not arise. Collisions with non-emergency service numbers are still possible, albeit less likely. For example, 118 is used for directory assistance in Finland.) If the user dials any of these digit strings, the UAC SHOULD generate a request with the "sos" URI described in Section Section 4.1 unless it has discovered a local outbound proxy. In that case, a UAC MAY use a "tel" URI [RFC2806] without 'phone-context', such as tel:911 tel:112Outbound proxy servers MUST be configurable to recognize additional localemergency numbers valid in their geographic service area in "tel" URIs. There are about 60 service numbers for emergency services in the world; including them all is not practical, as that would interfere with existing local two, three and four-digit dialing plans. 5. Request Handling Once identified,Identifying the Local Emergency Numbers There are many ways that a user agent can either determineconfigure emergency numbers for use in analyzing calls made with telephony-type user input. Such numbers become part of the appropriate ECC locallydevice dialplan. Mechanisms include configuration tokens such as SIM cards in mobile devices, network- specific solutions (e.g., for 3GPP networks) or delegate this taskprotocol-based solutions. Protocol-based solutions, using XCAP and DNS, are discussed in [I-D.schulzrinne-sipping-emergency-arch]. Given the different trade-offs in user agent implementation complexity and deployment difficulty, it appears likely that multiple such mechanisms will co-exist. Regardless of the mechanism chosen and whether any of the configuration mechanisms succeed, the digit strings "112" and "911" MUST always be recognized as emergency numbers. User agents SHOULD allow users and/or administrators to configure additional emergency numbers. User agents SHOULD attempt to ascertain the set of emergency numbers that are valid in the geographic region that the user agent is currently located in. Two such mechanisms included XCAP and DNS, discussed in [I-D.schulzrinne-sipping-emergency-arch]. If and only if an outbound proxy. Detailsend system is unable to determine the emergency numbers valid in its current geographical location, it SHOULD recognize any of the number 000, 08, 110, 999, 118 and 119 as emergency numbers. Since these numbers are also used for non- emergency purposes, their automatic transformation incurs the risk of accidentally dialing an emergency number when, for example, directory assistance was desired. To minimize such mistakes, end systems SHOULD alert users that they are dialing a recognized emergency number. This behavior corresponds to the guidelines in [schulzrinne-sipping-emergency-arch].3GPP TS 22.101. Since general SIP end points cannot be assumed to have SIMs or USIMs, this document uses the default list (000, 08, 110, 999, 118 and 119) only if no other configuration information about geographically local emergency numbers is available. 6. Request Handling Outbound proxy servers MUST recognize all localSHOULD check whether a tel URIs or a SIP URIs containing a dial string represents an emergency numbers as well asnumber within its geographic service area, but only if they can be reasonably certain that the call originated from within that area, e.g., if the call contained location information or the network is known to only be reachable from a restricted geographic area. Typically, these service areas encompass whole countries since many countries now have nationwide emergency numbers. Once they recognize an emergency number, they translate the tel URIs enumerated in Section Section 4.2.Request-URI to an "sos" URI as described above. The proxy MAY use any additional information contained in the call request, suchrequest to recognize additional numbers as emergency numbers. Such information includes the Mobile Country Code and the Mobile Network Code for 3GPP devices,devices or country information in location information available about the call, The [I-D.schulzrinne-sipping-emergency- arch] document describes a possible DNS-based mechanism to recognize additional numbers asobtain country-specific emergency numbers. It is RECOMMENDED that gateway SIP MESSAGE requests are directed to a TTY-for-the-deaf translator or a short-message service (SMS) if the emergency call center cannot handle SIP instant messaging. OPTIONS requests to the user "sos" and the "sos.*" addresses (sos.fire, etc.) can be used to test if the "sos" addresses are valid. As in standard SIP, a 200 (OK) response indicates that the address was recognized and a 404 (Not found) that it was not. Such request cause no further action. It is RECOMMENDED that user agents periodically automatically check for the availability of the "sos" identifier and alert the user if the check fails. The period of such automated checks SHOULDNOT be less than once per day and MUST be randomly placed over the testing interval. 6. Identifying the Local Emergency Numbers There are many ways that a user agent can configure emergency numbers for use in analyzing calls made with telephony-type user input. Such numbers become part of the device dialplan. Mechanisms include configuration tokens such as SIM cards in mobile devices, network-specific solutions (e.g., for 3GPP networks) or protocol-based solutions. Protocol-based solutions, using XCAP and DNS, are discussed in [schulzrinne-sipping-emergency-arch.] Given the different trade-offs in user agent implementation complexity and deployment difficulty, it appears likely that multiple such mechanisms will co-exist.7. Alternative IdentifiersApproaches Considered The "sos" SIP URI reserved user name proposed here follows the convention of RFC 2142 [RFC2142] and the "postmaster" convention documented in RFC 2822 [RFC2822]. One drawback is that it may conflict with locally assigned addresses of the form "sos@somewhere"."sos@domain". There are a number of possible alternatives, each with their own set of advantages and problems: tel:sos This solution avoids name conflicts, but is not a valid "tel" URI. It also only works ifonly works if every outbound proxy knows how to route requests to a proxy that can reach emergency services. The SIP URI proposed here only requires a user's home domain to be appropriately configured. urn:service:sos A related document [I-D.schulzrinne-sipping-service] defines a URN for identifying services, such as emergency calling. This solution fits most cleanly into the overall URI architecture and avoids dependencies on the home domain, but, like the tel URI solution above, also requires that every outbound proxy knows how tocan resolve this URN and can route requestscalls accordingly. Alternatively, the end system has to be configured with a proxy that can reach emergency services. The SIP URI proposed here only requires a user'ssuitable URN-resolving proxy, e.g., in its home domain to be appropriately configured.domain. URI parameter: One could create a special URI, such as "aor-domain;user=sos"."aor- domain;user=sos". This avoids the name conflict problem, but requires mechanism-aware user agents that are capable of emitting this special URI. Special domain: A special domain, such as "sip:email@example.com" could be used to identify emergency calls. This has similar properties as the "tel:sos" URI, except that it is indeed a valid URI. 8. Media Feature Tag Registration: Service This specification defines an additional media feature tag, extending the SIP tree entries described in [RFC3840] and following the registration process in Section 12.1 of that document. This section serves as the IANA registration for the service feature tags, which are made into the SIP media feature tag tree. This facility is not meant to encourage end users to select emergency services where a uniform ECC for all such services exist. Rather, these identifiers reflect current practice in jurisdictions that already have different numbers for the different emergency services. For example, in Germany, ambulance and fire use 112, while police uses 110. We expect that users will rarely invoke specific emergency services directly. Rather, they might be generated by outbound proxy servers translating dial strings or be generated when pressing icon-bearing speed dial buttons. Using feature tags has the advantage that they are not affected by entities that translate URIs, e.g., to route emergency calls to a specific ECC. The service types for this feature tag are case-insensitive. Additional service types can be registered with IANA (Section Section 9). Media feature tag name: sip.emergency-service ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: Each feature tag indicates the type of communication service requested. Values appropriate for use with this feature tag: Token with an equality relationship. Initial values include a number of emergency services: sos: general emergency service sos.fire: fire brigade sos.marine: marine guard sos.mountain: mountain rescue sos.police: police (law enforcement) sos.rescue: ambulance, emergency medical service sos.test: testing, not a real emergency call The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a user agent providing a particular type of communication service. Examples of typical use: Allowing an emergency service proxy to select the desired emergency service, such as police or ambulance. Related standards or documents: RFC3840. Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC3840. 9. IANA Considerations Subaddresses of the "sos" address are registered with IANA This specification establishes the "sos" subaddres sub-registry under http://www.iana.org/assignments/sip-parameters. Subaddresses are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC must include the following information, which appears in the IANA registry along with the RFC number of the publication. o Name of the subaddress. The name MAY be of any length, but SHOULD be no more than twenty characters long. The name MUST consist of NVT alphanumeric characters only and is case-insensitive. o Descriptive text that describes the emergency service. 9.10. Security Considerations The SIP specification [RFC3261] details security considerations that apply to emergency calls as well. Security for emergency calls has conflicting goals, namely to make it as easy and reliable as possible to reach emergency services, while discouraging and possibly tracing prank calls. It appears unlikely that classical authentication mechanisms can be required by emergency call centers, but SIP proxy servers may be able to add identifying information. Given the sensitive nature of many emergency calls, it is highly desirable to use the "sips" URI to ensure transport-level confidentiality and integrity. However, this may cause the call to fail in some environments. Allowing the user agent to clearly and unambiguously identify emergency calls makes it possible for the user agent to make appropriate policy decisions. For example, a user agent policy may reveal a different amount of information to the callee when making an emergency call. Local laws may affect what information network servers or service providers may be allowed or be required to release to emergency call centers. They may also base their decision on the user-declared destination of the call. Recognizing only "sos" in the user's home domain, i.e., the domain of the user's AOR, prevents spoofing where a link points to a fake emergency calling number and leads the user to, for example, include location information in the request. Additional security considerations related to call routing, destination authentication and other issues are detailed in [schulzrinne-sipping-emergency-arch]. 10.[I-D.schulzrinne-sipping-emergency-arch]. 11. Acknowledgements Andrew Allen, Keith Drage, Cullen Jennings, Mike Pierce, James Polk, Brian Rosen and John Schnizlein contributed helpful comments. 12. References 12.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M.M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002. [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. 12.2 Informative References [I-D.schulzrinne-sipping-emergency-arch] Schulzrinne, H. and B. Rosen, "Emergency Services for Internet Telephony Systems", draft-schulzrinne-sipping-emergency-arch-02 (work in progress), October 2004. [I-D.schulzrinne-sipping-service] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", draft-schulzrinne-sipping-service-00 (work in progress), July 2005. [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Author's Address Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7042 EMail:7004 Email: firstname.lastname@example.org URI: http://www.cs.columbia.edu Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual propertyIntellectual 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; neithernor does it represent that it has made any independent effort to identify any such rights. Information on the IETF'sprocedures with respect to rights in standards-track and standards-related documentationRFC documents can be found in BCP-11.BCP 78 and BCP 79. Copies of claims of rightsIPR disclosures made available for publicationto 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 implementorsimplementers or users of this specification can be obtained from the IETF Secretariat.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 whichthat may cover technology that may be required to practiceimplement this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purposeat email@example.com. Disclaimer of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.Validity This document and the information contained herein isare 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 DISCLAIMSDISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.