The Internet Protocol Journal, Volume 13, No.4

Emergency Services for Internet Multimedia

by Hannes Tschofenig, Nokia Siemens Networks and Henning Schulzrinne, Columbia University

Summoning the police, the fire department, or an ambulance in emergencies is one of the most important functions the telephone enables. As telephone functions move from circuit-switched to Internet telephony, telephone users rightfully expect that this core feature will continue to be available and work as well as it has in the past. Users also expect to be able to reach emergency assistance using new communication devices and applications, such as instant messaging or Short Message Service (SMS), and new media, such as video. In all cases, the basic objective is the same: The person seeking help needs to be connected with the most appropriate Public Safety Answering Point (PSAP), where call takers dispatch assistance to the caller's location. PSAPs are responsible for a particular geographic region, which can be as small as a single university campus or as large as a country.

The transition to Internet-based emergency services introduces two major structural challenges. First, whereas traditional emergency calling imposed no requirements on end systems and was regulated at the national level, Internet-based emergency calling needs global standards, particularly for end systems. In the old Public Switched Telephone Network (PSTN), each caller used a single entity, the landline or mobile carrier, to obtain services. For Internet multimedia services, network-level transport and applications can be separated, with the Internet Service Provider (ISP) providing IP connectivity service, and a Voice Service Provider (VSP) adding call routing and PSTN termination services. We ignore the potential separation between the Internet access provider, that is, a carrier that provides physical and data link layer network connectivity to its customers, and the ISP that provides network layer services. We use the term VSP for simplicity, instead of the more generic term Application Server Provider (ASP).

The documents that the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group is developing support multimedia-based emergency services, and not just voice. As is explained in more detail later in this article, emergency calls need to be identified for special call routing and handling services, and they need to carry the location of the caller for routing and dispatch. Only the calling device can reliably recognize emergency calls, while only the ISP typically has access to the current geographical location of the calling device based on its point of attachment to the network. The reliable handling of emergency calls is further complicated by the wide variety of access technologies in use, such as Virtual Private Networks (VPNs), other forms of tunneling, firewalls, and Network Address Translators (NATs).

This article describes the architecture of emergency services as defined by the IETF and some of the intermediate steps as end systems and the call-handling infrastructure transition from the current circuit-switched and emergency-calling-unaware Voice-over-IP (VoIP) systems to a true any-media, any-device emergency calling system.

IETF Emergency Services Architecture

The emergency services architecture developed by the IETF ECRIT working group is described in [1] and can be summarized as follows: Emergency calls are generally handled like regular multimedia calls, except for call routing. The ECRIT architecture assumes that PSAPs are connected to an IP network and support the Session Initiation Protocol (SIP) [2] for call setup and messaging. However, the calling user agent may use any call signaling or instant messaging protocol, which the VSP then translates into SIP.

Nonemergency calls are routed by a VSP, either to another subscriber of the VSP, typically through some SIP session border controller or proxy, or to a PSTN gateway. For emergency calls, the VSP keeps its call routing role, routing calls to the emergency service system to reach a PSAP instead. However, we also want to allow callers that do not subscribe to a VSP to reach a PSAP, using nothing but a standard SIP [2] user agent (see [3] and [4] for a discussion about this topic); the same mechanisms described here apply. Because the Internet is global, it is possible that a caller's VSP resides in a regulatory jurisdiction other than where the caller and the PSAP are located. In such circumstances it may be desirable to exclude the VSP and provide a direct signaling path between the caller and the emergency network. This setup has the advantage of ensuring that all parties included in the call delivery process reside in the same regulatory jurisdiction.

As noted in the introduction, the architecture neither forces nor assumes any type of trust or business relationship between the ISP and the VSP carrying the emergency call. In particular, this design assumption affects how location is derived and transported.

Providing emergency services requires three crucial steps, which we describe in the following sections: recognizing an emergency call, determining the caller's location, and routing the call and location information to the appropriate emergency service system operating a PSAP.

Recognizing an Emergency Call

