Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. Category: Informational July 2004 Concerns with URI-based call routing for emergency services draft-hardie-emergency-call-routing-00.txt 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 3668. 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 in January 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document discusses recent proposals that would introduce a common URI or set of URIs to identify and route calls intended to reach emergency services. 1. Introduction. In a number of areas the public switched telephone network (PSTN) has been configured to recognize a short, easily memorized number as a call for emergency services. There may be a single such number which is undifferentiated as to service, or there may be multiple numbers associated with distinct emergency services. The number assigned to this purpose varies according to region, though the regions for which each is valid tend to be large and aligned with a major political boundary. (ES-URI) proposes the introduction of a set of global identifiers for emergency services which would augment and possibly supersede these emergency service numbers. The problem inherent in this approach is setting out the appropriate context for the resolution of the URI. This document examines some aspects of that problem. 2. URI context and resolution. (URI) sets out that: URIs have a global scope and must be interpreted consistently regardless of context, though the result of that interpretation may be in relation to the end-user's context. For example, "http:// localhost/" has the same interpretation for every user of that reference, even though the network interface corresponding to "localhost" may be different for each end-user: interpretation is independent of access. However, an action made on the basis of that reference will take place in relation to the end-user's context, which implies that an action intended to refer to a single, globally unique thing must use a URI that distinguishes that resource from all other things. URIs that identify in relation to the end-user's local context should only be used when the context itself is a defining aspect of the resource, such as when an on-line Linux manual refers to a file on the end-user's filesystem (e.g., "file:///etc/hosts"). Clearly, a call for emergency services is not intended to refer to a single, globally unique resource. Nor is it, however, something local to an individual user's context. It relates to an emergency service context which depends on a broad, regional configuration of service contact methods and a geographically constrained context of service delivery. The problem of associating that emergency service context, with its irregular geographic boundaries and variability in breadth, to a single set of URIs is formidable. (ES-URI) proposes the use of a convention, in which a well-known string is used to construct a URI which is neither as local as file:///etc/hosts nor as global as http://www.example.com/file.txt. This string concatenates "sos" or a substring-augmented form like "sos.fire" with the domain of record for the caller to create a URI of the form "sip:sos@example.com". (ES-URI) provides the following rational for this choice: The 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. The difficulty here is that there is no existing relationship between the domain of record and the emergency service context. In addition, maintaining a relationship between the two when the calling device is mobile is quite challenging. 3. Call routing. In order for the method proposed in (ES-URI) to work, some network element must examine the SIP request URI and associate the request with an emergency service context appropriate for the user at her or his current location. That network element must then either directly or indirectly route the call to the Emergency Call Center (ECC) appropriate to that context. Without more granular geographic information, the location used must be assumed from network topology; given the prevalence of tunnels in modern IP networks, this can be very difficult and can produce incorrect results. There is no mechanism of which this author is aware for globally associating the data needed for geographically based resolution with domains of record; those devices which are capable of mapping a location to an ECC do so based on local databases whose form, scope, and granularity are currently all variable. (DNS-SOS) proposes using the DNS as a publication mechanism for this data, but notes that once published, data of local interest would have to be computed and locally stored to be usable by this system. Discovering what data is of local interest is an unsolved problem even under that proposal, and the DNS storage of location data is unrelated to the use of domains of record. While it is theoretically possible to maintain a local copy of a global mapping table of every possible ECC to its service area, this author believes that this will remain theoretical. Further, maintaining even incomplete mapping tables at every SIP proxy is clearly onerous to the point of impossibility. It may be possible to maintain them at specially designated route servers, to which SIP servers can forward requests for emergency service for onward call routing. SIP servers would, in such a case, need to be configured with the appropriate route server, which would actually perform the mapping function and route the call. 4) An alternate role for configuration. Rather than using a constructed URI which must be recognized and interpreted by a network element which is already performing other functions, one alternative would be to automatically configure devices with an appropriate URI. In some situations, this URI might be local PSTN emergency number encoded as a tel: URI. (ES-URI) describes the use of tel: URIs in emergency calls and notes that automatic configuration may be required to inform mobile devices of the local emergency service number. In other situations, this might be an emergency services call routing server, as is mentioned in section 3 above. Note that in this case, though, the intention would be to eliminate the initial connection and examination by the usual SIP proxy, and have the device talk directly to the emergency service call routing server, which would act as a SIP proxy for the emergency call. This configuration would, in essence, set the service context, thus making the URI resolution context clear and unambiguous. Even if the "sos" convention were retained for the left hand side of the URI (e.g. sos@local.call.routing.server.example.net), the need for intermediate elements to identify a device with appropriate local mapping tables is eliminated, and much of the complexity of the universal URI proposal reduced. 4.1) Barriers to the use of configuration. The use of configuration to set a service context would require that the common means of configuring devices would need to be extended to carry this data. At a minimum, this would require both DHCP (DHCP) and DHCPv6 (DHCPv6) to set aside appropriate code points, and it might require other systems (such as over-the-air configuration) to do so as well. Once the protocol mechanisms were in place, devices handling node configuration would have to be configured with this data and the data kept up to date. Route servers capable of both associating the location of a caller with the appropriate ECC and of handling the SIP call flows would have to be deployed. In cases where a mobile device receives no configuration data from a visited network, the home network would also have to maintain mapping tables sufficient for associating the device to an ECC. 4.2) Advantages to the use of configuration. The use of configuration for this level of call routing eliminates one network element from the emergency call flow, which should speed the call and eliminate a risk that other, non-emergency traffic may hinder call completion. It also supports a relatively flexible set of route server deployments; a network may choose to provide a very complete set of mappings in one large-scale route server farm or may distribute the data around their network. Depending on the format of the configuration record, extensibility to non-SIP flows might be possible in the future. For non-mobile devices, the configuration of this data should be relatively static and easily maintained over long periods of time. 5) Presentation layer vs. call routing. One of the chief advantages of national or regional schemes for emergency service numbers is that the numbers selected are short, easily remembered, and easily dialed. These are essentially presentation layer characteristics, though, and they mask the complexity of effort taken within the PSTN to route the call to the appropriate ECC. Part of the (ES-URI) proposal is clearly aimed at the same presentation layer characteristics--having a short, mnemonic string to associate with emergency services. There is no need, however, for this presentation layer string to constrain the development of the protocol elements used to support the underlying call routing. As a thought exercise, imagine every phone having an "emergency" button--the UI in this is clear, unambiguous, and easy for the end user to understand. What happens when that button is pressed is not constrained by the label on the button, though, and a similar independence between user interface and call routing can be achieved in this case. Just as (ES-URI) notes that a device should recognize both local dialing plan and "home region" dialing plan emergency service numbers as calls for help, a presentation layer convention can be set without it affecting the underlying routing. 6. Security Considerations. Any system used to deliver emergency services must be robust, timely and protected against malicious interference. The use of automatic configuration methods to derive some element of the emergency call routing will inherent any weaknesses of the configuration methods; in some instances, those might be severe. There is also risk that out of data information may cause emergency call information to be routed to route servers which are no longer available. A fallback mechanism (probably to route such calls to the usual SIP proxy, which would then use its local configuration) is probably necessary. If an attacker can spoof or DoS the emergency call routing center, calls will not go through. 7. IANA Considerations. This document contains no instructions to IANA. 8. Normative References Schulzrinne, H. "Emergency Services URI for the Session Initiation Protocol" draft-ietf-sipping-sos-00.txt (ES-URI) Berners-Lee, T., Fielding, R., Masinter, L. "Uniform Resource Identifier (URI): Generic Syntax" draft-fielding-uri-rfc2396bis-05.txt (URI) Rosen, B. "Emergency Call Information in the Domain Name System" draft-rosen-dns-sos-00.txt (DNS-SOS) 9. Non-Normative References Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, March 1997. (DHCP) Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. (DHCPv6) 10. Acknowledgements The author would like to acknowledge discussions with Randy Gellens, AC Mahendran, and Raymond Hsu. 11. Author's Address Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Campbell, CA U.S.A. EMail: hardie@qualcomm.com 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 purpose 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 assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.