Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

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 August 8, 2004.

Copyright Notice

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

Summoning emergency help is a core feature of telephone networks. This document describes how the Session Initiation Protocol (SIP) can be used to provide advanced emergency services for voice-over-IP (VoIP). The architecture employs standard SIP features and requires no new protocol mechanisms. DNS is used to map civil and geospatial locations to the appropriate emergency call center.

Table of Contents

1.  Requirements notation
2.  Overview
3.  Terminology
4.  Identifying an Emergency Call
5.  Location and Its Role in an Emergency Call
5.1  Introduction
5.2  Types of Location Information
5.3  Sources of Location Information
5.4  Using Location Information for Call Routing
6.  Routing the Call to the ECC
6.1  Routing the First Request
6.2  Updating Location Information
7.  Preventing Call Misdirection
8.  Requirements for SIP Proxy Servers
9.  Configuration
10.  Requirements for SIP User Agents
10.1  Emergency call taker
10.2  Calling users
11.  Example Call Flows
12.  Security Considerations
12.1  ECC Impersonation
12.2  Call Content Integrity
§  Normative References
§  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1. Requirements notation

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

2. Overview

Summoning police, the fire department or an ambulance in emergencies is one of the fundamental and most-valued functions of the telephone. As telephone functionality moves from circuit-switched telephony to Internet telephony, its users rightfully expect that this core functionality works at least as well as for the older technology. However, many of the technical advantages of Internet telephony require re-thinking of the traditional emergency calling architecture. This challenge also offers an opportunity to improve the working of emergency calling technology, while potentially lowering its cost and complexity.

It is beyond the scope of this document to enumerate and discuss all the differences between traditional (PSTN) and Internet telephony, but the core differences can be summarized as separation of signaling and media data, the emergence of application-independent carriers, and the potential mobility of all end systems, including landline systems and not just those using radio access technology.

This document focuses on how ECCs can natively handle Internet telephony emergency calls, rather than Describing how circuit-switched ECCs can handle VoIP calls. However, in many cases, ECCs making the transition from circuit-switched interfaces to packet-switched interfaces may be able to use some of the mechanisms described here, in combination with gateways that translate packet-switched calls into legacy interfaces, e.g., to continue to be able to use existing call taker equipment.

Existing emergency call systems are organized nationally; there are currently no international standards. However, Internet telephony does not respect national boundaries, and thus an international standard is required.

Furthermore, VoIP endpoints can be connected through tunneling mechanisms such as virtual private networks (VPNs). This significantly complicates emergency calling, because the location of the caller and the first element that routes emergency calls can be on different continents, with different conventions and processes for handling of emergency calls. The IETF has historically refused to create national variants of its standards. Thus, this document attempts to take into account best practices that have evolved for circuit switched ECCs, but makes no assumptions on particular operating practices currently in use, numbering schemes or organizational structures.

This document assumes that ECC interface is using the Session Initation Protocol (SIP). Use of a single protocol greatly simplifies the design and operation of the emergency calling infrastructure. Only peer-to-peer protocols such as H.323, ISUP and SIP are suitable for inter-domain communications, ruling out master-slave protocols such as MGCP or H.248/Megaco. The latter protocols can natually be used by the enterprise or carrier placing the call, but any such call would reach the ECC through a media gateway controller, similar to how interdomain VoIP calls would be placed. Other signaling protocols may also use protocol translation to communicate with a SIP-enabled ECC.

Existing emergency services rely exclusively on voice, and conventional TDD text media streams. However, more choices of media offer additional ways to communicate, evaluate and assist callers and call takers to handle emergency calls. For example, instant messaging and video could improve the ability to evaluate the situation and provide appropriate instruction prior to arrival of emergency crews. Thus, the architecture described here supports the creation of sessions of any media type, negotiated between the caller and ECC using existing SIP protocol mechanisms [RFC3264].

While traditionally, emergency services have been summoned by voice calls only, this document does not rule out the use of additional media during an emergency call, both to support callers with disabilities (e.g., through interactive text or video communications) and to provide additional information to the call taker and caller. For example, video from the caller to the ECC may allow the call taker to better assess the emergency situation; a video session from the ECC to the emergency caller may allow the call taker to provide instructions for first aid.