In the early days of PSTN-based emergency calling, callers would dial a local number for the fire or police department. It was recognized in the 1960s that trying to find this number in an emergency caused unacceptable delays; thus, most countries have been introducing single nationwide emergency numbers, such as 911 in North America, 999 in The United Kingdom, and 112 in all European Union countries.

This standardization became even more important as mobile devices started to supplant landline phones. In some countries, different types of emergency services, such as police or mountain rescue, are identified by separate numbers. Unfortunately, more than 60 different emergency numbers are used worldwide, many of which also have nonemergency uses in other countries, so simply storing the list of numbers in all devices is not feasible. In addition, hotels and university campuses often use dial prefixes, so an emergency caller in some European universities may actually have to dial 0112 to reach the fire department.

Because of this diversity, the ECRIT architecture decided to separate the concept of an emergency dial string, which remains the familiar and regionally defined emergency number, and a protocol identifier that is used for identifying emergency calls within the signaling system. The calling end system has to recognize the emergency (service) dial string and translate it into an emergency service identifier, which is an extensible set of Uniform Resource Names (URNs) defined in RFC 5031 [5]. A common example for such a URN, defined to reach the generic emergency service, is urn:service.sos. The emergency service URN is included in the signaling request as the destination and is used to identify the call as an emergency call. If the end system fails to recognize the emergency dial string, the VSP may also perform this service.

Because mobile devices may be sold and used worldwide, we want to avoid manually configuring emergency dial strings. In general, a device should recognize the emergency dial string familiar to the user and the dial strings customarily used in the currently visited country. The Location-to-Service Translation Protocol (LoST) [6], described in more detail later, also delivers this information.

Some devices, such as smartphones, can define dedicated user interface elements that dial emergency services. However, such mechanisms must be carefully designed so that they are not accidentally triggered, for example, when the device is in a pocket.

Emergency Call Routing

When an emergency call is recognized, the call needs to be routed to the appropriate PSAP. Each PSAP is responsible for only a limited geographic region, its service region, and some set of emergency services. For example, even in countries with a single general emergency number such as the United States, poison-control services maintain their own set of call centers. Because VSPs and end devices cannot keep a complete up-to-date mapping of all the service regions, a mapping protocol, LoST [6], maps a location and service URN to a specific PSAP Uniform Resource Identifier (URI) and a service region.

LoST, illustrated in Figure 1, is a Hypertext Transfer Protocol (HTTP)-based query/response protocol where a client sends a request containing the location information and service URN to a server and receives a response containing the service URL, typically a SIP URL, the service region where the same information would be returned, and an indication of how long the information is valid. Both request and response are formatted as Extensible Markup Language (XML). For efficiency, responses are cached, because otherwise every small movement would trigger a new LoST request. As long as the client remains in the same service region, it does not need to consult the server again until the response returned reaches its expiration date. The response may also indicate that only a more generic emergency service is offered for this region. For example, a request for urn:service:sos.marine in Austria may be replaced by urn:service:sos. Finally, the response also indicates the emergency number and dial string for the respective service.

The number of PSAPs serving a country varies significantly. Sweden, for example, has 18 PSAPs, and the United States has approximately 6,200. Therefore, there is roughly one PSAP per 500,000 inhabitants in Sweden and one per 50,000 in the United States. As all-IP infrastructure is rolled out, smaller PSAPs may be consolidated into regional PSAPs. Routing may also take place in multiple stages, with the call being directed to an Emergency Services Routing Proxy (ESRP), which in turn routes the call to a PSAP, accounting for factors such as the number of available call takers or the language capabilities of the call takers.

Figure 1: High-Level Functions of Location-to-Service Translation (LoST) Protocol

Location Information

Emergency services need location information for three reasons: routing the call to the right PSAP, dispatching first responders (for example, policemen), and determining the right emergency service dial strings. It is clear that the location must be automatic for the first and third applications, but experience has shown that automated, highly accurate location information is vital to dispatching as well, rather than relying on callers to report their locations to the call taker.

Such information increases accuracy and avoids dispatch delays when callers are unable to provide location information because of language barriers, lack of familiarity with their surroundings, stress, or physical or mental impairment.

