Emergency Calling for SIP

Drafts and Papers

NENA i2, as summarized by Brian Rosen:
A VPC is a VoIP Positioning Center, and is a service provider contracted by a VSP to provide it 9-1-1 services. The VPC has connections to the database the PSAPs make queries to (the ALI). ALI queries are made with telephone numbers, and can return a civic or a geo address. The connection between the VPC and the ALI database is called "E2" (or another interface, "PAM").

The VPC gets the address and decides which PSAP should get the call. It then allocates a phone number to the call that is area code appropriate for the PSAP. It can't use the real phone number, because the system does not accommodate non-local area codes and the caller could be roaming. These are generically called "pseudoANIs" (pANIs) or, more specifically for i2, Emergency Services Query Keys (ESQKs). The ESQK is associated with a specific PSAP. When presented to the 9-1-1 tandem ("Selective Router"), that number will cause the call to be routed to the right PSAP.

The VPC saves the location. When the PSAP queries ALI with the ANI it gets on the call (which in this case would be the ESQK the VPC allocated for it), the query is "steered" to the VPC that owns it over the E2 interface. When the VPC gets the query, it responds with the location of the caller. This may be a civic or a geo.

3GPP TR 23.867: Internet Protocol (IP) based IP Multimedia Subsystem (IMS) emergency sessions
The present document is a temporary container for the architectural impacts on IM CN subsystem and on IP-Connectivity Access Network for establishing an emergency session via IM CN subsystem. The contents of this report when stable will be moved into 3GPP Technical Specification e.g. TS 23.002, TS 23.060 and TS 23.228.
TS22.101: Service aspects; Service principles
Section 10 covers emergency calls.
3GPP TS 23.167: IP Multimedia Subsystem (IMS) emergency sessions
This document defines the stage-2 service description for emergency services in the IP Multimedia Core Network Subsystem (IMS), including the elements necessary to support IP Multimedia (IM) emergency services. ITU T Recommendation I.130 describes a three-stage method for characterisation of telecommunication services, and ITU T Recommendation Q.65 defines stage 2 of the method. This document covers also the Access Network aspects that are crucial for the provisioning of IMS emergency services. Other 3GPP specifications that are related to the IMS emergency services are TS 23.228 on IMS in general, including fixed broadband access aspects, TS 23.060 and TS 23.234 describing GPRS and 3GPP/WLAN Interworking respectively and TS 23.271 that covers location services. TS 25.301 contains an overall description of the UMTS Terrestrial Radio Access Network.
Comments of the Global IP Alliance and Professor Henning Schulzrinne
Pursuant to Section 1.2 of the Commission's Rules, 47 C.F.R. § 1.2, the Global IP Alliance submits these comments in response to the Commission's Notice of Proposed Rulemaking in the above captioned proceeding. These comments consist of a document prepared by Professor Henning Schulzrinne3 with the Global IP Alliance and considers how to move towards a globally-oriented, more robust and functional IP-based next-generation emergency response.
A VoIP Emergency Services Architecture and Prototype
To be published at ICCCN 2005, San Diego, October 2005.
Providing emergency services in VoIP networks is vital to the success of VoIP. It not only presents design and implementation challenges, but also gives an opportunity to enhance the existing emergency call handling infrastructure. We propose an architecture to deliver emergency services in SIP-based VoIP networks, which can accommodate PSTN calls through PSTN to SIP gateways. Our architecture addresses the issues of identifying emergency calls, determining callers’ locations, routing emergency calls to appropriate public safety access points (PSAP), and presenting required information to emergency call takers. We have developed a prototype implementation to prove our architecture's feasibility and scalability. We expect to undertake a pilot project at a working PSAP with our implementation once it is thoroughly tested.
E911 Requirements for IP-Enabled Service
"In this Order, we adopt rules requiring providers of interconnected voice over Internet Protocol (VoIP) service to supply enhanced 911 (E911) capabilities to their customers. Interconnected VoIP providers may satisfy this requirement by interconnecting indirectly through a third party such as a competitive LEC, interconnecting directly with the Wireline E911 Network, or through any other solution that allows a provider to offer E911 service. The characteristics of interconnected VoIP services have posed challenges for 911/E911 and threaten to compromise public safety. Thus, we require providers of interconnected VoIP service to provide E911 services to all of their customers as a standard feature of the service, rather than as an optional enhancement. We further require them to provide E911 from wherever the customer is using the service, whether at home or away from home."
Emergency Services for Internet Telephony Systems
Henning Schulzrinne and Brian Rosen
July 2004
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.
9-1-1 Calls for Voice-over-IP - Ex-Parte Filing for Docket 94-102
H. Schulzrinne
February 28, 2003 (FCC filing)
This document enumerates some of the major opportunities and challenges for providing emergency call (9-1-1) services using IP technology. In particular, all VoIP devices are effectively mobile. The same IP telephony device works anywhere in the Internet, keeping the same external identifier such as an E.164 number or URL. Transitioning to an IP-based E9-1-1 infrastructure not only supports emerging VoIP systems, but can also greatly improve the capabilities of the emergency call infrastructure. It can become more resilient, sets up calls faster, better supports subscribers with hearing disabilities, adds multimedia information to better direct resources, allows competition for elements of the network infrastructure, conveys more call-associated data and allowmore cost-effective PSAP technology.

Providing Emergency Call Services for SIP-based Internet Telephony
H. Schulzrinne
March 2001 (outdated).
If Internet Telephony is to offer a full replacement for traditional telephone services, it needs to provide emergency call services. In the United States, emergency calls are known as 911 services, based on the number dialed. This note desccribes some options for providing enhanced emergency service, i.e., emergency calls that allow emergency response centers to determine the address where the caller is located. This is made more difficult by the temporary nature of IP addresses, the large number of ISPs and their lack of legal responsibility for emergency services and the ability of many Internet terminals to be connected to the Internet at different locations. This note explores some of the requirements and design choices.

Emergency Services Messaging Interface, ATIS document
"This document contains standards for an Emergency Services interface to the Emergency Services Network (ESNet). It specifies protocols and message sets for use in the Emergency Services Messaging Interface (EMSI). The Emergency Services Messaging Interface is the evolution of the Emergency Service Network that provides sophisticated and robust services to the PSAP and other authorized agencies. The Emergency Services Messaging Interface supports a future direction toward a next generation emergency services network." (Emergency Services Messaging Interface Task Force)



Limitations of Existing Emergency Calling Systems

Core Assumptions for VoIP Emergency Services


IT Crowd emergency email; IT Crowd emergency number;

Last updated by Henning Schulzrinne