The choice of media and encodings is negotiated on a call-by-call basis using standard SIP mechanisms [RFC3265]. To ensure that at least one common means of communications, this document recommends certain minimal capabilities in Section Section 10 that call taker user agents and ECC-operated proxies should possess.

This document does not prescribe the detailed network architecture for ECCs or collection of ECCs. For example, it does not describe where ECCs may place firewalls or how many SIP proxies they should use.

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.

3. Terminology

(emergency) call taker

Person that answers an emergency call; typically located in an emergency call center.

ECC (emergency call center)

Call center that receives emergency calls and dispatches polic, fire and rescue services. An ECC serves a limited geographic area. In the United States, PSAPs are ECCs.

ESRP (emergency service routing proxy)

SIP proxy that routes incoming emergency calls to the appropriate ECC.

PSAP (public safety answering point)

The United States and Canadian term for ECC.

SIP proxy

see [RFC3261]

SIP UA (user agent)

see [RFC3261]

4. Identifying an Emergency Call

Using the 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 region (such as many countries in the European Union). For end systems based on the Session Initiation Protocol (SIP), it is desirable to have a universal identifier, independent of location, to simplify the user experience, allow the automated inclusion of location information and to allow the device and other entities in the call path to perform appropriate processing.

As part of the overall emergency calling architecture, we define a common user identifier, "sos" and "sos" with an emergency service designation, as the contact mechanism for emergency assistance. In addition, two tel URIs, tel:112 and tel:911, are permissible as emergency call identifiers issued by a user agent. We refer to this URI as the "emergency calling URI". The calling user agent sets both the "To" header and the request-URI to the emergency URI, so that entities after the ESRP can still readily determine that this is an emergency call. Details are described in [draft-schulzrinne-sipping-sos].

In addition, user agents SHOULD detect emergency calls following local emergency calling conventions. There are two local conventions, namely those local to the user's SIP domain, e.g., a user's network at work, and those at the caller's current geographic location, e.g., while traveling. The former can be obtained using SIP configuration mechanisms (Section Section 9). Obtaining geographically local emergency numbers is more difficult, particularly if the outbound proxy or DHCP server may be in a different country than the caller. There are several, complementary solutions. First, DHCP can be extended with a pointer to a local SIP configuration, including the dial plan specifying emergency numbers. In addition, we define a new DNS resource record that identifies the country-specific emergency number.

Location information can be provided by the user agent or a proxy. If the user agent provides this information, the user agent needs to be able to determine that a call is indeed an emergency call as it is unlikely to include location information in each call.

5. Location and Its Role in an Emergency Call

5.1 Introduction

Caller location plays a central role in routing emergency calls. For practical reasons, each ECC generally handles only calls for a certain geographic area. Other calls that reach it by accident must be manually re-routed (transferred) to the appropriate ECC, increasing call handling delay and the chance for errors. The area covered by each ECC differs by jurisdiction, where some countries have only a small number of ECCs, while others devolve ECC responsibilities down to the community level.

In most cases, ECCs cover at least a city or town, but there are some areas where ECC coverage areas follow old telephone rate center boundaries and may straddle more than one city.

5.2 Types of Location Information

There are four primary types of location information: civil, postal, geospatial, and cellular cell tower and sector.

Civil:

Civil information describes the location of a person or object by a floor and street address that corresponds to a building or other structure.

Postal:

Postal addresses are similar to civil addresses, but the may contain post office boxes or street addresses that do not correspond to an actual building. Postal addresses are generally unsuitable for emergency call routing, but may be the only address available to a service provider, derived from billing records.

Geospatial:

Geospatial addresses contain longitude, latitude and altitude information.

Cell tower/sector:

Cell tower and sectors identify the cell tower and the antenna sector that the mobile device is currently using. (Cell/sector information could also be transmitted as an irregularly shaped polygon of geospatial coordinates reflecting the likely geospatial location of the mobile device, but since these boundaries are not sharp, transmitting the raw information is probaby preferable.)

5.3 Sources of Location Information

There are two principal contributors of location information. In some cases, the calling end system knows its current civil and/or geospatial location, in others the outbound proxy or other network entity. In some cases, both such entities may have location information, possibly partially contradictory. This document provides no recommendation on how to reconcile conflicting location information or which one is to be used by routing elements. Conflicting location information is particularly harmful if it points to multiple distinct ECCs. If there is no other basis for choice, the ESRP SHOULD determine the appropriate ECC for all location objects and, if there is a conflict, route based on the most accurate one.