Location information for emergency purposes comes in two representations: geo(detic), that is, longitude and latitude, and civic, that is, street addresses similar to postal addresses. Particularly for indoor location, vertical information (floors) is very useful. Civic locations are most useful for fixed Internet access, including wireless hotspots, and are often preferable for specifying indoor locations, whereas geodetic location is frequently used for cell phones. However, with the advent of femto and pico cells, civic location is both possible and probably preferable because accurate geodetic information can be very hard to acquire indoors.

In almost all cases, location values are represented as Presence Information Data Format Location Object (PIDF-LO), an XML-based document to encapsulate civic and geodetic location information. The format of PIDF-LO is described in [7], with the civic location format updated in [8] and the geodetic location format profiled in [9]. The latter document uses the Geography Markup Language (GML) developed by the Open Geospatial Consortium (OGC) for describing commonly used location shapes.

Location can be conveyed either by value ("LbyV") or by reference ("LbyR"). For the former, the XML location object is added as a message body in the SIP message. Location by value is particularly appropriate if the end system has access to the location information; for example, if it contains a Global Positioning System (GPS) receiver or uses one of the location configuration mechanisms described later in this section. In environments where the end host location changes frequently, the LbyR mechanism might be more appropriate. In this case, the LbyR is an HTTP/Secure HTTP (HTTPS) or SIP/Secure SIP (SIPS) URI, which the recipient needs to resolve to obtain the current location. Terminology and requirements for the LbyR mechanism are available in [10].

An LbyV and an LbyR can be obtained through location config-uration protocols, such as the HTTP Enabled Location Delivery (HELD) protocol [11] or Dynamic Host Configuration Protocol (DHCP) [12, 13]. When obtained, location information is required for LoST queries, and that information is added to SIP messages [14].

The requirements for location accuracy differ between routing and dispatch. For call routing, city or even county-level accuracy is often sufficient, depending on how large the PSAP service areas are, whereas first responders benefit greatly when they can pinpoint the caller to a particular building or, better yet, apartment or office for indoor locations, and an outdoor area of at most a few hundred meters. This detailed location information avoids having to search multiple buildings, for example, for medical emergencies.

As mentioned previously, the ISP is the source of the most accurate and dependable location information, except for cases where the calling device has built-in location capabilities, such as GPS, when it may have more accurate location information. For landline Internet connections such as DSL, cable, or fiber-to-the-home, the ISP knows the provisioned location for the network termination, for example. The IETF GEOPRIV working group has developed protocol mechanisms, called Location Configuration Protocols, so that the end host can request and receive location information from the ISP. The Best Current Practice document for emergency calling [15] enumerates three options that clients should universally support: DHCP civic [16] and geo [12] (with a revision of RFC 3825 in progress [17]), and HELD [11]. HELD uses XML query and response objects carried in HTTP exchanges. DHCP does not use the PIDF-LO format, but rather more compact binary representations of locations that require the endpoint to construct the PIDF-LO.

Particularly for cases where end systems are not location-capable, a VSP may need to obtain location information on behalf of the end host [18].

Obtaining at least approximate location information at the time of the call is time-critical, because the LoST query can be initiated only after the calling device or VSP has obtained location information. Also, to accelerate response, it is desirable to transmit this location information with the initial call signaling message. In some cases, however, location information at call setup time is imprecise. For example, a mobile device typically needs 15 to 20 seconds to get an accurate GPS location "fix," and the initial location report is based on the cell tower and sector. For such calls, the PSAP should be able to request more accurate location information either from the mobile device directly or the Location Information Server (LIS) operated by the ISP. The SIP event notification extension, defined in RFC 3265 [19], is one such mechanism that allows a PSAP to obtain the location from an LIS. To ensure that the PSAP is informed only of pertinent location changes and that the number of notifications is kept to a minimum, event filters [20] can be used.

The two-stage location refinement mechanism described previously works best when location is provided by reference (LbyR) in the SIP INVITE call setup request. The PSAP subscribes to the LbyR provided in the SIP exchange and the LbyR refers to the LIS in the ISP's network. In addition to a SIP URI, the LbyR message can also contain an HTTP/HTTPS URI. When such a URI is provided, an HTTP-based protocol can be used to retrieve the current location [21].

