draft-ietf-ecrit-framework-01.txt   draft-ietf-ecrit-framework-02.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: September 2, 2007 Columbia U. Expires: January 9, 2008 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
SunRocket SunRocket
March 01, 2007 July 08, 2007
Framework for Emergency Calling in Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-01 draft-ietf-ecrit-framework-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at 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 The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2007. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Summoning emergency help by the public is a core feature of telephone Summoning emergency help by the public is a core feature of telephone
networks. This document describes a framework of how various IETF networks. This document describes how various IETF protocols and
protocols and mechanisms are combined to place emergency calls. This mechanisms are combined to place emergency calls. This includes how
includes how these calls are routed to the correct Public Safety these calls are routed to the correct Public Safety Answering Point
Answering Point (PSAP) based on the physical location of the caller, (PSAP) based on the physical location of the caller, while providing
while providing the call taker the necessary information to dispatch the call taker the necessary information to dispatch a first
a first responder to that location. This document explains how responder to that location and to call back the caller if necessary.
location mapping, call identification and end system behavior are It describes at a high level how the pieces (recognizing a call as an
combined to allow multimedia emergency calls. It describes at a high emergency call, marking it as such, determining the location of the
level how the pieces (recognizing a call as an emergency call, caller, routing the call based on location) go together, and
marking it as such, determining the location of the caller, routing references the Internet standards that define the details of these
the call based on location) go together, and references the Internet mechanisms.
standards that define the details of these mechanisms.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of How Emergency Calls are Placed . . . . . . . . . . 7 3. Overview of How Emergency Calls are Placed . . . . . . . . . . 7
4. Identifying an Emergency Call . . . . . . . . . . . . . . . . 11 4. Identifying an Emergency Call . . . . . . . . . . . . . . . . 12
5. Location and Its Role in an Emergency Call . . . . . . . . . . 12 5. Location and Its Role in an Emergency Call . . . . . . . . . . 12
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Types of Location Information . . . . . . . . . . . . . . 12 5.2. Types of Location Information . . . . . . . . . . . . . . 13
5.3. Location Determination . . . . . . . . . . . . . . . . . . 13 5.3. Location Determination . . . . . . . . . . . . . . . . . . 14
5.3.1. User-Entered Location Information . . . . . . . . . . 14 5.3.1. User-Entered Location Information . . . . . . . . . . 15
5.3.2. Access Network "Wire Database" Location Information . 14 5.3.2. Access Network "Wire Database" Location Information . 15
5.3.3. End-System Measured Location Information . . . . . . . 15 5.3.3. End-System Measured Location Information . . . . . . . 16
5.3.4. Third-party Measured Location Information . . . . . . 15 5.3.4. Third-party Measured Location Information . . . . . . 16
5.4. Location and References to Location . . . . . . . . . . . 16 5.4. Location and References to Location . . . . . . . . . . . 17
5.5. End System Location Configuration . . . . . . . . . . . . 16 5.5. End System Location Configuration . . . . . . . . . . . . 17
5.6. Conveyance of Location . . . . . . . . . . . . . . . . . . 18 5.6. Conveyance of Location . . . . . . . . . . . . . . . . . . 19
5.7. Location Updates . . . . . . . . . . . . . . . . . . . . . 18 5.7. Location Updates . . . . . . . . . . . . . . . . . . . . . 19
5.8. Location Validation . . . . . . . . . . . . . . . . . . . 19 5.8. Location Validation . . . . . . . . . . . . . . . . . . . 20
5.9. Default Location . . . . . . . . . . . . . . . . . . . . . 19 5.9. Default Location . . . . . . . . . . . . . . . . . . . . . 21
6. Routing the Call to the PSAP . . . . . . . . . . . . . . . . . 20 5.10. Uninitialized Devices and Location . . . . . . . . . . . . 21
7. Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 21 6. Routing the Call to the PSAP . . . . . . . . . . . . . . . . . 21
8. Caller Preferences . . . . . . . . . . . . . . . . . . . . . . 22 7. Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 23
9. Including a Valid Call-Back Identifier . . . . . . . . . . . . 22 8. Caller Preferences . . . . . . . . . . . . . . . . . . . . . . 23
10. Mid-Call Services and Behavior . . . . . . . . . . . . . . . . 23 9. Including a Valid Call-Back Identifier . . . . . . . . . . . . 23
11. Call Termination . . . . . . . . . . . . . . . . . . . . . . . 23 10. Mid-Call Services and Behavior . . . . . . . . . . . . . . . . 24
12. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Call Termination . . . . . . . . . . . . . . . . . . . . . . . 24
13. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 24 13. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
15. Alternatives Considered . . . . . . . . . . . . . . . . . . . 24 14. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 25
15.1. tel URIs . . . . . . . . . . . . . . . . . . . . . . . . . 24 15. Alternatives Considered . . . . . . . . . . . . . . . . . . . 25
16. Security Considerations . . . . . . . . . . . . . . . . . . . 24 15.1. tel URIs . . . . . . . . . . . . . . . . . . . . . . . . . 26
16.1. Caller Authentication . . . . . . . . . . . . . . . . . . 25 16. Security Considerations . . . . . . . . . . . . . . . . . . . 26
16.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 26 16.1. Caller Authentication . . . . . . . . . . . . . . . . . . 27
16.3. PSAP Impersonation . . . . . . . . . . . . . . . . . . . . 26 16.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 27
16.4. Preventing Call Misdirection . . . . . . . . . . . . . . . 26 16.3. PSAP Impersonation . . . . . . . . . . . . . . . . . . . . 28
16.5. Call Signaling Integrity . . . . . . . . . . . . . . . . . 27 16.4. Preventing Call Misdirection . . . . . . . . . . . . . . . 28
16.6. Media Integrity and Confidentiality . . . . . . . . . . . 27 16.5. Call Signaling Integrity . . . . . . . . . . . . . . . . . 28
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 16.6. Media Integrity and Confidentiality . . . . . . . . . . . 28
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
18.1. Normative References . . . . . . . . . . . . . . . . . . . 27 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
18.2. Informative References . . . . . . . . . . . . . . . . . . 30 18.1. Normative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 18.2. Informative References . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 34
1. Terminology 1. Terminology
As a framework document, we do not define any new protocols or As a framework document, we do not define any new protocols or
articulate new behaviors. Thus we do not use RFC2119 [RFC2119] articulate new behaviors. Thus we do not use RFC2119 [RFC2119]
notation. In this document, we reuse terms, and their definition, notation. The following terms are used:
from [I-D.ietf-ecrit-requirements]. In addition, the following terms
are used:
(Emergency) call taker: see [I-D.ietf-ecrit-requirements] (Emergency) call taker: see [I-D.ietf-ecrit-requirements]
ESRP (emergency service routing proxy): see ESRP (emergency service routing proxy): see
[I-D.ietf-ecrit-requirements] [I-D.ietf-ecrit-requirements]
Access Network: The wide area network that supplies IP packet Access Network: The network that supplies IP packet service to an
service to an endpoint. In a residential or small business endpoint. In a residential or small business environment, this
environment, this might be a DSL or cable modem or WiMax service. might be a DSL or cable modem or WiMax service. In a large
In a large enterprise environment, this would be the enterprise enterprise environment, this would be the enterprise network. In
network. In a mobile environment, this might be a mobile a mobile environment, this might be a mobile (cellular) data
(cellular) data network or a WiFi network. network or a WiFi network.
Location Configuration: The process by which an endpoint learns its Location Configuration: The process by which an endpoint learns its
physical location. physical location.
Location Conveyance: The process of sending location to another Location Conveyance: The process of sending location to another
element. element.
Location Determination: The mechanism used to resolve where an Location Determination: The process of finding where an endpoint is
endpoint is physically. For example, the endpoint may have a GPS physically. For example, the endpoint may contain a GPS receiver
receiver. used to measure its own location.
Location Information Server An element that stores location Location Information Server: An element that stores location
information for retrieval by an authorized entity information for retrieval by an authorized entity
Location Validation: see [I-D.ietf-ecrit-requirements] Location Validation: see [I-D.ietf-ecrit-requirements]
Mapping: see [I-D.ietf-ecrit-requirements] Mapping: see [I-D.ietf-ecrit-requirements]
NENA (National Emergency Number Association: A North American NENA (National Emergency Number Association): A North American
organization of public safety focused individuals defining organization of public safety focused individuals defining
emergency calling specifications and procedures. emergency calling specifications and procedures.
PSAP (public safety answering point): see PSAP (public safety answering point): see
[I-D.ietf-ecrit-requirements] [I-D.ietf-ecrit-requirements]
SIP B2BUA see [RFC3261] SIP B2BUA: see [RFC3261]
SIP proxy: see [RFC3261]. SIP proxy: see [RFC3261]
SIP Server see [RFC3261] SIP Server: see [RFC3261]
SIP UA (user agent): see [RFC3261]. SIP UA (user agent): see [RFC3261]
Stationary device (user): An immobile user agent that is connected Stationary device (user): An immobile user agent that is connected
to the network at a fixed, long-term-stable geographic location. to the network at a fixed, long-term-stable geographic location.
Examples include a home PC or a payphone. Examples include a home PC or a payphone.
Nomadic device (user): User agent that is connected to the network Nomadic device (user): User agent that is connected to the network
temporarily, for relatively short durations, but does not move temporarily, for relatively short durations, but does not move
significantly during the lifetime of a network connection or significantly during the lifetime of a network connection or
during the emergency call. Examples include a laptop using an during the emergency call. Examples include a laptop using an
802.11 hotspot or a desk IP phone that is moved from one cubicle IEEE 802.11 hotspot or a desk IP phone that is moved from one
to another. cubicle to another.
Mobile device (user): User agent that changes geographic location Mobile device (user): User agent that changes geographic location
and possibly its network attachment point during an emergency and possibly its network attachment point during an emergency
call. call.
2. Introduction 2. Introduction
Summoning police, the fire department or an ambulance in emergencies Summoning police, the fire department or an ambulance in emergencies
is one of the fundamental and most-valued functions of the telephone. is one of the fundamental and most-valued functions of the telephone.
As telephone functionality moves from circuit-switched telephony to As telephone functionality moves from circuit-switched telephony to
Internet telephony, its users rightfully expect that this core Internet telephony, its users rightfully expect that this core
skipping to change at page 5, line 26 skipping to change at page 5, line 22
the older technology. New devices and services are being made the older technology. New devices and services are being made
available which could be used to make a request for help which are available which could be used to make a request for help which are
not traditional telephones, and users are increasingly expecting them not traditional telephones, and users are increasingly expecting them
to be used to place emergency calls. However, many of the technical to be used to place emergency calls. However, many of the technical
advantages of Internet multimedia require re-thinking of the advantages of Internet multimedia require re-thinking of the
traditional emergency calling architecture. This challenge also traditional emergency calling architecture. This challenge also
offers an opportunity to improve the operation of emergency calling offers an opportunity to improve the operation of emergency calling
technology, while potentially lowering its cost and complexity. technology, while potentially lowering its cost and complexity.
It is beyond the scope of this document to enumerate and discuss all It is beyond the scope of this document to enumerate and discuss all
the differences between traditional (PSTN) and Internet telephony, the differences between traditional (PSTN) and IP based telephony,
but the core differences can be summarized as: but calling on the Internet is characterized by:
o the separation/interleaving of signaling and media data packets; o the interleaving of signaling and media data packets;
o the interleaving over the same infrastructure of what is an o the interleaving over the same infrastructure of a wider variety
emergency call with non-emergency traffic, whether that other of services;
traffic is another type of call or other Internet-based traffic o the separation of the access provider from the application
such as email or web browsing provider;
o the emergence of application-independent carriers;
o the plethora of different media that can be accommodated; o the plethora of different media that can be accommodated;
o potential mobility of all end systems, including endpoints o potential mobility of all end systems, including endpoints
nominally thought of as fixed systems and not just those using nominally thought of as fixed systems and not just those using
radio access technology. For example, a wired phone connected to radio access technology. For example, a wired phone connected to
a router using a mobile data network such as EV-DO as an uplink; a router using a mobile data network such as EV-DO as an uplink;
This document focuses on how devices using the Internet can place This document focuses on how devices using the Internet can place
emergency calls and how PSAPs can natively handle Internet multimedia emergency calls and how PSAPs can handle Internet multimedia
emergency calls, rather than describing how circuit-switched PSAPs emergency calls natively, rather than describing how circuit-switched
can handle VoIP calls. In many cases, PSAPs making the transition PSAPs can handle VoIP calls. In many cases, PSAPs making the
from circuit-switched interfaces to packet-switched interfaces may be transition from circuit-switched interfaces to packet-switched
able to use some of the mechanisms described here, in combination interfaces may be able to use some of the mechanisms described here,
with gateways that translate packet-switched calls into legacy in combination with gateways that translate packet-switched calls
interfaces, e.g., to continue to be able to use existing call taker into legacy interfaces, e.g., to continue to be able to use existing
equipment. call taker equipment.
We distinguish an individual request for help, usually accomplished We distinguish an individual request for help, usually accomplished
by dialing a short digit sequence like 9-1-1 or 1-1-2 from a call by dialing a short digit sequence like 9-1-1 or 1-1-2, from a call
placed by specially designated persons who have authority to claim placed by specially designated persons who have authority to claim
priority on available Internet communications facilities. This priority on available Internet communications facilities. This
document only discusses the former - a request for help by an document only discusses a request for help by an ordinary user
ordinary user answered at an emergency call center (i.e. a PSAP). answered at an emergency call center (i.e. a PSAP).
Existing emergency call systems are organized locally/nationally; Existing emergency call systems are organized locally or nationally;
there are currently no international standards. However, the there are currently no international standards. However, the
Internet does not respect national boundaries, and thus international Internet crosses national boundaries, and thus international
standards for equipment and software are required. To further standards for equipment and software are required. To further
complicate matters, VoIP endpoints can be connected through tunneling complicate matters, VoIP endpoints can be connected through tunneling
mechanisms such as virtual private networks (VPNs). This mechanisms such as virtual private networks (VPNs). This
significantly complicates emergency calling, because the location of significantly complicates emergency calling, because the location of
the caller and the first element that routes emergency calls can be the caller and the first element that routes emergency calls can be
on different continents, with different conventions and processes for on different continents, with different conventions and processes for
handling of emergency calls. handling of emergency calls.
The IETF has historically refused to create national variants of its The IETF has historically refused to create national variants of its
standards. Thus, this document attempts to take into account best standards. Thus, this document attempts to take into account best
practices that have evolved for circuit switched PSAPs, but makes no practices that have evolved for circuit switched PSAPs, but makes no
assumptions on particular operating practices currently in use, assumptions on particular operating practices currently in use,
numbering schemes or organizational structures. numbering schemes or organizational structures.
This document discusses the use of the Session Initiation Protocol This document discusses the use of the Session Initiation Protocol
(SIP) [RFC3261] by PSAPs and calling parties. While other inter- (SIP) [RFC3261] by PSAPs and calling parties. While other inter-
domain call signaling protocols may be used for emergency calling, domain call signaling protocols may be used for emergency calling,
SIP is ubiquitous and possesses, through its related specifications, SIP is ubiquitous and possesses, through its related specifications
more of the needed features for the proper support of this use case. the proper support of this use case. Only protocols such as H.323,
Only protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable XMPP/Jingle, ISUP and SIP are suitable for inter-domain
for inter-domain communications, ruling out MG/MGC protocols such as communications, ruling out MGC protocols such as MGCP or H.248/
MGCP or H.248/Megaco. The latter protocols can naturally be used by Megaco. The latter protocols can naturally be used by the enterprise
the enterprise or carrier placing the call, but any such call would or carrier placing the call, but any such call would reach the PSAP
reach the PSAP through a media gateway controller, similar to how through a media gateway controller, similar to how interdomain VoIP
interdomain VoIP calls would be placed. Other signaling protocols calls would be placed. Other signaling protocols may also use
may also use protocol translation to communicate with a SIP-enabled protocol translation to communicate with a SIP-enabled PSAP.
PSAP.
Existing emergency services rely exclusively on voice and Existing emergency services rely exclusively on voice and
conventional text telephony (known as TTY in the United States) media conventional text telephony ("TTY") media streams. However, more
streams. However, more choices of media offer additional ways to choices of media offer additional ways to communicate and evaluate
communicate and evaluate the situation as well as to assist callers the situation as well as to assist callers and call takers in
and call takers to handle emergency calls. For example, instant handling emergency calls. For example, instant messaging and video
messaging and video could improve the ability to communicate and could improve the ability to communicate and evaluate the situation
evaluate the situation and to provide appropriate instruction prior and to provide appropriate instruction prior to arrival of emergency
to arrival of emergency crews. Thus, the architecture described here crews. Thus, the architecture described here supports the creation
supports the creation of sessions of any media type, negotiated of sessions of any media type, negotiated between the caller and PSAP
between the caller and PSAP using existing SIP protocol mechanisms using existing SIP protocol mechanisms [RFC3264]. To ensure that,
[RFC3264]. To ensure that at least one common means of [I-D.ietf-ecrit-phonebcp] recommends certain minimal capabilities in
communications, this document recommends certain minimal capabilities that call taker user agents and PSAP-operated proxies should possess.
in [I-D.ietf-ecrit-phonebcp] that call taker user agents and PSAP-
operated proxies should possess.
This document does not prescribe the detailed network architecture
for a PSAP or collection of PSAPs. For example, it does not describe
where PSAPs may place firewalls or how many SIP proxies they should
use.
This document does not introduce any new SIP header fields, request Supporting emergency calling does not require any new SIP header
methods, status codes, message bodies, or event packages. User fields, request methods, status codes, message bodies, or event
agents unaware of the recommendations in this draft can place packages. User agents unaware of the recommendations in this draft
emergency calls, but may not be able to provide the same elevated may be able to place emergency calls, but functionality may be
user interface functionality. The document suggests behavior for impared. For example, if the UA does not implement the location
proxy servers, in particular outbound proxy servers. mechanisms described, an emergency call may not be routed to the
correct PSAP, and if the caller is unable to supply his exact
location, response may be delayed. Suggested behavior for both
endpoints and servers is provided
3. Overview of How Emergency Calls are Placed 3. Overview of How Emergency Calls are Placed
We distinguish (Section 4) an emergency call from any other call by a We distinguish (Section 4) an emergency call from any other call by a
unique Service URN[I-D.ietf-ecrit-service-urn], which is placed in unique Service URN[I-D.ietf-ecrit-service-urn], which is placed in
the initial call set-up signaling when a home or visited emergancy the initial call set-up signaling when a home or visited emergency
dialstring is detected. We route emergency calls based on the dialstring is detected. We route emergency calls based on the
location ( (Section 5)) of the caller. To get this location we location ( (Section 5)) of the caller. To get this location we
either include a form of measuring (e.g. GPS) ( (Section 5.3.3)) either include a form of measuring (e.g. GPS) ( (Section 5.3.3))
device location in the endpoint, or the endpoint is configured ( device location in the endpoint, or the endpoint is configured (
(Section 5.5)) with its location from the access network's Location (Section 5.5)) with its location from the access network's Location
Information Server (LIS) The location is conveyed ( (Section 5.6)) in Information Server (LIS) The location is conveyed ( (Section 5.6)) in
the SIP signaling with the call. We route( (Section 6)) the call the SIP signaling with the call. We route( (Section 6)) the call
based on location using the LoST protocol ( [I-D.ietf-ecrit-lost]) based on location using the LoST protocol ( [I-D.ietf-ecrit-lost])
which maps a location to a set of PSAP URIs. Each URI resolves to a which maps a location to a set of PSAP URIs. Each URI resolves to a
PSAP or an Emergency Services Routing Proxy which serves a group of PSAP or an Emergency Services Routing Proxy which serves a group of
skipping to change at page 8, line 41 skipping to change at page 8, line 41
+-------+ +-------+
Figure 1: Generic ECRIT Component Topology Figure 1: Generic ECRIT Component Topology
Figure 2 shows a generic emergency call establishment. This includes Figure 2 shows a generic emergency call establishment. This includes
the following: the following:
o Alice - who will make the emergency call. o Alice - who will make the emergency call.
o Configuration Servers - Servers providing Alice's UA its IP o Configuration Servers - Servers providing Alice's UA its IP
address and other configuration information, perhaps including address and other configuration information, perhaps including
Location by-value or by-reference. In this flow, we use DHCP as Location by-value or by-reference. In this flow, we use DHCP as
an example location acquisition protocol. Configuration servers an example location configuration protocol. Configuration servers
also may include a SIP Registrar server, for Alice's UA to also may include a SIP Registrar server, for Alice's UA to
register Alice's UA to register with. Most SIP UAs will register register Alice's UA to register with. Most SIP UAs will register
with a call server, so it will be a common scenario for UAs that with a call server, so it will be a common scenario for UAs that
make emergency calls to be registered with such a server in the make emergency calls to be registered with such a server in the
originating calling network. All these configuration messages are originating calling network. Registration would be required for
labeled M1 through M3, but could easily require more messages than the PSAP to be able to call back after an emergency call is
4 to complete. completed. All the configuration messages are labeled M1 through
M3, but could easily require more messages than 4 to complete.
o ESRP - The Emergency Services Routing Proxy Server that is the o ESRP - The Emergency Services Routing Proxy Server that is the
incoming call proxy in the emergency services domain. The ESRP incoming call proxy in the emergency services domain. The ESRP
makes further routing decisions based on PSAP state and location makes further routing decisions based on PSAP state and location
of the caller to choose the actual PSAP which handles the call. of the caller to choose the actual PSAP which handles the call.
In some jurisdictions, that may involve another LoST dip In some jurisdictions, that may involve another LoST query
o LoST Server - Processes the LoST request for Location to PSAP-URI o LoST Server - Processes the LoST request for Location + Service
Mapping function, either for an initial request from a UA, or an URN to PSAP-URI Mapping function, either for an initial request
in-call routing by the Proxy server in the originating network, or from a UA, or an in-call routing by the Proxy server in the
possibly by an ESRP. originating network, or possibly by an ESRP.
o PSAP - Call center where emergency calls are destined for in times o PSAP - Call center where emergency calls are destined for in times
of emergencies. of emergencies.
Generally, Alice's UA either has location configured manually, has an Generally, Alice's UA either has location configured manually, has an
integral location measurement mechanism, or it runs a location integral location measurement mechanism, or it runs a location
configuration protocol to obtain location from the access (broadband) configuration protocol to obtain location from the access (broadband)
network. For most devices, an LCP will be used, for example a network. For most devices, a location configuration protocol will be
DHCPREQUEST message or another location acquisition mechanism. used, for example a DHCPREQUEST message or another location
Alice's UA then will most likely register with a SIP domain. This acquisition mechanism. Alice's UA then will most likely register
allows her to be contacted by other SIP entities. Next, her UA will with a SIP domain. This allows her to be contacted by other SIP
perform an initial LoST Location-to-PSAP SIP(S)-URI query to learn a entities. Next, her UA will perform an initial LoST Location-to-PSAP
URI, for use if the Lost Query fails during an emergency call. The SIP(S)-URI query to learn a URI, for use if the Lost Query fails
LoST query may contain the dialstring for emergency calls appropriate during an emergency call or to use it to test the emergency call
for the location provided. mechanism. The LoST query may contain the dial string for emergency
calls appropriate for the location provided.
Some time has hopefully passed since Alice's UA booted. In this Some time has hopefully passed since Alice's UA booted. In this
example, she dials or initiates an emergency call. This may have example, she dials or initiates an emergency call. This may have
been through her keypad with her locally known emergency dialstring. been through her keypad with her locally known emergency dialstring.
It is important that this dialstring be recognized by her UA wherever It is important that this dial string be recognized by her UA
Alice is because she may be in enough distress she forgets what the wherever Alice is because she may be in enough distress she forgets
traveled-to emergency dialstring is; as there are more than 60 around what the traveled-to emergency dial string is; as there are more than
the world. 60 around the world.
The UA recognizes the dialstring, which means this is an emergency The UA recognizes the dialstring, which means this is an emergency
call. The UA attempts to refresh its location, and with that call. The UA attempts to refresh its location, and with that
location, the LoST mapping, to get the most accurate information to location, the LoST mapping, to get the most accurate information to
use for routing the call. If the location request or the LoST use for routing the call. If the location request or the LoST
request fails (or takes too long) the UA uses it's cached values. request fails (or takes too long) the UA uses it's cached values.
The UA creates an INVITE which includes the location. The UA creates an INVITE which includes the location.
[I-D.ietf-sip-location-conveyance] defines a SIP Location header that [I-D.ietf-sip-location-conveyance] defines a SIP Location header that
either contain the location-by-reference URI, or a [RFC2396] "cid:" either contain the location-by-reference URI, or a [RFC2396] "cid:"
indicating where in the message body the location-by-value is. indicating where in the message body the location-by-value is.
The INVITE message routes to the ESRP, which is the first inbound The INVITE message routes to the ESRP, which is the first inbound
proxy for the emergency services domain. This message, is then proxy for the emergency services domain. This message, is then
routed by the ESRP towards the most current PSAP for Alice's routed by the ESRP towards the most current PSAP for Alice's
location, which uses PSAP state, location and other state information location, which uses PSAP state, location and other state information
to choose this PSAP. to choose this PSAP.
A proxy in the PSAP choses an available call taker and extends the A proxy in the PSAP chooses an available call taker and extends the
call to its UA. call to its UA.
The 200 OK to the INVITE traverses the path in reverse, from call The 200 OK to the INVITE traverses the path in reverse, from call
taker UA to PSAP proxy to ESRP to originating network proxy to taker UA to PSAP proxy to ESRP to originating network proxy to
Alice's UA. The ACK completes the call set-up and the emergency call Alice's UA. The ACK completes the call set-up and the emergency call
is established, allowing the PSAP call-taker to talk to Alice about is established, allowing the PSAP call-taker to talk to Alice about
her emergency. her emergency.
Configuration LoST Configuration LoST
Alice Servers ESRP Server PSAP Alice Servers ESRP Server PSAP
skipping to change at page 11, line 43 skipping to change at page 12, line 39
intermediary (proxy server). For devices that are mobile or nomadic, intermediary (proxy server). For devices that are mobile or nomadic,
an issue arises of whether the home or visited dialing strings should an issue arises of whether the home or visited dialing strings should
be used. Many users would prefer that their home dialing sequences be used. Many users would prefer that their home dialing sequences
work no matter where they are. Local laws and preferences of the work no matter where they are. Local laws and preferences of the
emergency response professionals are such that the visited dialing emergency response professionals are such that the visited dialing
sequences must always work. Having the home dialstring work is sequences must always work. Having the home dialstring work is
optional. The best answer seems to be for both to work. optional. The best answer seems to be for both to work.
The mechanism for obtaining the dialing sequences for a given The mechanism for obtaining the dialing sequences for a given
location is provided by LoST [I-D.ietf-ecrit-lost]. Where the location is provided by LoST [I-D.ietf-ecrit-lost]. Where the
endpoint does not support the translation of dialstrings to telephone endpoint does not support the translation of dial strings to
numbers, the dialing sequence would be represented as a dialstring telephone numbers, the dialing sequence would be represented as a
[I-D.rosen-iptel-dialstring] and the outgoing proxy would recognize dial string [I-D.rosen-iptel-dialstring] and the outgoing proxy would
the dialstring and translate to the service URN. It should be noted recognize the dial string and translate to the service URN. To
that the endpoint would not normally supply location unless it determine the local dial string, the proxy needs the location of the
understood the call to be an emergency call. To determine the local endpoint. This may be difficult in situations where the user can
dialstring, the proxy needs the location of the endpoint. This may roam or be nomadic. Endpoint recognition of emergency dial strings
be difficult in situations where the user can roam or be nomadic. is therefore preferred.
Endpoint recognition of emergency dialstrings is therefore preferred.
5. Location and Its Role in an Emergency Call 5. Location and Its Role in an Emergency Call
5.1. Introduction 5.1. Introduction
Caller location plays a central role in routing emergency calls. For Caller location plays a central role in routing emergency calls. For
practical reasons, each PSAP generally handles only calls for a practical reasons, each PSAP generally handles only calls for a
certain geographic area (overload arrangements between PSAPs to certain geographic area (overload arrangements between PSAPs to
handle each others calls notwithstanding). Other calls that reach it handle each others calls notwithstanding). Other calls that reach it
by accident must be manually re-routed (transferred) to the by accident must be manually re-routed (transferred) to the
skipping to change at page 12, line 36 skipping to change at page 13, line 32
PSAP service boundaries, not "closest" or "best fit" algorithms. PSAP service boundaries, not "closest" or "best fit" algorithms.
5.2. Types of Location Information 5.2. Types of Location Information
There are four primary types of location information: civic, postal, There are four primary types of location information: civic, postal,
geospatial, and cellular cell tower and sector. geospatial, and cellular cell tower and sector.
Civic: Civic location information describes the location of a person Civic: Civic location information describes the location of a person
or object by a street address that corresponds to a building or or object by a street address that corresponds to a building or
other structure. (This is sometimes also called "civil" location other structure. (This is sometimes also called "civil" location
information.) Civic location may include more finer grained information.) Civic location may include more finely grained
location information such as floor, room, cubicle. Civic location information such as floor, room and cubicle. Civic
information comes in two forms: information comes in two forms:
Jurisdictional - This refers to a civic location using actual Jurisdictional - This refers to a civic location using actual
political subdivisions, especially for the community name. political subdivisions, especially for the community name.
Postal - This refers to a civic location used to mail a letter Postal - This refers to a civic location used to mail a letter
to. The name of the post office sometimes does not correspond to. The name of the post office sometimes does not correspond
to the actual community name and a postal addrress may contain to the actual community name and a postal address may contain
post office boxes or street addresses that do not correspond to post office boxes or street addresses that do not correspond to
an actual building. Postal addresses are generally unsuitable an actual building. Postal addresses are generally unsuitable
for emergency call routing, but may be the only address for emergency call routing, but may be the only address
available. available.
Geospatial: Geospatial addresses contain longitude, latitude and Geospatial: Geospatial addresses contain longitude, latitude and
altitude information based on an understood datum (starting point) altitude information based on an understood datum (starting point)
and earth shape model. While there have been many datums and earth shape model. While there have been many datum developed
developed over time, most modern systems are using or moving over time, most modern systems are using or moving towards the
towards WGS84. [WGS84] datum.
Cell tower/sector: Cell tower and sectors identify the cell tower Cell tower/sector: Cell tower and sectors identify the cell tower
and the antenna sector that the mobile device is currently using. and the antenna sector that the mobile device is currently using.
Traditionally, the tower location is expressed as a point, and Traditionally, the tower location is expressed as a point, and
routing decisions are made on that point. Cell/sector information routing decisions are made on that point. Cell/sector information
could also be transmitted as an irregularly shaped polygon of could also be transmitted as an irregularly shaped polygon of
geospatial coordinates reflecting the likely geospatial location geospatial coordinates reflecting the likely geospatial location
of the mobile device. of the mobile device.
In IETF protocols, civic and geo forms are both supported. The civic In IETF protocols, civic and geo forms are both supported. The civic
forms include both the postal and jurisdictional fields. The cell forms include both the postal and jurisdictional fields. The cell
skipping to change at page 13, line 39 skipping to change at page 14, line 34
In some cases, an entity may have multiple sources of location In some cases, an entity may have multiple sources of location
information, possibly partially contradictory. This is particularly information, possibly partially contradictory. This is particularly
likely if the location information is determined both by the end likely if the location information is determined both by the end
system and a third party. Handling multiple locations is discussed system and a third party. Handling multiple locations is discussed
in [I-D.ietf-geopriv-pdif-lo-profile]. Conflicting location in [I-D.ietf-geopriv-pdif-lo-profile]. Conflicting location
information is particularly harmful if it points to multiple distinct information is particularly harmful if it points to multiple distinct
PSAPs. Guidelines for dealing with multiple locations is also given PSAPs. Guidelines for dealing with multiple locations is also given
in [I-D.ietf-ecrit-lost]. in [I-D.ietf-ecrit-lost].
All location objects MUST be delivered to the PSAP. To facilitate All location objects MUST be delivered to the PSAP. Location
such policy decisions, location information should contain information should contain information about the source of data, such
information about the source of data, such as GPS, manually entered as GPS, manually entered or based on access network topology. In
or based on access network topology. In addition, the generator of addition, the source of the location information should be included
the location information should be included. The ability of the UA (PIDF "provided-by"). The ability of the UA to understand how it
to understand how it learned its location, and include this learned its location, and include this information element in the
information element in the location object that is sent to the PSAP, location object that is sent to the PSAP, provides the call-taker
provides the call-taker with many pieces of information to make with many pieces of information to make decisions upon, and guidance
decisions upon, and guidance for what to ask the caller and what to for what to ask the caller and what to tell the responders.
tell the responders.
The call should indicate which location information has been used for The call should indicate which location information has been used for
routing, so that the same location information is used for all call routing, so that the same location information is used for all call
routing decisions. Otherwise, two proxies might pick different routing decisions. Otherwise, two proxies might pick different
location information from the call request, resulting in different location information from the call request, resulting in different
routing decisions for different transactions. The location routing decisions for different transactions. The location
conveyance mechanism [I-D.ietf-ecrit-lost] contains a parameter which conveyance mechanism [I-D.ietf-sip-location-conveyance] contains a
can be used for this purpose parameter which can be used for this purpose
End systems and network elements can derive location information from End systems and network elements can derive location information from
a variety of sources. It is not the goal of this document to a variety of sources. It is not the goal of this document to
exhaustively enumerate them, but we provide a few common examples in exhaustively enumerate them, but we provide a few common examples in
the sections below. the sections below.
5.3.1. User-Entered Location Information 5.3.1. User-Entered Location Information
Location information can be maintained by the end user or the Location information can be maintained by the end user or the
installer of an endpoint in the endpoint itself, or in a database. installer of an endpoint in the endpoint itself, or in a database.
skipping to change at page 15, line 8 skipping to change at page 15, line 50
Location information can be maintained by the access network, Location information can be maintained by the access network,
relating some form of identifier for the end subscriber or device to relating some form of identifier for the end subscriber or device to
a location database ("wire database"). In enterprise LANs, wiremap a location database ("wire database"). In enterprise LANs, wiremap
databases map Ethernet switch ports to building layouts at known databases map Ethernet switch ports to building layouts at known
locations. In DSL installations, the local telephone carrier locations. In DSL installations, the local telephone carrier
maintains a mapping of wire-pairs to subscriber addresses. maintains a mapping of wire-pairs to subscriber addresses.
Even for IEEE 802.11 wireless access points, wire databases may Even for IEEE 802.11 wireless access points, wire databases may
provide sufficient location resolution; the location of the access provide sufficient location resolution; the location of the access
point may be sufficient location information for each of the clients point may be sufficient location information for each of the clients
served by that access point. This may be the connectivity type for served by that access point. However, this may not be true for
both residential users of DSL and Cable Modem installations, as well larger scale systems such as IEEE 802.16 and IEEE 802.22 which
as the only infrastructure at a WiFi hotspot, such as a coffee shop. typically have larger cells than those of IEEE 802.11. A Wire
database may be the source of location information for both
residential users of DSL and Cable Modem installations, as well as
the only infrastructure at a WiFi hotspot, such as a coffee shop.
Each of these cases will have a known civic address of the dwelling/ Each of these cases will have a known civic address of the dwelling/
business, likely providing sufficient location resolution. business, likely providing sufficient location resolution. However,
the civic location of an IEEE 802.16 base station may be of little
use to emergency personnel
Wire databases to the home are likely to be the most promising Wire databases to the home are likely to be the most promising
solution for residential users where a service provider knows the solution for residential users where a service provider knows the
customer's service address. The service provider can then perform customer's service address. The service provider can then perform
address verification, similar to the current system in some address verification, similar to the current system in some
jurisdictions. jurisdictions.
5.3.3. End-System Measured Location Information 5.3.3. End-System Measured Location Information
Global Positioning System (GPS) sensors may be embedded directly in Global Positioning System (GPS) sensors may be embedded directly in
the end device. GPS produces relatively high precision location the end device. GPS produces relatively high precision location
fixes in open-sky conditions, but the technology still faces several fixes in open-sky conditions, but the technology still faces several
challenges in terms of performance (time-to-fix and time-to-first- challenges in terms of performance (time-to-fix and time-to-first-
fix), as well as obtaining successful location fixes within shielded fix), as well as obtaining successful location fixes within shielded
structures, or underneath the ground (tunnels, basements, etc.). It structures, or underneath the ground (tunnels, basements, etc.). It
also requires all devices to be equipped with the appropriate GPS also requires all devices to be equipped with the appropriate GPS
capability. GPS technology is improving, and is increasingly capability. GPS technology is improving (e.g. Galileo), and is
successful in more difficult conditions such as dense urban canyons increasingly successful in more difficult conditions such as dense
and inside commercial structures. It is currently accurate to tens urban canyons and inside commercial structures. It is currently
of meters using some kind of "assist", which may be operated by the accurate to tens of meters using some kind of "assist", which may be
access network (A-GPS) or by a government (WAAS). Newer multi- operated by the access network (A-GPS) or by a government (WAAS).
frequency systems will improve accuracy without assist. Newer multi-frequency systems will improve accuracy without assist.
GPS equipped devices vary depending on which element initiates GPS equipped devices vary depending on which element initiates
requests, which element actually determines final location, assist requests, which element actually determines final location, assist
mechanisms, etc. Some common implementations include: mechanisms, etc. Some common implementations include:
1. GPS S/A (standalone), device initiated 1. GPS S/A (standalone), device initiated
2. GPS S/A, network initiated 2. GPS S/A, network initiated
3. AGPS-device initiated, network determined 3. AGPS-device initiated, network determined
4. AGPS-device initiated, network augmented 4. AGPS-device initiated, network augmented
5. AGPS-network initiated, network determined 5. AGPS-network initiated, network determined
6. AGPS-network initiated, network augmented 6. AGPS-network initiated, network augmented
skipping to change at page 16, line 29 skipping to change at page 17, line 29
Location information may be expressed as the actual civic or geo Location information may be expressed as the actual civic or geo
value but can be transmitted as by-value (wholly contained within the value but can be transmitted as by-value (wholly contained within the
signaling message) or by-reference (a URI pointing to the value signaling message) or by-reference (a URI pointing to the value
residing on a remote node waiting to be dereferenced). There are residing on a remote node waiting to be dereferenced). There are
pros and cons to each form: pros and cons to each form:
location-by-value: location-by-value:
pro- Value available to each device along the path immediately pro- Value available to each device along the path immediately
for further processing. for further processing.
con- Size, especially if constrained to a UDP transport. Value con- Size, especially if constrained to a UDP transport. Value
fixed at the time the value is acquired from the access fixed at the time the value is acquired from the access
network. Value can be changed by endpoint, which may be network. Value can be changed by the endpoint, which may be
considered untrustworthy for this critical usage. considered untrustworthy for this critical usage.
location-by-reference location-by-reference
pro- Small size. Value can be fixed at time of dereference. pro- Small size. Value can be fixed at time of dereference.
Value cannot be changed by endpoint Value cannot be changed by endpoint
con- URI resolution requires location source be available and con- URI resolution requires location source be available and
accessible by dereferencer. Dereferencing takes time. accessible by dereferencer. Dereferencing takes time.
Dereferencing may fail. Dereferencing may fail.
5.5. End System Location Configuration 5.5. End System Location Configuration
Unless a user agent has access to provisioned or locally measured Unless a user agent has access to provisioned or locally measured
location information, it must obtain it from the access network. location information, it must obtain it from the access network.
There are several Location Configuration Protocols that can be used There are several Location Configuration Protocols (LCPs) that can be
for this purpose. used for this purpose.
DHCP can deliver civic [RFC4676] or geospatial [RFC3825] DHCP can deliver civic [RFC4676] or geospatial [RFC3825]
information. User agents would need to support both formats. information. User agents would need to support both formats.
Note that a user agent can use DHCP, via the DHCP REQUEST or Note that a user agent can use DHCP, via the DHCP REQUEST or
INFORM messages, even if it uses other means to acquire its IP INFORM messages, even if it uses other means to acquire its IP
address. address.
Insert reference to L7 acquisition protocol document> is another Insert reference to L7 acquisition protocol document> is another
choice. choice.
Link-Layer Discovery Protocol [LLDP]), with proposed extensions Link-Layer Discovery Protocol [LLDP]), with proposed extensions
[LLDP-MED], may also be used to deliver location information. [LLDP-MED], may also be used to deliver location information.
SUPL OASIS <insert reference> is yet another choice. SUPL OMA <insert reference> is yet another choice.
Other LCPs may be devised by other standards bodies. Each LCP has Other LCPs may be devised by other standards bodies. Each LCP has
limitations in the kinds of networks that can reasonably support it. limitations in the kinds of networks that can reasonably support it.
For this reason, it is not possible to choose a single mandatory to For this reason, it is not possible to choose a single mandatory to
deploy LCP. For endpoints with common network connections (such as deploy LCP. For endpoints with common network connections (such as
an Ethernet jack or a WiFi connection), unless every network an Ethernet jack or a WiFi connection), unless every network
supported every protocol, or alternatively, every device supported supported every protocol, or alternatively, every device supported
every protocol, serious incompatibilities would ensue. every protocol, serious incompatibilities would ensue.
[I-D.ietf-ecrit-lost] contains a (short) list of protocols such [I-D.ietf-ecrit-phonebcp] contains a (short) list of protocols such
devices must support. devices must support.
Where an access network can control the specification of EVERY Where an access network can control the specification of EVERY
endpoint that could make an emergency call that is directly connected endpoint that could make an emergency call that is directly connected
to the network, or indirectly connected (for example, a device on a to the network, or indirectly connected (for example, a device on a
LAN behind a network attachment unit), it may specify any protocol it LAN behind a network attachment unit), it may specify any protocol it
wishes for each endpoint. This is a very unusual case; nearly every wishes for each endpoint. This is a very unusual case; nearly every
access network can be used to support an Ethernet based LAN behind it access network can be used to support an Ethernet based LAN behind it
For example, existing mobile networks are being used to support For example, existing mobile networks are being used to support
routers and LANs behind a wireless data network WAN connection, with routers and LANs behind a wireless data network WAN connection, with
Ethernet connected phones connected to that. It is possible that the Ethernet connected phones connected to that. It is possible that the
access network supports a protocol not on the phonebcp list, and access network supports a protocol not on the phonebcp list, and
every handset supported in that network could use that protocol for every handset supported in that network could use that protocol for
emergency calls. However, unless another element which the access emergency calls. However, unless another element which the access
network provider controls the specification of can acquire location network provider controls the specification of can acquire location
using that protocol and then that element can support one of the using that protocol and then that element can support one of the
phonebcp's list of protocols, the Ethernt connected phone won't be phonebcp's list of protocols, the Ethernet connected phone won't be
able to acquire location. In this case, if the access network able to acquire location. In this case, if the access network
provider supplies a router which includes a DHCP server, it can provider supplies a router which includes a DHCP server, it can
acquire location using the access network specific protocol, and then acquire location using the access network specific protocol, and then
use the location information to supply it to its clients (e.g. the use the location information to supply it to its clients (e.g. the
Ethernet connected phone) via DHCP. Ethernet connected phone) via DHCP.
For most networks, it will not be practical to control the For most networks, it will not be practical to control the
specification of every device, or arrange interworking with network specification of every device, or arrange interworking with network
specific LCPs. For this reason, most devices will need to support specific LCPs. For this reason, most devices will need to support
ALL of the LCPs in [I-D.ietf-ecrit-lost], and access networks will ALL of the LCPs in [I-D.ietf-ecrit-lost], and access networks will
skipping to change at page 19, line 14 skipping to change at page 20, line 14
the initial call setup by an unacceptable amount of time. the initial call setup by an unacceptable amount of time.
In addition, the location of a mobile caller, e.g., in a vehicle or In addition, the location of a mobile caller, e.g., in a vehicle or
aircraft, can change significantly during the emergency call. The aircraft, can change significantly during the emergency call. The
PSAP must be able to get updated location information while it is PSAP must be able to get updated location information while it is
processing the call. processing the call.
Location updates where the location is conveyed by value may be Location updates where the location is conveyed by value may be
conveyed either in a re-INVITE or UPDATE [RFC3311] request message conveyed either in a re-INVITE or UPDATE [RFC3311] request message
(where UPDATE is preferred) or the PSAP may subscribe to the location (where UPDATE is preferred) or the PSAP may subscribe to the location
information of the caller, using SIP presence mechanisms (RFC 3265 information of the caller, using SIP presence mechanisms RFC 3856
[RFC3265] RFC 3856 [RFC3856]). Authorization for subscriptions is [RFC3856]). Authorization for subscriptions is for future study.
for future study. When location is conveyed by reference, additional When location is conveyed by reference, additional dereference
dereference operations yield updated location. operations yield updated location.
5.8. Location Validation 5.8. Location Validation
Location must be validated prior to a device placing an actual In some jurisdictions, location must be validated prior to a device
emergency call. Validation in this context means both that there is placing an actual emergency call, and is always a recommended
a mapping from the address to a PSAP and that the PSAP understands practice. Validation in this context means both that there is a
how to direct responders to the location. This is not as easy as it mapping from the address to a PSAP and that the PSAP understands how
to direct responders to the location. This is not as easy as it
sounds. There are, for example, many cases of two names for the same sounds. There are, for example, many cases of two names for the same
street, or two streets with the same name in a city. In some street, or two streets with the same name in a city. In some
countries, the current system provides validation. For example, in countries, the current system provides validation. For example, in
the United States, the Master Street Address Guide (MSAG) records all the United States, the Master Street Address Guide (MSAG) records all
valid street addresses and is used to ensure that the service valid street addresses and is used to ensure that the service
addresses in phone billing records correspond to valid emergency addresses in phone billing records correspond to valid emergency
service street addresses. Validation is normally a concern for civic service street addresses. Validation is normally a concern for civic
addresses, although there could be a concern that a given geo is addresses, although there could be a concern that a given geo is
within at least one PSAP service boundary; that is, a "valid" geo is within at least one PSAP service boundary; that is, a "valid" geo is
one for which there is a mapping. one for which there is a mapping.
The LoST resolver[I-D.ietf-ecrit-lost] includes a validation The LoST resolver[I-D.ietf-ecrit-lost] includes a validation
function. Validation should ideally be performed when a location is function. Validation should ideally be performed when a location is
entered into a Location Information Server (which is normally a entered into a Location Information Server (which is normally a
provisioning mechanism in the access carrier's operation and support provisioning mechanism in the access carrier's operation and support
system). It should be confirmed periodically, because the mapping system). It should be confirmed periodically, because the mapping
database undergoes slow change; new streets are added or removed, database undergoes slow change; new streets are added or removed,
community names change, postal codes change, etc. Endpoints may wish community names change, postal codes change, etc. Endpoints may wish
to validate locations they receive from the access network, and will to validate locations they receive from the access network, and will
need to validate manually entered locations. Proxies which insert need to validate manually entered locations. Proxies which insert
location may wish to validate locations they recieve from a LIS. location may wish to validate locations they receive from a LIS.
Test functions (Section 13) should also re-validate. Test functions (Section 13) should also re-validate.
5.9. Default Location 5.9. Default Location
Occasionally, a failure may occur where the access network cannot Occasionally, a failure may occur where the access network cannot
determine the actual location of the caller. In these cases, it must determine the actual location of the caller. In these cases, it must
supply a default location. The default location should be as supply a default location. The default location should be as
accurate as the network can determine. For example, in a cable accurate as the network can determine. For example, in a cable
network, a default location for each Cable Modem Termination System network, a default location for each Cable Modem Termination System
(CMTS), with a representative location for all cable modems served by (CMTS), with a representative location for all cable modems served by
that CMTS could be provided if the network is unable to resolve the that CMTS could be provided if the network is unable to resolve the
subscriber to any unit less than the CMTS. Default locations must be subscriber to any unit less than the CMTS. Default locations must be
marked as such (how?) so that the PSAP knows that the location is not marked as such (how?) so that the PSAP knows that the location is not
accurate. accurate.
5.10. Uninitialized Devices and Location
Support of devices that are not registered, and don't have valid call
back identifiers is complex. In some jurisdictions, for some
services, support of emergency calls from so called "uninitialized"
devices, for example, a mobile phone which does not have an active
service contract in the United States is required to support calls to
9-1-1. It is attractive for such devices to be able to be used in an
emergency. However, the requirement to do so has caused a huge
number of prank calls to the emergency service. In some countries,
it is common to attempt to place an emergency call from an
unitialized device in the local bazaars to prove to a would-be
purchaser that the phone works. An unitialized device that can place
an emergency call must supply location the same as a fully enabled
device.
6. Routing the Call to the PSAP 6. Routing the Call to the PSAP
Emergency calls are routed based on one or more of the following Emergency calls are routed based on one or more of the following
criteria expressed in the call setup request (INVITE): criteria expressed in the call setup request (INVITE):
Location: Since each PSAP serves a limited geographic region and Location: Since each PSAP serves a limited geographic region and
transferring existing calls delays the emergency response, calls transferring existing calls delays the emergency response, calls
need to be routed to the most appropriate PSAP. In this need to be routed to the most appropriate PSAP. In this
architecture, emergency call setup requests contain location architecture, emergency call setup requests contain location
information, expressed in civic or geospatial coordinates, that information, expressed in civic or geospatial coordinates, that
skipping to change at page 20, line 38 skipping to change at page 22, line 16
for fire, police, ambulance or mountain rescue are directed to for fire, police, ambulance or mountain rescue are directed to
just those emergency-specific PSAPs. We support this mechanism by just those emergency-specific PSAPs. We support this mechanism by
optionally labeling calls with a service identifier optionally labeling calls with a service identifier
[I-D.ietf-ecrit-service-urn]. [I-D.ietf-ecrit-service-urn].
Media capabilities of caller: In some cases, emergency call centers Media capabilities of caller: In some cases, emergency call centers
for specific caller media preferences, such as typed text or for specific caller media preferences, such as typed text or
video, are separate from voice systems. Also, even if media video, are separate from voice systems. Also, even if media
capability does not affect the selection of the PSAP, there may be capability does not affect the selection of the PSAP, there may be
call takers within the PSAP that are specifically trained, e.g., call takers within the PSAP that are specifically trained, e.g.,
in interactive text or sign language communications. Again, we in interactive text or sign language communications. Again, we
use the callee capabilities [RFC3840] mechanism to label and route use the caller capabilities [RFC3840] mechanism to label and route
such calls. such calls.
Routing for calls by location and by service is the primary function Routing for calls by location and by service is the primary function
LoST [I-D.ietf-ecrit-lost] provides. LoST accepts a query with LoST [I-D.ietf-ecrit-lost] provides. LoST accepts a query with
location (by-value) in either civic or geo form, plus a service location (by-value) in either civic or geo form, plus a service
identifier, and returns an xml data structure containing a URI (or identifier, and returns an xml data structure containing a URI (or
set of URIs) to route the call to. Normal SIP [RFC3261] routing set of URIs) to route the call to. Normal SIP [RFC3261] routing
functions are used to resolve the URI to a next hop destination. functions are used to resolve the URI to a next hop destination.
The endpoint can complete the LoST mapping from its location at boot The endpoint can complete the LoST mapping from its location at boot
time, and periodically thereafter. It should attempt to obtain a time, and periodically thereafter. It should attempt to obtain a
"fresh" location, and from that a current mapping when it places an "fresh" location, and from that a current mapping when it places an
emergency call, and if accessing either its location acquisition emergency call, and if accessing either its location acquisition
function or mapping function fails, it should use this cached value. function or mapping function fails, it should use this cached value.
The call would follow its normal outbound call processing. Networks The call would follow its normal outbound call processing. Networks
that support devices that do not implement LoST mapping themseleves that support devices that do not implement LoST mapping themselves
would have the outbound proxy do the mapping. The proxy must have would have the outbound proxy do the mapping. The proxy must have
the location of the endpoint, which is often difficult for the the location of the endpoint, which is often difficult for the
calling network to accurately determine. The endpoint may have its calling network to accurately determine. The endpoint may have its
location, but would not normally include it on the call signaling. location, but would not normally include it on the call signaling.
There is no mechanism provided in [I-D.ietf-sip-location-conveyance] There is no mechanism provided in [I-D.ietf-sip-location-conveyance]
to allow a proxy to require the endpoint supply location, because to allow a proxy to require the endpoint supply location, because
that would open the endpoint to an attack by any proxy on the path to that would open the endpoint to an attack by any proxy on the path to
get it to reveal location. The Proxy CAN redirect a call to the get it to reveal location. The Proxy CAN redirect a call to the
service URN which, if the device recognized the significance, would service URN which, if the device recognized the significance, would
include location in the redirected call. All networks should detect include location in the redirected call. All networks should detect
emergency calls and supply default location and/or routing if it is emergency calls and supply default location and/or routing if it is
not already performed. not already performed.
With the URI obtained from mapping, whether by the endpoint or the With the URI obtained from mapping, whether by the endpoint or the
proxy, the proxy routes the call. Normal SIP[RFC3261] mechanisms are proxy, the proxy routes the call. Normal SIP[RFC3261] mechanisms are
used to route calls to the URI obtained from the LoST dip. used to route calls to the URI obtained from the LoST query.
Often, the SIP routing of an emergency call will first route to an Often, the SIP routing of an emergency call will first route to an
incoming call proxy in the domain operated by the emergency service. incoming call proxy in the domain operated by the emergency service.
That proxy is called an "Emergency Services Routing Proxy" (ESRP). That proxy is called an "Emergency Services Routing Proxy" (ESRP).
The ESRP, which is a normal SIP proxy server, may use a variety of The ESRP, which is a normal SIP proxy server, may use a variety of
PSAP state information, the location of the caller, and other PSAP state information, the location of the caller, and other
criteria to onward route the call to the PSAP. criteria to onward route the call to the PSAP.
7. Signaling of Emergency Calls 7. Signaling of Emergency Calls
As discussed above, location is carried in all emergency calls in the As discussed above, location is carried in all emergency calls in the
call signaling. Since emergency calls carry privacy-sensitive call signaling. Since emergency calls carry privacy-sensitive
information, they are subject to the requirements for geospatial information, they are subject to the requirements for geospatial
protocols [RFC3693]. In particular, signaling information should be protocols [RFC3693]. In particular, signaling information should be
skipping to change at page 22, line 32 skipping to change at page 24, line 9
prematurely dropped. prematurely dropped.
In addition, a call-back identifier should be included either as the In addition, a call-back identifier should be included either as the
URI in the From header field [RFC3261] preferably verified by SIP URI in the From header field [RFC3261] preferably verified by SIP
Identity[RFC4474]. This identifier would be used to initiate a call- Identity[RFC4474]. This identifier would be used to initiate a call-
back at a later time and may reach the caller, not necessarily on the back at a later time and may reach the caller, not necessarily on the
same device (and at the same location) as the original emergency same device (and at the same location) as the original emergency
call. Both the Contact and From specific requirements are detailed call. Both the Contact and From specific requirements are detailed
in [I-D.ietf-ecrit-phonebcp] in [I-D.ietf-ecrit-phonebcp]
Emergency authorities generally discourage support of unitialized
devices (see Section 5.10. If an uninitialized device does place an
emergency call, some kind of call back URI must be provided.
Finally, there may be two other call identifiers included in an Finally, there may be two other call identifiers included in an
emergency call. An identifier may be included which can be used to emergency call. An identifier may be included which can be used to
identify the caller, as opposed to the device or the subscriber of a identify the caller, as opposed to the device or the subscriber of a
specific calling service. This identifier may be used to retrieve specific calling service. This identifier may be used to retrieve
information about the caller that is independent of calling service. information about the caller that is independent of calling service.
For example, Alice may have home, office and mobile telephony For example, Alice may have home, office and mobile telephony
services, but she is the same Alice in all of them. Information services, but she is the same Alice in all of them. Information
about Alice may be kept by an entity independent of any telephony about Alice may be kept by an entity independent of any telephony
service provider. The caller identity is a URI and is placed in a service provider. The caller identity is a URI and is placed in a
SIP Call-Info header [RFC3261] using the token "?" following the SIP Call-Info header [RFC3261] using the token "?" following the
skipping to change at page 23, line 12 skipping to change at page 24, line 38
the Call-Info header using the token "?" per the Call-Info header using the token "?" per
[I-D.ietf-ecrit-phonebcp]. [I-D.ietf-ecrit-phonebcp].
10. Mid-Call Services and Behavior 10. Mid-Call Services and Behavior
A PSAP may need to REFER[RFC3515] a call to a bridge for A PSAP may need to REFER[RFC3515] a call to a bridge for
conferencing. The caller should also be prepared to have the call conferencing. The caller should also be prepared to have the call
transferred (usually attended, but possibly blind) as transferred (usually attended, but possibly blind) as
per[I-D.ietf-sipping-service-examples]. per[I-D.ietf-sipping-service-examples].
While in a call, a number of of other call features, such as call While in a call, a number of other call features, such as call
waiting, must be disabled. This is also discussed in waiting, must be disabled. This is also discussed in
[I-D.ietf-ecrit-phonebcp]. [I-D.ietf-ecrit-phonebcp].
11. Call Termination 11. Call Termination
It is undesirable for the caller to terminate an emergency call. It is undesirable for the caller to terminate an emergency call.
Strategies for devices to handle caller attempts to terminate may be Strategies for devices to handle caller attempts to terminate may be
found in [I-D.ietf-ecrit-phonebcp]. PSAP call termination is found in [I-D.ietf-ecrit-phonebcp]. PSAP call termination is
accomplished with normal SIP call termination procedures. accomplished with normal SIP call termination procedures.
skipping to change at page 25, line 9 skipping to change at page 26, line 39
Connecting ANY service to the Internet creates threads to the service Connecting ANY service to the Internet creates threads to the service
which did not exist before. The emergency call service is especially which did not exist before. The emergency call service is especially
critical compared to other services lately connected to the Internet. critical compared to other services lately connected to the Internet.
It must work reliably even in case of a major disaster when thousands It must work reliably even in case of a major disaster when thousands
of citizens call for help simultaneously. Not only does the service of citizens call for help simultaneously. Not only does the service
need to be protected but also the liberties of the citizens who might need to be protected but also the liberties of the citizens who might
need to use the service must be considered. need to use the service must be considered.
The emergency service is an obvious target for a deliberate attack, The emergency service is an obvious target for a deliberate attack,
and specifially a denial of service attack. Mechanisms must be and specifically a denial of service attack. Mechanisms must be
provided to help the emergency networks survive such attacks while provided to help the emergency networks survive such attacks while
continuing to provide service to genuine callers. continuing to provide service to genuine callers.
Failure of any security mechanism should normally not prevent an Failure of any security mechanism should normally not prevent an
emergency call to be established. Unlike most systems, suspicious emergency call to be established. Unlike most systems, suspicious
calls (that is, those where normal security mechanisms are not calls (that is, those where normal security mechanisms are not
attempted or they fail to produce expected valid credentials) are attempted or they fail to produce expected valid credentials) are
normally not dropped, but are processed with the call taker made normally not dropped, but are processed with the call taker made
aware that the information given (location, for example), may not be aware that the information given (location, for example), may not be
accurate. As the discussion in Section 5 shows, providing accurate accurate. As the discussion in Section 5 shows, providing accurate
skipping to change at page 25, line 43 skipping to change at page 27, line 25
the call router and the policy of the PSAP and out of the scope of the call router and the policy of the PSAP and out of the scope of
this document. this document.
16.1. Caller Authentication 16.1. Caller Authentication
Fraudulent calls to PSAPs is a significant concern. Current systems Fraudulent calls to PSAPs is a significant concern. Current systems
rely on inherent security mechanisms in the PSTN to make sure the rely on inherent security mechanisms in the PSTN to make sure the
identity of the owner of the telephone is known. As Internet identity of the owner of the telephone is known. As Internet
technologies are increasingly used to place calls, it is becoming technologies are increasingly used to place calls, it is becoming
easier to hide the identity of a caller. Use of the SIP Identity easier to hide the identity of a caller. Use of the SIP Identity
mechanism [RFC4474] i is recommended. If SIP Identity cannot be mechanism [RFC4474] is recommended. If SIP Identity cannot be
provided, carriers should make use of P-Asserted-Identity, [RFC3325] provided, carriers should make use of P-Asserted-Identity, [RFC3325]
In keeping with established customs in circuit-switched emergency In keeping with established customs in circuit-switched emergency
calling, authentication cannot be made a prerequisite for routing or calling, authentication cannot be made a prerequisite for routing or
accepting an emergency call. However, a call taker may be more accepting an emergency call. However, a call taker may be more
suspicious of a caller and request additional information if the call suspicious of a caller and request additional information if the call
authenticity cannot be verified. authenticity cannot be verified.
16.2. Location Privacy 16.2. Location Privacy
skipping to change at page 27, line 38 skipping to change at page 29, line 21
Design Team members participating in this draft creation include Design Team members participating in this draft creation include
Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger
Marshall, Stu Goldman, Shida Schubert and Tom Taylor. Marshall, Stu Goldman, Shida Schubert and Tom Taylor.
18. References 18. References
18.1. Normative References 18.1. Normative References
[I-D.ietf-ecrit-lost] [I-D.ietf-ecrit-lost]
Hardie, T., "LoST: A Location-to-Service Translation Hardie, T., "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-04 (work in progress), Protocol", draft-ietf-ecrit-lost-05 (work in progress),
February 2007. March 2007.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-00 (work in progress), draft-ietf-ecrit-phonebcp-01 (work in progress),
October 2006. March 2007.
[I-D.ietf-ecrit-requirements] [I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-12 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
August 2006. March 2007.
[I-D.ietf-ecrit-service-urn] [I-D.ietf-ecrit-service-urn]
Schulzrinne, H., "A Uniform Resource Name (URN) for Schulzrinne, H., "A Uniform Resource Name (URN) for
Services", draft-ietf-ecrit-service-urn-05 (work in Services", draft-ietf-ecrit-service-urn-06 (work in
progress), August 2006. progress), March 2007.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations", Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-05 (work in progress), draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),
October 2006. July 2007.
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-11 (work in progress), (SIP)", draft-ietf-sip-gruu-14 (work in progress),
October 2006. June 2007.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Session Initiation Protocol Polk, J. and B. Rosen, "Session Initiation Protocol
Location Conveyance", Location Conveyance",
draft-ietf-sip-location-conveyance-07 (work in progress), draft-ietf-sip-location-conveyance-07 (work in progress),
February 2007. February 2007.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Petrie, D. and S. Channabasappa, "A Framework for Session Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-10 (work in progress), draft-ietf-sipping-config-framework-12 (work in progress),
January 2007. June 2007.
[I-D.rosen-iptel-dialstring] [I-D.rosen-iptel-dialstring]
Rosen, B., "Dialstring parameter for the Session Rosen, B., "Dialstring parameter for the Session
Initiation Protocol Uniform Resource Identifier", Initiation Protocol Uniform Resource Identifier",
draft-rosen-iptel-dialstring-05 (work in progress), draft-rosen-iptel-dialstring-05 (work in progress),
March 2007. March 2007.
[LLDP] "IEEE802.1ab Station and Media Access Control", Dec 2004. [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Dec 2004.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
skipping to change at page 29, line 25 skipping to change at page 31, line 6
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
[RFC3325] "", 2005. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
skipping to change at page 30, line 20 skipping to change at page 32, line 4
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4103] "", 2005. [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4474] "", 2005. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4676, October 2006. Configuration Information", RFC 4676, October 2006.
18.2. Informative References 18.2. Informative References
[I-D.ietf-sipping-service-examples] [I-D.ietf-sipping-service-examples]
Johnston, A., "Session Initiation Protocol Service Johnston, A., "Session Initiation Protocol Service
Examples", draft-ietf-sipping-service-examples-12 (work in Examples", draft-ietf-sipping-service-examples-12 (work in
progress), January 2007. progress), January 2007.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of
Defense World Geodetic System 1984, Its Definition and
Relationships With Local Geodetic Systems, Third Edition",
July 1997.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
Mars, PA 16046 Mars, PA 16046
US US
Email: br@brianrosen.net Email: br@brianrosen.net
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7042 Phone: +1 212 939 7042
Email: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
 End of changes. 70 change blocks. 
233 lines changed or deleted 263 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/