To facilitate such policy decisions, location information SHOULD contain information about the source of data, such as GPS, manually entered or based on subscriber address information. In addition, the author of the location information SHOULD be included. TBD: need to add this to (e.g.) PIDF-LO!

End systems and network elements can derive location information from a variety of sources. It is not the goal of this document to exhaustively enumerate them, but we provide a few common examples below:

GPS:

Global Positioning System (GPS) information is generally only available where there is a clear view of a large swath of the sky. It is accurate to tens of feet.

Wireless triangulation:

Either cell towers or 802.11 access points triangulate based on signal strength or time of arrival.

DHCP:

The device obtains location information provided by its DHCP server, derived through one of the other methods enumerated here.

Location beacons:

A short range wireless beacon, e.g., using BlueTooth or infrared, announces its location to mobile devices in the vicinity.

Subscriber information:

A carrier has address information reflecting the service location for its subscribers.

Manual configuration:

A user manually enters civil or geospatial information into a mobile or stationary device.

TBD: there is a need to indicate which location information has been used to avoid possible routing loops, where two proxies pick different location information from the call request, each pointing to the other one.

5.4 Using Location Information for Call Routing

Note that emergency calls may not be routed to the geographically closest ECC, but rather to the most jurisdictionally appropriate one, which may well be further away.

Location information may not be available at call setup time. For example, if a GPS-enabled cell phone is turned on and then immediately places an emergency call, it can take an additional 20-25 seconds before the cell phone acquires a GPS fix and its location. Thus, while it is necessary and expedient to include caller location information in the call setup message, this is not sufficient in all circumstances. In some cases, the initial call setup will proceed based on, for example, cell and sector information and then add location information during the call, rather than delaying the initial call setup by an unacceptable amount of time.

In addition, the location of a mobile caller, e.g., in a vehicle or aircraft, can change significantly during the emergency call.

6. Routing the Call to the ECC

6.1 Routing the First Request

Emergency calls are routed based on location information contained within the call setup request (INVITE). If there is no or imprecise (e.g., cell tower/sector) information, an on-going emergency call may also be transferred to another ECC based on location information.

Each proxy receiving an emergency call request, identified as described in Section Section 4, attempts to route the call to the most appropriate ECC. Similarly, a user agent can also directly route emergency calls if it has location information, either obtained locally or from a redirect response provided by the outbound proxy. There are three types of routing actions: default routing, DNS-based routing and local routing.

ESRPs and user agents using default routing forward all emergency call requests to one designated ESRP, regardless of the location of the caller.

ESRPs and user agents using DNS-based routing employ the mechanism in [-dns-] to route calls to another ESRP that is qualified to handle the emergency call. Thus, DNS acts here as a location service for the proxy.

Finally, an ESRP MAY use a local database to perform location-based call routing. The details of such a database are beyond the scope of this document.

If an emergency call INVITE request does not contain location information and no other location hints (such as subscriber identity) are available, the first ESRP in the call path SHOULD route it to an ECC that is geographically local to that proxy, since no other call routing can be performed.

Jurisdictions organizing ECCs may choose to implement multiple levels of routing based on location. For example, a state or province might deploy an ESRP in front of a collection of ECCs. The information available to a VoIP carrier or enterprise ESRP may be coarse, so that any location within the state or province gets routed to the state/province ESRP, with that ESRP doing the detailed routing to a specific ECC. Thus, each ESRP MUST inspect the INVITE request and determine if more precise request routing is called for.

6.2 Updating Location Information

Location information is needed both for routing the initial INVITE message in a call as well as possibly later during a call since location information may change or only become available later, after the call has reached an ECC.

This document considers three mechanisms for conveying updated location during a call: UPDATE or re-INVITE, INFO or dialog events.

In the first approach, the caller sends UDPATE [RFC3311], prior to completion of the initial INVITE transaction, or re-INVITE requests to the destination. Care must be taken that these requests are routed to the same destination as the original call-initiating request. This is unlikely to be a problem for a re-INVITE if the Contact header field in the 200 OK indicates the ECC address.

In the second approach, the ECC subscribes to the location of the caller, using the SIP event mechanism and PIDF-LO [I-D.ietf-geopriv-pidf-lo]. This approach has the advantage that authorized third parties can easily get access to call-related location information. This also works better if a network entity has location information, rather than the user agent. With the re-INVITE approach, the user agent would have to obtain this information via redirection.