Obligations

This section discusses the requirements the different entities need to satisfy, based on Figure 2. A more detailed description can be found in [15].

Note that this narration focuses on the final stage of deployment and does not discuss the transition architecture, in which some implementation responsibilities can be rearranged, with an effect on the overall functions offered by the emergency services architecture. A few variations were introduced to handle the transition from the current system to a fully developed ECRIT architecture.

Figure 2: Main Components Involved in an Emergency Call

With the work on the IETF emergency architecture, we have tried to balance the responsibilities among the participants, as described in the following sections.

End Hosts

An end host, through its VoIP application, has three main responsibilities: it has to attempt to obtain its own location, determine the URI of the appropriate PSAP for that location, and recognize when the user places an emergency call by examining the dial string. The end host operating system may assist in determining the device location.

The protocol interaction for location configuration is indicated as interface (a) in Figure 2; numerous location configuration protocols have been developed to provide this capability.

A VoIP application needs to support the LoST protocol [6] in order to determine the emergency service dial strings and the PSAP URI. Additionally, the device needs to understand the service identifiers, defined in [5].

As currently defined, it is assumed that SIP can reach PSAPs, but PSAPs may support other signaling protocols, either directly or through a protocol translation gateway. The LoST retrieval results indicate whether other signaling protocols are supported. To provide support for multimedia, use of different types of codecs may be required; details are available in [15].

ISP

The ISP has to make location information available to the endpoint through one or more of the location configuration protocols.

In order to route an emergency call correctly to a PSAP, an ISP may initially disclose the approximate location for routing to the endpoint and give more precise location information later, when the PSAP operator dispatches emergency personnel. The functions required by the IETF emergency services architecture are restricted to the disclosure of a relatively small amount of location information, as discussed in [22] and in [23].

The ISP may also operate a (caching) LoST server to improve the robustness and reliability of the architecture. This server lowers the round-trip time for contacting a LoST server, and the caches are most likely to hold the mappings of the area where the emergency caller is currently located.

When ISPs allow Internet traffic to traverse their network, the signaling and media protocols used for emergency calls function without problems. Today, there are no legal requirements to offer prioritization of emergency calls over IP-based networks. Although the standardization community has developed a range of Quality of Service (QoS) signaling protocols, they have not experienced widespread deployment.

VSP

SIP does not mandate that call setup requests traverse SIP proxies; that is, SIP messages can be sent directly to the user agent. Thus, even for emergency services it is possible to use SIP without the involvement of a VSP. However, in terms of deployment, it is highly likely that a VSP will be used. If a caller uses a VSP, this VSP often forces all calls, emergency or not, to traverse an outbound proxy or Session Border Controller (SBC) operated by the VSP. If some end devices are unable to perform a LoST lookup, VSP can provide the necessary functions as a backup solution.

If the VSP uses a signaling or media protocol that the PSAP does not support, it needs to translate the signaling or media flows.

VSPs can assist the PSAP by providing identity assurance for emergency calls; for example, using [30], thus helping to prosecute prank callers. However, the link between the subscriber information and the real-world person making the call is weak.

In many cases, VSPs have, at best, only the credit card data for their customers, and some of these customers may use gift cards or other anonymous means of payment.

PSAP

The emergency services Best Current Practice document [15] discusses only the standardization of the interfaces from the VSP and ISP toward PSAPs and some parts of the PSAP-to-PSAP call transfer mechanisms that are necessary for emergency calls to be processed by the PSAP. Many aspects related to the internal communication within a PSAP, between PSAPs as well as between a PSAP and first responders, are beyond the scope of the IETF specification.

When emergency calling has been fully converted to Internet proto-cols, PSAPs must accept calls from any VSP, as shown in interface (d) of Figure 2. Because calls may come from all sources, PSAPs must develop mechanisms to reduce the number of malicious calls, particularly calls containing intentionally false location information. Assuring the reliability of location information remains challenging, particularly as more and more devices are equipped with Global Navigation Satellite Systems (GNSS) receivers, including GPS and Galileo, allowing them to determine their own location [24]. However, it may be possible in some cases to check the veracity of the location information an endpoint provides by comparing it against infrastructure-provided location information; for example, a LIS-determined location.