A third alternative is to use the SIP INFO method, as the location update does not require an offer-answer exchange and does not change call state.

7. Preventing Call Misdirection

We need to prevent that an emergency call reaches a destination other than an ECC. For example, a rogue UA able to intercept SIP requests might be able to impersonate an ECC.

In the absence of a globally recognized certificate that ensures that the owner is a legitimate PSAP, we rely on a chain of trust enforced by the 'sips' URI schema. The 'sips' URI schema forces each SIP hop to route the call only to destinations supporting TLS transport. Each ESRP MUST verify that the next-hop destination chosen as described in Section Section 6 corresponds to the server certificate offered by that destination.

8. Requirements for SIP Proxy Servers

All ESRP SHOULD support RFC 3261 [RFC3261] with UDP, TCP, TLS transports.

For robustness, ESRPs SHOULD NOT use RFC 1918 [RFC1918] addresses, i.e., should not be behind network address translators.

9. Configuration

SIP devices do not require any additional configuration to place emergency calls. They SHOULD use the local outbound proxy, discovered via [RFC3361] or [RFC3319].

However, to acquire local dial plan numbers, the SIP configuration framework [I-D.ietf-sipping-config-framework] can be used. The format for dial plans remains to be defined. A device may retrieve dial plan information for emergency calls from two locations, namely the user's home domain and the local outbound proxy, as described in Section 3.13 of [I-D.ietf-sipping-config-framework].

Since a traveling user cannot rely on a DHCP server in the visited location to have accurate local emergency number information, we also propose a new DNS resource record, EN. Typically, this resource record will be associated with a country-level 'sos.arpa' zone, as most countries either have or are developing country-wide emergency numbers. These number strings are treated as dial strings, not "tel" URIs. TBD: It might be possible to use NAPTR [RFC2915] records to include translations such that 110 becomes sos.police for de.sos.arpa. NAPTR translations are not limited to hostnames or URIs.

In the example below, the German emergency number for police is translated into an 'sos' URI. This only works if there is a designated SIP proxy that can route all emergency calls originating in Germany. There does not appear to be a way to substitute the caller's current home AOR domain, although one could conceivably adopt a convention for including this information. Note that this mechanism would also allow direct routing based on finer-grained location information, e.g., at the city level.

de.sos.arpa.
;;       order pre flags service        regexp     replacement
IN NAPTR 100 10 "u" "SOS" "/110/sips:sos.police@notfall.de/i" .

bonn.nrw.de.sos.arpa.
;;       order pre flags service        regexp      replacement
IN NAPTR 100 10 "u" "SOS" "/110/sips:sos.police@pol.bonn.de/i" .

Example NAPTR records to map dial strings to 'sos' URIs

10. Requirements for SIP User Agents

10.1 Emergency call taker

To increase the likelihood that diverse user equipment can successfully communicate with the ECC, it is recommended that call taker equipment has the following minimal capabilites:

signaling: RFC 3261, with UDP, TCP and TLS (sips) support RFC 3262

audio: RTP and RTCP according to ..., G.711, GSM 06.10, FEC, SRTP

Interactive text

SIP-based instant messaging

10.2 Calling users

A user agent placing an emergency call SHOULD use the "sips" URI schema for all such calls, forcing these calls to use TLS as secure hop-by-hop transport. If a call cannot be established using TLS transport, the user agent SHOULD attempt a call using the "sip" URI.

If a user agent receives a redirect (3xx) response for an emergency call, it MUST include the location information contained in that response in the outgoing call. This differs from regular behavior for redirects, where the message body is not copied into the new call.

A user agent MUST check the Contact URI in redirect responses to see if it is an emergency call, as described in Section X. If so, the behavior in the previous paragraph applies.

End systems that allow human users to initiate an emergency call with a single button press or other similar stimulus SHOULD require callers to confirm their call.

11. Example Call Flows

TBD

12. Security Considerations

12.1 ECC Impersonation

See Section Section 7.

With DNS-based call routing (Section Section 6), an attacker could modify the DNS entries for one or more ECCs, re-routing calls destined for them. Thus, the use of secure DNS is RECOMMENDED.

12.2 Call Content Integrity

Normative References

Informative References

Authors' Addresses

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice 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 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 assignees.

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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.