Mapping Architecture

So far we have described LoST as a client-server protocol. Similar to the Domain Name System (DNS), a single LoST server does not store the mapping elements for all PSAPs worldwide, for both technical and administrative reasons. Thus, there is a need to let LoST servers interact with other LoST servers, each covering a specific geographical region. Working together, LoST servers form a distributed mapping database, with each server carrying mapping elements, as shown in Figure 3. LoST servers may be operated by different entities, including the ISP, the VSP, or another independent entity, such as a governmental agency. Typically, individual LoST servers offer the necessary mapping elements for their geographic regions to others. However, LoST servers may also cache mapping elements of other LoST servers either through data synchronization mechanisms (for example, FTP or exports from a Geographical Information System [GIS] or through a specialized protocol [25]) or by regular usage of LoST. This caching improves performance and increases the robustness of the system.

Figure: Mapping Element

A detailed description of the mapping architecture with examples is available in [29].

Steps Toward an IETF Emergency Services Architecture

The architecture described so far requires changes both in already-deployed VoIP end systems and in the existing PSAPs. The speed of transition and the path taken vary between different countries, depending on funding and business incentives. Therefore, it is generally difficult to argue whether upgrading endpoints or replacing the emergency service infrastructure will be easier. In any case, the transition approaches being investigated consider both directions. We can distinguish roughly four stages of transition (Note: The following descriptions omit many of the details because of space constraints):

  1. Initially, VoIP end systems cannot place emergency calls at all; for example, many software clients, such as GoogleTalk, cannot place emergency calls.
  2. In a second stage, VoIP callers manually configure their location, and emergency calls are routed to the appropriate PSAP as circuit-switched calls through PSTN gateways using technologies similar to mobile calls. This level of service is now offered in some countries for PSTN-replacement VoIP services; that is, VoIP services that are offered as replacement for the home phone. In the United States, this service is known as the "NENA I2" service.
  3. In a third stage, PSAPs maintain two separate infrastructures, one for calls arriving through an IP network and the traditional infrastructure.
  4. In the final stage, all calls, including those from traditional cell phones and analog landline phones, reach the PSAP through IP networks, with the traditional calls converted to the ECRIT requirements by the carriers or the emergency service infrastructure.

If devices are used in environments without location services, the VSP's SIP proxy may need to insert location information based on estimates or subscriber data. These cases are described briefly in the following sections.

Traditional Endpoints

Figure 4 shows an emergency services architecture with traditional endpoints. When the emergency caller dials the Europeanwide emergency number 112 (step 0), the device treats it as any other call without recognizing it as an emergency call; that is, the dial string provided by the endpoint that may conform to RFC 4967 [26] or RFC 3966 [27] is signaled to the VSP (step 1). Recognition of the dial string is then left to the VSP for processing or sorting; the same is true for location retrieval (step 2) and routing to the nearest (or appropriate) PSAP (step 3). Dial-string recognition, location determination, and call routing are simpler to carry out using a fixed device and the voice and application service provided through the ISP than they are when the VSP and the ISP are two separate entities.

Figure 4: Emergency Services Architecture with Traditional Endpoints

There are two main challenges to overcome when dealing with traditional devices: First, the VSP must discover the LIS that knows the location of the IP-based end host. The VSP is likely to know only the IP address of that device, visible in the call signaling that arrives at the VSP. When a LIS is discovered and contacted and some amount of location information is available, then the second challenge arises, namely, how to route the emergency call to the appropriate PSAP. To accomplish the latter task it is necessary to have some information about the PSAP boundaries available.

Reference [15] does not describe a complete and detailed solution but uses building blocks specified in ECRIT. Still, this deployment scenario shows many constraints:

  • Only the emergency numbers configured at the VSP are understood. This situation may lead to cases where a dialed emergency number is not recognized.
  • Using the IP address to find the ISP is challenging and may, in case of mobility protocols and VPNs, lead to wrong results.
  • Security concerns might arise when a potentially large number of VSPs or ASPs are able to retrieve location information from an ISP. It is likely that only authorized VSP and ASPs will be granted access. Hence, it is unlikely that such a solution would work smoothly across national boundaries.
  • When the user agent does not recognize the emergency call, functions such as call waiting, call transfer, three-way call, flash hold, and outbound call blocking cannot be disabled.
  • The user-agent software may block callbacks from the PSAP.
  • Privacy settings may not get considered and identity may get disclosed to unauthorized parties. These identity privacy features exist in some jurisdictions even in emergency situations.
  • Certain VoIP call features may not be supported, such as REFER (for conference call and transfer to secondary PSAP) and Globally Routable UA URI (GRUU).
  • User agents will not convey location information to the VSP (even if available).

Partially Upgraded End Hosts

A giant step forward in simplifying the handling of IP-based emergency calls is to provide the end host with some information about the ISP so that LIS discovery is possible. The end host may, for example, learn the ISP's domain name by using LIS discovery [28], or might even obtain a Location by Reference (LbyR) through the DHCP-URI option [13] or through HELD [11]. The VSP can then either resolve the LbyR in order to route the call or use the domain to discover a LIS using DNS.

Additional software upgrades at the end device may allow for recognition of emergency calls based on some preconfigured emergency numbers (for example, 112 and 911) and allow for the implementation of other emergency service-related features, such as disabling silence suppression during emergency calls.

Outlook

In most countries, national and sometimes regional telecommunications regulators, such as the Federal Communications Commission (FCC) and individual states, or the European Union, strongly influence how emergency services are provided, who pays for them, and the obligations that the various parties have. Regulation is, however, still at an early stage: in most countries current requirements demand only manual update of location information by the VoIP user. The ability to obtain location information automatically is, however, crucial for reliable emergency service operation, and it is required for nomadic and mobile devices. (Nomadic devices remain in one place during a communication session, but are moved frequently from place to place. Laptops with Wi-Fi interfaces are currently the most common nomadic devices.)

Regulators have traditionally focused on the national or, at most, the European level, and the international nature of the Internet poses new challenges. For example, mobile devices are now routinely used beyond their country of purchase and, unlike traditional cellular phones, need to support emergency calling functions. It appears likely that different countries will deploy IP-based emergency services over different time horizons, so travelers may be surprised to find that they cannot call for emergency assistance outside their home country.

The separation between Internet access and application providers on the Internet is one of the most important differences to existing circuit-switched telephony networks. A side effect of this separation is the increased speed of innovation at the application layer, and the number of new communication mechanisms is steadily increasing. Many emergency service organizations have recognized this trend and advocated for the use of new communication mechanisms, including video, real-time text, and instant messaging, to offer improved emergency calling support for citizens. Again, this situation requires regulators to rethink the distribution of responsibilities, funding, and liability.

Many communication systems used today lack accountability; that is, it is difficult or impossible to trace malicious activities back to the persons who caused them. This problem is not new, because pay phones and prepaid cell phones have long offered mischief makers the opportunity to place hoax calls, but the weak user registration procedures, the lack of deployed end-to-end identity mechanisms, and the ease of providing fake location information increases the attack surface at PSAPs. Attackers also have become more sophisticated over time, and Botnets that generate a large volume of automated emergency calls to exhaust PSAP resources, including call takers and first responders, are not science fiction.

References

[1] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia," Internet Draft, work in progress, draft-ietf-ecrit-framework-11, July 2010.

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

[3] Winterbottom, J., Thomson, M., Tschofenig, H., and H. Schulzrinne, "ECRIT Direct Emergency Calling," Internet Draft, work in progress, draft-winterbottom-ecrit-direct-02.txt, March 2010.

[4] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., and D. Kroeselberg, "Extensions to the Emergency Services Architecture for Dealing with Unauthenticated and Unauthorized Devices," Internet Draft, work in progress, draft-ietf-ecrit-unauthenticated-access-00.txt, September 2010.

[5] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services," RFC 5031, January 2008.

[6] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol," RFC 5222, August 2008.

[7] Peterson, J., "A Presence-based GEOPRIV Location Object Format," RFC 4119, December 2005.

[8] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)," RFC 5139, February 2008.

[9] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations," RFC 5491, March 2009.

[10] R. Marshall, "Requirements for a Location-by-Reference Mechanism," RFC 5808, May 2010.

[11] M. Barnes, "HTTP Enabled Location Delivery (HELD)," RFC 5985, September 2010.

[12] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information," RFC 3825, July 2004.

[13] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)," Internet Draft, work in progress, draft-ietf-geopriv-dhcp-lbyr-uri-option-08, July 2010.

[14] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol," Internet Draft, work in progress, draft-ietf-sipcore-location-conveyance-03, July 2010.

[15]  Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling," Internet Draft, work in progress, draft-ietf-ecrit-phonebcp-15, July 2010.

[16] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information," RFC 4776, November 2006.

[17] Polk, J., Schnizlein, J., Linsner, M., and B. Aboba, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information," Internet Draft, work in progress, draft-ietf-geopriv-rfc3825bis-11, July 2010.

[18] Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)," Internet Draft, work in progress, draft-ietf-geopriv-held-identity-extensions-04, June 2010.

[19] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification," RFC 3265, June 2002.

[20] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Location Notifications in the Session Initiation Protocol," Internet Draft, work in progress, draft-ietf-geopriv-loc-filters-11, March 2010.

[21] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., and M. Dawson, "A Location Dereferencing Protocol Using HELD," Internet Draft, work in progress, draft-ietf-geopriv-deref-protocol-01, September 2010.

[22] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. Kuett, "Location Hiding: Problem Statement and Requirements," Internet Draft, work in progress, draft-ietf-ecrit-location-hiding-req-04, Feb 2010.

[23] Barnes, R., and M. Lepinski, "Using Imprecise Location for Emergency Context Resolution," Internet Draft, work in progress, draft-ietf-ecrit-rough-loc-03, August 2010.

[24] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy Location Information," Internet Draft, work in progress, draft-tschofenig-ecrit-trustworthy-location-00, September 2010.

[25] Schulzrinne, H., and H. Tschofenig, "Synchronizing Location-to-Service Translation (LoST) Servers," Internet Draft, work in progress, draft-ietf-ecrit-lost-sync-10, March 2010.

[26] B. Rosen, "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier," RFC 4967, July 2007.

[27] H. Schulzrinne "The tel URI for Telephone Numbers," RFC 3966, December 2004.

[28] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)," RFC 5986, September 2010.

[29] H. Schulzrinne, "Location-to-URL Mapping Architecture and Framework," RFC 5582, September 2009.

[30] C. Jennings, J. Peterson, and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks," RFC 3325, November 2002.

HENNING SCHULZRINNE, Levi Professor of Computer Science at Columbia University, received his Ph.D. from the University of Massachusetts in Amherst, Massachusetts. He was an MTS at AT&T Bell Laboratories and an associate department head at GMD-Fokus (Berlin) before joining the Computer Science and Electrical Engineering departments at Columbia University. He served as chair of Computer Science from 2004 to 2009. Protocols that he co-developed, such as RTP, RTSP, and SIP, are now Internet standards, used by almost all Internet telephony and multimedia applications. His research interests include Internet multimedia systems, ubiquitous computing, and mobile systems. He is a Fellow of the IEEE. E-mail: hgs@cs.columbia.edu

HANNES TSCHOFENIG received a Diploma degree from the University of Klagenfurt, Austria. He joined Siemens Corporate Technology, Munich, in 2001 and joined Nokia Siemens Networks in April 2007 to move to Finland in December 2007, where he focuses on standards development. Most of his time is dedicated to the participation in the Internet Engineering Task Force (IETF) where he, among other responsibilities, co-chaired the ECRIT working group from 2005 to early 2010. Additionally, he co-chairs the Next Generation 112 Technical Committee of the European Emergency Number Association (EENA) and contributes to the technical specifications developed within the National Emergency Number Association (NENA), and he co-organized the SDO emergency services workshop series. In March 2010 he joined the Internet Architecture Board (IAB). E-mail: hannes.tschofenig@nsn.com