ecrit                                                           B. Rosen
Internet-Draft                                                   NeuStar
Intended status: Standards Track                          H. Schulzrinne
Expires: January 9, March 22, 2008                                      Columbia U.
                                                                 J. Polk
                                                           Cisco Systems
                                                               A. Newton
                                                               SunRocket
                                                           July 08,
                                                      TranTech/MediaSolv
                                                      September 19, 2007

       Framework for Emergency Calling using Internet Multimedia
                     draft-ietf-ecrit-framework-02
                     draft-ietf-ecrit-framework-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 9, March 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Summoning emergency help by the public is a core feature

   The IETF has several efforts targeted at standardizing various
   aspects of telephone
   networks. placing emergency calls.  This document describes how various IETF protocols and
   mechanisms all
   of those component parts are combined used to place support emergency calls.  This includes how
   these calls are routed to the correct Public Safety Answering Point
   (PSAP) based on the physical location of the caller, while providing
   the call taker the necessary information to dispatch a first
   responder to that location from
   citizens and visitors to call back the caller if necessary.
   It describes at a high level how the pieces (recognizing a call as an
   emergency call, marking it as such, determining the location of the
   caller, routing the call based on location) go together, and
   references the Internet standards that define the details of these
   mechanisms. authorities.

Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5  4
   3.  Overview of How Emergency Calls how emergency calls are Placed placed . . . . . . . . . .  7
   4.  Which devices and services should support  emergency calls . . 11
   5.  Identifying an Emergency Call emergency call  . . . . . . . . . . . . . . . . 12
   5. 11
   6.  Location and Its Role its role in an Emergency Call emergency call . . . . . . . . . . 12
     5.1.  Introduction 13
     6.1.  Types of location information  . . . . . . . . . . . . . . 14
     6.2.  Location Determination . . . . . . . . . 13
     5.2.  Types of Location Information . . . . . . . . . 16
       6.2.1.  User-entered location information  . . . . . 13
     5.3.  Location Determination . . . . . 16
       6.2.2.  Access network "wire database" location information  . 17
       6.2.3.  End-system measured location information . . . . . . . 17
       6.2.4.  Network measured location information  . . . . . 14
       5.3.1.  User-Entered Location Information . . . 18
     6.3.  Who adds location, endpoint or proxy . . . . . . . 15
       5.3.2.  Access Network "Wire Database" Location Information . 15
       5.3.3.  End-System Measured Location Information . . . 18
     6.4.  Location and references to location  . . . . 16
       5.3.4.  Third-party Measured Location Information . . . . . . 16
     5.4.  Location and References to Location . 19
     6.5.  End system location configuration  . . . . . . . . . . 17
     5.5.  End System Location Configuration . . 19
     6.6.  When location should be configured . . . . . . . . . . 17
     5.6.  Conveyance of Location . . 21
     6.7.  Conveying location in SIP  . . . . . . . . . . . . . . . . 19
     5.7. 22
     6.8.  Location Updates updates . . . . . . . . . . . . . . . . . . . . . 19
     5.8.  Location Validation 22
     6.9.  Multiple locations . . . . . . . . . . . . . . . . . . . 20
     5.9.  Default . 23
     6.10. Location validation  . . . . . . . . . . . . . . . . . . . . . 21
     5.10. Uninitialized Devices and Location . . . . . . . . . . . . 21
   6.  Routing the Call to the PSAP . . . . . . . . . . . . . . . . . 21
   7.  Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 23
   8.  Caller Preferences . . 23
     6.11. Default location . . . . . . . . . . . . . . . . . . . . 23
   9.  Including a Valid Call-Back Identifier . . . . . . . . . . . . 23
   10. Mid-Call Services and Behavior . . 24
     6.12. Other location considerations  . . . . . . . . . . . . . . 24
   11. Call Termination . . .
   7.  Uninitialized devices  . . . . . . . . . . . . . . . . . . . . 24
   12. Media  . . . . .
   8.  Routing the call to the PSAP . . . . . . . . . . . . . . . . . 25
   9.  Signaling of emergency calls . . . . . . 25
   13. Testing . . . . . . . . . . . 26
     9.1.  Use of TLS . . . . . . . . . . . . . . . . 25
   14. Example Call Flows . . . . . . . . 26
     9.2.  SIP signaling requirements for  User Agents  . . . . . . . 27
     9.3.  SIP signaling requirements for proxy servers . . . . . . . 25
   15. Alternatives Considered 27
   10. Call backs . . . . . . . . . . . . . . . . . . . 25
     15.1. tel URIs . . . . . . . 27
   11. Mid-call behavior  . . . . . . . . . . . . . . . . . . 26
   16. Security Considerations . . . . 28
   12. Call termination . . . . . . . . . . . . . . . 26
     16.1. Caller Authentication . . . . . . . . 28
   13. Disabling of features  . . . . . . . . . . 27
     16.2. Location Privacy . . . . . . . . . . 28
   14. Media  . . . . . . . . . . . 27
     16.3. PSAP Impersonation . . . . . . . . . . . . . . . . . 28
   15. Testing  . . . 28
     16.4. Preventing Call Misdirection . . . . . . . . . . . . . . . 28
     16.5. Call Signaling Integrity . . . . . . . . . 29
   16. Security Considerations  . . . . . . . . 28
     16.6. Media Integrity and Confidentiality . . . . . . . . . . . 28 29
   17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 30
   18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 30
     18.1. Normative References . . . . . . . . . . . . . . . . . . . 29 30
     18.2. Informative References . . . . . . . . . . . . . . . . . . 32 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 34 36

1.  Terminology

   As a framework document, we do not define any new protocols or
   articulate new behaviors.  Thus we do not use RFC2119 [RFC2119]
   notation.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document uses terms from [RFC3261] and
   [I-D.ietf-ecrit-requirements].  In addition the following terms are
   used:
   (Emergency) call taker:  see [I-D.ietf-ecrit-requirements]
   ESRP (emergency service routing proxy):  see
      [I-D.ietf-ecrit-requirements]
   Access Network: network:  The network that supplies IP packet service to an
      endpoint.  In a residential or small business environment, this
      might be a DSL or cable modem or WiMax service.  In a large
      enterprise environment, this would be the enterprise network.  In
      a mobile environment, this might be a mobile (cellular) data
      network or a WiFi network.
   Location Configuration: network
   (Emergency) Call taker:  The process by which person who answers an endpoint learns its
      physical location.
   Location Conveyance: emergency call at
      the PSAP
   Confidence  The mathematically derived statistical estimate
      indicating how sure the measuring system is that the location data
      estimate is accurate, within the bounds defined by the Uncertainty
      value.  This is expressed as a percentage, such as 90%, or 45%
      etc.
   Dispatch Location  Location used for dispatching responders to the
      person in need of assistance.  Must be precise as opposed to that
      needed for Routing Location.
   Emergency services routing proxy (ESRP):  A proxy server that
      provides routing services for a group of PSAPs
   Location configuration:  The process where an endpoint learns its
      physical location
   Location conveyance:  The process of sending location to another
      element.
      element
   Location Determination: determination:  The process of finding where an endpoint is
      physically.  For example, the endpoint may contain a GPS receiver
      used to measure its own location. location or location may be determined by
      administration using a wiremap database or similar
   Location Information Server: Server (LIS):  An element that stores location
      information for retrieval by an authorized entity
   Location Validation:  see [I-D.ietf-ecrit-requirements]
   Mapping:  see [I-D.ietf-ecrit-requirements]
   Mobile device:  User agent that changes geographic location and
      possibly its network attachment point during an emergency call
   NENA (National Emergency Number Association):  A North American
      organization of public safety focused individuals defining
      emergency calling specifications and procedures.
   PSAP (public safety answering point):  see
      [I-D.ietf-ecrit-requirements]
   SIP B2BUA:  see [RFC3261]
   SIP proxy:  see [RFC3261]
   SIP Server:  see [RFC3261]
   SIP UA (user agent):  see [RFC3261]
   Stationary device (user):  An immobile user agent that is connected
      to the network at a fixed, long-term-stable geographic location.
      Examples include a home PC or a payphone. procedures
   Nomadic device (user):  User agent that is connected to the network
      temporarily, for relatively short durations, but does not move
      significantly during the lifetime of a network connection or
      during the emergency call.  Examples include a laptop using an
      IEEE 802.11 hotspot or a desk IP phone that is moved from one
      cubicle to another.
   Mobile device (user):  User agent that changes geographic another
   Routing Location:  The location
      and possibly its network attachment point during of an endpoint that is used for
      routing an emergency call.

2.  Introduction

   Summoning police,  May not be as precise as the fire department Dispatch
      Location.
   Stationary device:  An immobile user agent that is connected to the
      network at a fixed, long-term-stable geographic location.
      Examples include a home PC or an ambulance a pay phone
   Uncertainty  The mathematically derived statistical estimate,
      expressed in emergencies
   is one of meters, indicating the fundamental and most-valued functions size of the telephone.
   As area used in the
      calculation of Confidence.

2.  Introduction

   Requesting help in an emergency using a communications device such as
   a telephone functionality moves from circuit-switched telephony to or mobile is an accepted practice in most of the world.
   As communications devices increasingly utilize the Internet telephony, its to
   interconnect and communicate, users rightfully expect that this core
   functionality will continue to work at least as well expect to use
   such devices to request help, regardless of whether or not they
   communicate using IP.  This document describes establishment of a
   communications session by a user to a "Public Safety Answering Point"
   (PSAP) that is a call center established by response agencies to
   accept emergency calls.  Such citizen/visitor-to-authority calls can
   be distinguished from those that are created by responders
   (authority-to-authority) using public communications infrastructure
   often involving some kind of priority access as it has defined in Emergency
   Telecommunications Service (ETS) in IP Telephony [RFC4190].  They
   also can be distinguished from emergency warning systems that are
   authority-to-citizen.

   Supporting emergency calling requires cooperation by a number of
   elements, their vendors and service providers.  It discusses how end
   device and applications create emergency calls, how access networks
   supply location for some of these devices, how service providers
   assist the older technology. establishment and routing, and how PSAPs receive calls
   from the Internet.

   The emergency response community will have to upgrade their
   facilities to support the wider range of communications services, but
   cannot be expected to handle wide variation in device and service
   capability.  New devices and services are being made available which that
   could be used to make a request for help which that are not traditional
   telephones, and users are increasingly expecting them to be used to
   place emergency calls.  However, many of the technical advantages of
   Internet multimedia require re-thinking of the traditional emergency
   calling architecture.  This challenge also offers an opportunity to
   improve the operation of emergency calling technology, while
   potentially lowering its cost and complexity.

   It is beyond the scope of this document to enumerate and discuss all
   the differences between traditional (PSTN) (Public Switched Telephone
   Network) and IP based telephony, but calling on the Internet is
   characterized by:
   o  the interleaving of signaling and media data packets;
   o  the interleaving over the same infrastructure of a wider variety
      of services;
   o  the separation of the access provider from the application
      provider;
   o  the plethora of different media that can be accommodated;
   o  potential mobility of all end systems, including endpoints
      nominally thought of as fixed systems and not just those using
      radio access technology.  For example, a wired phone connected to
      a router using a mobile data network such as EV-DO as an uplink; uplink.

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

   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
   placed by specially designated persons who  There are many legacy telephone networks that
   will persist long after most systems have authority been upgraded to claim
   priority on available Internet communications facilities.  This
   document only discusses a request for help by an ordinary user
   answered at an IP
   origination and termination of emergency call center (i.e. a PSAP). calls.  There will be PSAPs
   that require new systems to terminate to existing mechanisms for some
   time.  Many of these legacy systems use telephone number based
   routing.  Gateways and conversions between existing systems and newer
   systems defined by this document will be required.  Since existing
   systems are governed primarily by local government regulations and
   national standards, the gateway and conversion details will be
   governed by national standards and thus are out of scope for this
   document.

   Existing emergency call systems are organized locally or nationally;
   there are currently no international standards.  However, the
   Internet crosses national boundaries, and thus international
   standards for equipment and software are required.  To further
   complicate matters, VoIP endpoints can be connected through tunneling
   mechanisms such as virtual private networks (VPNs).  Tunnels can
   obscure the identity of the actual access network that knows the
   location.  This significantly complicates emergency calling, because
   the location of the caller and the first element that routes
   emergency calls can be on different continents, with different
   conventions and processes for handling of emergency calls.

   The IETF has historically refused to create national variants of its
   standards.  Thus, this document attempts to take into account best
   practices that have evolved for circuit switched PSAPs, but makes no
   assumptions on particular operating practices currently in use,
   numbering schemes or organizational structures.

   This document discusses the use of the Session Initiation Protocol
   (SIP) [RFC3261] by PSAPs and calling parties.  While other inter-
   domain call signaling protocols may be used for emergency calling,
   SIP is ubiquitous and possesses, through its related specifications possesses the proper support of this use case.
   Only protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable
   for inter-domain communications, ruling out MGC protocols such as
   MGCP or H.248/
   Megaco. H.248/Megaco.  The latter protocols can naturally be used by
   the enterprise or carrier placing the call, but any such call would
   reach the PSAP through a media gateway controller, similar to how interdomain
   inter-domain VoIP calls would be placed.  Other signaling protocols
   may also use protocol translation to communicate with a SIP-enabled
   PSAP.

   Existing emergency services rely exclusively on voice and
   conventional text telephony ("TTY") media streams.  However, more
   choices of media offer additional ways to communicate and evaluate
   the situation as well as to assist callers and call takers in
   handling emergency calls.  For example, instant messaging and video
   could improve the ability to communicate and evaluate the situation
   and to provide appropriate instruction prior to arrival of emergency
   crews.  Thus, the architecture described here supports the creation
   of sessions of any media type, negotiated between the caller and PSAP
   using existing SIP protocol mechanisms [RFC3264].  To ensure that,
   [I-D.ietf-ecrit-phonebcp] recommends certain minimal capabilities in
   that call taker user agents and PSAP-operated proxies should possess.

   Supporting emergency calling does not require any new specialized SIP
   header fields, request methods, status codes, message bodies, or
   event
   packages. packages, but does require that existing mechanisms be used in
   certain specific ways, as described below.  User agents unaware of
   the recommendations in this draft may be able to place emergency
   calls, but functionality may be
   impared. impaired.  For example, if the UA
   does not implement the location 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 dispatch of emergency responders
   may be delayed.  Suggested behavior for both endpoints and servers is provided
   provided.

   From the point of view of the PSAP three essential elements
   characterize an emergency call:
   o  The call is routed to the most appropriate PSAP, selected
      principally by the location of the caller.
   o  The PSAP must be able to automatically obtain the location of the
      caller sufficiently accurate to dispatch a responder to help the
      caller.

   o  The PSAP must be able to re-establish a session to the caller if
      for any reason the original session is lost.

3.  Overview of How Emergency Calls how emergency calls are Placed

   We distinguish (Section 4) an placed

   An emergency call can be distinguished (Section 5) from any other
   call by a unique Service URN[I-D.ietf-ecrit-service-urn], which URN [I-D.ietf-ecrit-service-urn], that is
   placed in the initial call set-up signaling when a home or visited emergency
   dial string is detected.  We route  Because emergency calls based on the services are local to
   specific geographic regions, a caller must obtain his location (
   (Section 5)) of the caller. Section 6) prior to making emergency calls.  To get this location we
   location, either include a form of measuring (e.g. (e.g., GPS) ( (Section 5.3.3)) 6.2.3)
   device location in the endpoint, endpoint is deployed, or the endpoint is
   configured ( (Section 5.5)) 6.5) with its location from the access network's
   Location Information Server (LIS) (LIS).  The location is conveyed (
   (Section 5.6)) 6.7) in the SIP signaling with the call.  We route( (Section 6)) the  The call is routed
   (Section 8) based on location using the LoST protocol ( [I-D.ietf-ecrit-lost])
   which
   [I-D.ietf-ecrit-lost], that maps a location to a set of PSAP or URIs.
   Each URI resolves to a PSAP or an Emergency Services Routing Proxy which
   (ESRP) that serves a group of PSAPs.  The call arrives at the PSAP
   with the location included in the INVITE request.

   The following is a quick overview for a typical Ethernet connected
   telephone using SIP signaling.  It illustrates one set of choices for
   various options presented later in this document.
   o  The phone "boots" and connects to its access network
   o  The phone gets location from the DHCP server [RFC4676] or
      [RFC3825], a HELD server [I-D.ietf-geopriv-http-location-delivery]
      or the first level switch's LLDP server [LLDP].
   o  The phone obtains the local emergency dial string(s) from the
      [I-D.ietf-ecrit-lost] server for its current location.  It also
      receives and caches the PSAP URI obtained from LoST.
   o  It recognizes an emergency call from the dial strings and uses
      "urn:service:sos" [I-D.ietf-ecrit-service-urn] to mark an
      emergency call.
   o  It determines the PSAP's URI by querying the LoST mapping server
      with its location.
   o  It puts its location in the SIP INVITE in a Geolocation header
      [I-D.ietf-sip-location-conveyance] and forwards the call using its
      normal outbound call processing, that commonly involves an
      outgoing proxy.
   o  The proxy recognizes the call as an emergency call and routes the
      call using normal SIP routing mechanisms to the URI specified.
   o  The call routing commonly traverses an incoming proxy server in
      the emergency services network.  That proxy would route to the
      PSAP.

   o  The call is established with the PSAP and common media streams are
      created.
   o  The location of the caller is displayed to the call taker.

          Configuration Servers
    . . . . . . . . . . . . . . . . .
    .                               .
    .   +--------+    +----------+  .
    . +--------+ |  +----------+ |  .
    . | LIS    | |  | SIP      | |  .
    . |        |-+  | Registrar|-+  .
    . +--------+    +----------+    .
    .   ^               ^           .
    . . | . . . . . . . | . . . . . .
        |               |
        |[1][4]         |[2]
        |[M1][M4]       |[M2]
        |               |         +--------+
        |+--------------+       +--------+ |
        ||                      | LoST   | |
        ||+-------------------->| Servers|-+
        |||        [3][5]        [M3][M5]     +--------+       +-------+
        |||                                      | PSAP2 |
        |||                                      +-------+
        |||
        |||   [6]  +-------+ [7] +------+ [8]  [M6]  +-------+ [9] [M7]+------+ [M8]+-------+
      Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
                   +-------+     +------+     +-------+

                                                 +-------+
                                                 | PSAP3 |
                                                 +-------+

                Figure 1: Generic ECRIT Emergency Call Component Topology

   Figure 2 shows a generic emergency call establishment.  This includes
   the following:
   o  Alice - who will make the emergency call.
   o
               Configuration                     LoST
       Alice      Servers - Servers providing Alice's UA its IP
      address and other configuration information, perhaps including
      Location by-value or by-reference.  In this flow, we use DHCP as
      an example location configuration protocol.      ESRP             Server          PSAP

   [M1] LCP Request(s) (ask for location)
   ---------->
   LCP Reply(s) (replies with location)
   <---------
   [M2] SIP REGISTER
   ---------->
   SIP 200 OK (REGISTER)
   <---------
   [M3] Initial LoST Protocol Query (contains location)
   ---------------------------------------->
   Initial LoST Protocol Response (contains PSAP-URI and dial
   string)
   <----------------------------------------

   *** Some time later, Alice dials/initiates emergency call ***

   [M4] LCP Request (update location)
   ---------->
   LCP Reply (replies with location)
   <---------
   [M5] Update LoST Protocol Query (contains location)
   ---------------------------------------->
   LoST Protocol Response (contains PSAP-URI)
   <----------------------------------------
   [M6/7] INVITE (service URN, Location & PSAP URI)
   --------------------->

   [M8] INVITE (urm:service:sos, Location & PSAP-URI)
   -------------------------------------->
                                    200 OK
         <--------------------------------------------------------------
                                    ACK
         -------------------------------------------------------------->
                        Emergency Session Established
         <=============================================================>

         Figure 2: General Flow of an Emergency Call Establishment

   Figure 1 shows emergency call component topology and Figure 2 shows
   call establishment.  These include the following:
   o  Alice - who makes the emergency call.
   o  Configuration Servers - Servers providing Alice's UA its IP
      address and other configuration information, perhaps including
      location by-value or by-reference.  In this flow, DHCP is used as
      an example location configuration protocol (LCP).  Configuration
      servers also may include a SIP Registrar server, registrar for Alice's UA to
      register Alice's UA to register with. UA.  Most SIP
      UAs will register
      with a call server, register, so it will be a common scenario for UAs that
      make emergency calls to be registered with such a server in the
      originating calling network.  Registration would be required for
      the PSAP to be able to call back after an emergency call is
      completed.  All the configuration messages are labeled M1 through
      M3, but could easily require more messages than 4 3 messages to complete.
   o  ESRP - The Emergency Services Routing Proxy Server emergency services routing proxy server that is the
      incoming call proxy in the emergency services domain.  The ESRP
      makes further routing decisions (e.g. based on PSAP state and the
      location of the caller caller) to choose the actual PSAP which that handles the
      call.  In some jurisdictions, that this may involve another LoST query query.
   o  LoST Server server - Processes the LoST request for Location + Service
      URN to PSAP-URI Mapping function, either for an initial request
      from a UA, or an in-call routing by the Proxy server in the
      originating network, or possibly by an ESRP.
   o  PSAP - Call center where emergency calls are destined for in times
      of emergencies. for.

   Generally, Alice's UA either has location configured manually, has an
   integral location measurement mechanism, or it runs a location
   configuration protocol LCP [M1] to
   obtain location from the access (broadband) network.  For most
   devices, a location configuration protocol LCP will be used, for example a DHCPREQUEST message or
   another location acquisition mechanism.  Alice's UA then will most
   likely register [M2] with a SIP domain.  This allows her to be
   contacted by other SIP entities.  Next, her UA will perform an
   initial LoST Location-to-PSAP
   SIP(S)-URI query [M3] to learn a URI, URI for use if the Lost Query LoST query
   fails during an emergency call call, or to use it to test the emergency call
   mechanism.  The LoST query response may contain the dial string for
   emergency calls appropriate for the location provided.

   Some

   At some time after her device has hopefully passed since Alice's UA booted.  In this
   example, she dials or booted, Alice initiates an
   emergency call.  This  She may have
   been through her keypad with her locally known do this by dialing an emergency dial string.
   It is important that this dial string be recognized by
   valid for her UA
   wherever Alice is because she may be in enough distress she forgets
   what the traveled-to emergency dial string is; as there are more than
   60 around the world. current ("local") location, or for her "home" location.

   The UA recognizes the dial string, which means this is an emergency
   call. string.  The UA attempts to refresh its location,
   location [M4], and with that location, to refresh the LoST mapping, mapping
   [M5], in order to get the most accurate information to use for
   routing the call.  If the location request or the LoST request fails (or fails,
   or takes too long) long, the UA uses it's cached values. values it has cached.

   The UA creates an a SIP INVITE which [M6] request that includes the location.
   [I-D.ietf-sip-location-conveyance] defines a SIP Location Geolocation header
   that contains either contain the a location-by-reference URI, URI or a [RFC2396] "cid:" "cid"
   URL indicating where in the message body the location-by-value is.

   The INVITE message routes is routed to the ESRP, which ESRP [M7], that is the first
   inbound proxy for the emergency services domain.  This message, message is
   then routed by the ESRP towards the most current appropriate PSAP for Alice's
   location, which uses
   location [M8], as determined by PSAP state, location and other state information
   to choose this PSAP.
   information.

   A proxy in the PSAP chooses an available call taker and extends the
   call to its UA.

   The 200 OK response to the INVITE request traverses the path in
   reverse, from call 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 is established, allowing the PSAP call-taker to
   talk to Alice about
   her Alice's emergency.

               Configuration                     LoST
       Alice      Servers      ESRP             Server          PSAP

         [M1] DHCP Request(s) (may ask for Location)
         ---------->
              DHCP Reply(s) (replies with location if asked)
         <---------
         [M2] SIP REGISTER
         ---------->
              SIP 200 OK (REGISTER)
         <---------
         [M3] Initial LoST Protocol Query (contains Location)
         ---------------------------------------->
              Initial LoST Protocol Response (contains PSAP-URI)
         <----------------------------------------

      ***Some time later, Alice dials/initiates

4.  Which devices and services should support  emergency call***

         [M4] DHCP Request(s) (update Location)
         ---------->
              DHCP Reply(s) (replies with location)
         <---------
         [M5] Update LoST Protocol Query (contains Location)
         ---------------------------------------->
              LoST Protocol Response (contains PSAP-URI)
         <----------------------------------------
         [M6/7] INVITE (sos URN, Location & early PSAP URI)
         --------------------->

                               [M8] INVITE (sos, Location & PSAP-URI)
                               -------------------------------------->
                                    200 OK
         <--------------------------------------------------------------
                                    ACK
         -------------------------------------------------------------->
                        Emergency Session Established
         <=============================================================>

         Figure 2: General Flow of an Emergency Call Establishment

   This calls

   Support for voice calls and real-time text calls placed through PSTN
   facilities or systems connected to the PSTN is found in present
   PSAPs.  Future PSAPs will however support Internet connectivity and a very rough example of the operation
   wider range of an emergency call
   establishment.  There are no layer 3 routers in media types and provide higher functionality.  In
   general, if a user could reasonably expect to be able to place a call
   for help with the message flow, device, then the device or service should support
   emergency calling.  Certainly, any device or service that looks like
   and
   whatever security messages exist in works like a telephone (wired or mobile) should support emergency
   calling, but increasingly, users have expectations that other devices
   and services should work.

   Certainly, any device or service that looks like and works like a
   telephone (wired or mobile) should support emergency calling, but
   increasingly, users have expectations that other devices and services
   should work.

   Using current (evolving) standards, devices that create media
   sessions and exchange audio, video and/or text, and have the call are not shown either.
   Each of those aspects will be addressed individually,
   capability to keep each
   discussion in context establish sessions to a wide variety of that subject, for clarity.

4. addresses, and
   communicate over private IP networks or the Internet, should support
   emergency calls.

5.  Identifying an Emergency Call emergency call

   Using the PSTN, emergency help can often be summoned by dialing a
   nationally designated, widely known number, regardless of where the
   telephone was purchased.  The appropriate number is determined by
   which the
   infrastructure the telephone is connected to.  However, this number
   differs between localities, even though it is often the same for a
   country or region, such as it is in many countries in the European Union.
   In some countries, there is a single digit sequence that is used for
   all types of emergencies.  In others, there are several sequences
   that are specific to the responder, type of responder needed, e.g., one for
   police, another for fire.  It is deemed impractical to change the dialed
   digits to summon help.  For end systems, on the other hand, it is
   desirable to have a universal identifier, independent of location, to
   allow the automated inclusion of location information and to allow
   the device and other entities in the call path to perform appropriate
   processing within the signaling protocol in an emergency call set-up.

   As

   Since there is no such universal identifier, as part of the overall
   emergency calling architecture, we define common emergency call URIs which URNs are
   defined in [I-D.ietf-ecrit-service-urn].  An example, for a single
   number environment is "urn:service:sos".  Users are not expected to
   "dial" an emergency URN.  Rather, the current appropriate emergency dial string should be strings
   is translated to the appropriate corresponding service URN. URNs, carried in the Request-
   URI of the INVITE.  Such translation could ideally be
   performed in is best done by the endpoint,
   because emergency calls convey location in the signaling, but non
   emergency calls do not normally do that.  If the device recognizes
   the emergency call, it can include location.  Dial string recognition
   could be performed in a signaling intermediary (proxy server). server) if for
   some reason, the endpoint does not recognize it.  For devices that
   are mobile or nomadic, an issue arises of whether the home or visited
   dialing strings should be used.  Many users would prefer that their
   home dialing sequences work no matter where they are.  Local laws and preferences of the
   emergency response professionals are such that
   regulations may require the visited dialing
   sequences must sequence(s) always work.
   Having the home dial string work is optional.

   The best answer seems to be for both to work.

   The mechanism for obtaining the dialing sequences for a given
   location is provided by LoST [I-D.ietf-ecrit-lost].  Where  If the endpoint
   does not support the translation of dial strings to telephone
   numbers, the dialing sequence would be represented as a dial string [I-D.rosen-iptel-dialstring]
   [RFC4967] and the outgoing proxy would recognize the dial string and
   translate to the service URN.  To determine the local dial string,
   the proxy needs the location of the endpoint.  This may be difficult
   in situations where the user can roam or be nomadic.  Endpoint
   recognition of emergency dial strings is therefore preferred.

5.

   Note: It is undesirable to have a single "button" emergency call user
   interface element.  These mechanisms tend to result in a very high
   rate of false or accidental emergency calls.  In order to minimize
   this rate, devices SHOULD only initiate emergency calls based on
   entry of specific emergency call dial strings.

   While in some countries there is a single 3 digit dial string that is
   used for all emergency calls (i.e. 9-1-1 in North America), in some
   countries there are several 3 digit numbers used for different types
   of calls.  For example, in Switzerland, 1-1-7 is used to call police,
   1-1-8 is used to call the fire brigade, and 1-4-4 is used for
   emergency medical assistance.  In other countries, there are no
   "short codes" or "service codes" for 3 digit dialing of emergency
   services and local (PSTN) numbers are used.

   [I-D.ietf-ecrit-service-urn] introduces a universal emergency service
   URN scheme.  On the wire, emergency calls include this type of URI in
   the Request-URI [RFC3261].  The scheme includes a single emergency
   URN (urn:service:sos) for use in countries with a single emergency
   dial string, and responder-specific ones (urn:service:sos.police) for
   countries where the user dials each service with separate numbers.
   Using the service:sos URN scheme, emergency calls can be recognized
   as such throughout the Internet.

6.  Location and Its Role its role in an Emergency Call

5.1.  Introduction

   Caller location plays a emergency call

   Location is central role to the operation of emergency services.  It is
   frequently the case that the user in routing an emergency calls. is unable to
   provide a unique, valid location themselves.  For this reason,
   location provided by the endpoint or the access network is needed.
   For practical reasons, each PSAP generally handles only calls for a
   certain geographic area (overload area, with overload arrangements between PSAPs to
   handle each others calls notwithstanding). calls.  Other calls that reach it by accident must
   be manually re-routed (transferred) to the most appropriate PSAP,
   increasing call handling delay and the chance for errors.  The area
   covered by each PSAP differs by jurisdiction, where some countries
   have only a small number of PSAPs, while others decentralize PSAP
   responsibilities to the level of counties or municipalities.

   In most cases, PSAPs cover at least a city or town, but there are
   some areas where PSAP coverage areas follow old telephone rate center
   boundaries and may straddle more than one city.  Irregular boundaries
   are common, often for historical reasons.  Routing must be done based
   on PSAP service boundaries, not "closest" the closest PSAP, or "best fit" algorithms.

5.2.  Types of Location Information

   There are four primary types the PSAP that serves
   the nominal city name provided in the location may not be the correct
   PSAP.

   Accuracy of routing location information: civic, postal,
   geospatial, and cellular cell tower is a complex subject.  Calls must be
   routed quickly, but accurately, and sector.

   Civic:  Civic location information describes the location of determination is often a person
   time/accuracy tradeoff, especially with mobile devices or object by self
   measuring mechanisms.  It is considered acceptable to base a street address that corresponds routing
   decision on an accuracy equal to the area of one sector of a building or
      other structure.  (This mobile
   cell site if no more accurate routing location is sometimes also called "civil" available.

   Routing to the most appropriate PSAP is always calculated on the
   location
      information.)  Civic of the caller, despite the fact that some emergency calls
   are placed on behalf of someone else, and the location of the
   incident is sometimes not the location of the caller.  In some cases,
   there are other factors that enter into the choice of the PSAP that
   gets the call, which may include more finely grained factors other than location information such (such as floor, room
   caller media and cubicle.  Civic
      information comes in language preference, PSAP state, etc.).  However,
   location of the caller is the primary input to the routing decision.

   Routing is but one of two forms:
      Jurisdictional -  This refers uses for location in an emergency call.
   The other is for dispatch of a responder.  Many mechanisms used to
   locate a caller have a relatively long "cold start" time.  To get a civic
   location using actual
         political subdivisions, especially accurate enough for the community name.
      Postal - dispatch may take as much as 30 seconds.
   This refers is too long to a civic location used wait for emergencies.  Accordingly, it is common,
   especially in mobile systems to mail use a letter
         to.  The name of coarse location, for example,
   the post office sometimes does not correspond
         to cell site and sector serving the actual community name call, for routing purposes, and a postal address may contain
         post office boxes or street addresses that do not correspond
   then to
         an actual building.  Postal addresses are generally unsuitable
         for emergency call routing, but may be the only address
         available.
   Geospatial:  Geospatial addresses contain longitude, latitude and
      altitude information based on an understood datum (starting point)
      and earth shape model.  While there have been many datum developed
      over time, most modern systems are using or moving towards update the
      [WGS84] datum.

   Cell tower/sector:  Cell tower location when a more precise value is known prior
   to dispatch.  In this document we use "routing location" and sectors identify
   "dispatch location" when the cell tower distinction matters.

   Accuracy of dispatch location is sometimes determined by local
   regulation, and the antenna sector is constrained by available technology.  The actual
   requirement exceeds available technology.  It is required that the mobile a
   device is currently using.
      Traditionally, making an emergency call close to the tower location is expressed as "demising" or separation
   wall between two apartments in a point, and
      routing decisions are made high rise apartment building report
   location with sufficient accuracy to determine on that point.  Cell/sector information
      could also be transmitted as an irregularly shaped polygon what side of
      geospatial coordinates reflecting the likely geospatial location
   wall it is on.  This implies perhaps a 3 cm accuracy requirement.  As
   of the mobile device.

   In IETF protocols, civic date of this memo, typical assisted GPS uncertainty with 95%
   confidence is 100 m.

   Location usually involves several steps to process and geo forms multiple
   elements are both supported.  The civic
   forms include both involved.  In Internet emergency calling, where the postal and jurisdictional fields.  The cell
   tower/sector can be represented as
   endpoint is located is "Determined" using a point.

5.3.  Location Determination

   Location information can be entered by the user or installer variety of a
   device ("manual configuration"), can measurement or
   wire-tracing methods.  Endpoints may be measured "Configured" with their own
   location by the end system,
   can be delivered to the end system by access network.  In some protocol or can be
   measured by circumstances, a third party and inserted proxy
   server may insert location into the call signaling.  We
   discuss these in detail below.

   In some cases, an entity may have multiple sources signaling on behalf of location
   information, possibly partially contradictory.  This is particularly
   likely if the
   endpoint.  The location information is determined both by "Mapped" to the end
   system URI to send the call to,
   and a third party.  Handling multiple locations is discussed
   in [I-D.ietf-geopriv-pdif-lo-profile].  Conflicting the location
   information is particularly harmful if it points "Conveyed" to multiple distinct
   PSAPs.  Guidelines for dealing with multiple locations is also given the PSAP (and other elements) in [I-D.ietf-ecrit-lost].

   All location objects MUST be delivered to
   the PSAP. signaling.  Likewise, we employ Location
   information should contain information about Configuration Protocols,
   Location Mapping Protocols, and Location Conveyance Protocols for
   these functions.  The Location-to-Service Translation protocol
   [I-D.ietf-ecrit-lost] is the source of data, such
   as GPS, manually entered or based on access network topology.  In
   addition, Location Mapping Protocol defined by the source
   IETF.

6.1.  Types of the location information should

   There are several ways location can be included
   (PIDF "provided-by").  The ability of the UA to understand how it
   learned its location, and include this specified:
   Civic  Civic location information element in describes the location of a person
      or object by a street address that is sent corresponds to the PSAP, provides the call-taker
   with many pieces of a building or
      other structure.  Civic location may include more finely grained
      location information to make decisions upon, such as floor, room and guidance
   for what cubicle.  Civic
      information comes in two forms:

      Jurisdictional  This refers to ask a civic location using actual
         political subdivisions, especially for the caller and what community name.
      Postal  This refers to tell the responders.

   The call should indicate which a civic location information has been used for
   routing, so that mail delivery.  The
         name of the same location information is used post office sometimes does not correspond to the
         community name and a postal address may contain post office
         boxes or street addresses that do not correspond to an actual
         building.  Postal addresses are generally unsuitable for all
         emergency call
   routing decisions.  Otherwise, two proxies might pick different
   location information from dispatch because the call request, resulting in different
   routing decisions post office conventions
         (for community name, for different transactions. example) do not match those known by
         the responders.  The location
   conveyance mechanism [I-D.ietf-sip-location-conveyance] contains a
   parameter which fact that they are unique can sometimes be used for this purpose

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

5.3.1.  User-Entered Location Information

   Location information can be maintained by the end user or the
   installer of an endpoint in the endpoint itself, or in mapping between a postal address and a database.

   Location information added by end users is almost always inferior to
   measured or wire database information, as users may mistype
         civic
   location information, may not know the meaning of geospatial
   coordinates or may use address information that does not correspond suitable to dispatch a recognized civic address.  A user-entered responder to.  In IETF
         location protocols, there is a element (Postal Community Name)
         that can fail to be changed when the location of a device changes during or after
   movement.  For example, included in a user could move their residence to another
   dwelling, not update their device/equipment with this new location,
   and place an emergency call with old location information.

   All that said, there are always a small number of cases where the
   mechanisms used by the access network to determine location fail to
   accurately reflect the actual location of the endpoint.  For example, provide the user may deploy his own WAN behind an access network, effectively
   remoting an endpoint some distance from post office
         name as well as the access network's notion
   of its location. actual jurisdictional community name.
         There must be some mechanism provided to provision
   a location is no other accommodation for postal addresses in these
         protocols.
   Geospatial (geo):  Geospatial addresses contain longitude, latitude
      and altitude information based on an endpoint by the user understood datum and earth
      shape model.  While there have been many datums developed over
      time, most modern systems are using or by moving towards the access network on
   behalf
      WGS84[WGS84] datum.
   Cell tower/sector:  Cell tower/sector is often used for identifying
      the location of a user.  The use mobile handset, especially for routing of
      emergency calls.  Cell tower and sectors identify the mechanism introduces cell tower
      and the
   possibility of users falsely declaring themselves to be somewhere
   they are not.  As an aside, normally, if an emergency caller insists
   he is at antenna sector that a location different from what any automatic location
   determination system reports he is, responders will always be sent to mobile device is currently using.
      Traditionally, the user's self-declared location.  However this tower location is represented as a matter of local
   policy point chosen
      to be within a certain PSAP service boundary who agrees to take
      calls originating from that tower/sector, and is outside the scope of this document.

5.3.2.  Access Network "Wire Database" Location Information

   Location routing decisions
      are made on that point.  Cell/sector information can could also be maintained by the access network,
   relating some form of identifier for the end subscriber or device to
   a location database ("wire database").  In enterprise LANs, wiremap
   databases map Ethernet switch ports to building layouts at known
   locations.  In DSL installations, the local telephone carrier
   maintains a mapping
      represented as an irregularly shaped polygon of wire-pairs to subscriber addresses.

   Even for IEEE 802.11 wireless access points, wire databases may
   provide sufficient location resolution; geospatial
      coordinates reflecting the likely geospatial location of the access
   point may be sufficient location information for each of
      mobile device.  Whatever representation is used must route
      correctly in the clients
   served LoST database, where "correct" is determined by that access point.  However, this may not be true for
   larger scale systems such as IEEE 802.16
      local PSAP management.

   In IETF protocols, civic and IEEE 802.22 which
   typically have larger cells than those of IEEE 802.11.  A Wire
   database may be the source of location information for geospatial forms are both
   residential users of DSL supported.
   The civic forms include both postal and Cable Modem installations, as well as
   the only infrastructure at a WiFi hotspot, such jurisdictional fields.  A
   cell tower/sector can be represented as a coffee shop.
   Each point (geo or civic) or
   polygon.  Other forms of these cases will have location representation must be mapped into
   either a known geo or civic address for use in emergency calls.

   For emergency call purposes, conversion of the dwelling/
   business, likely providing sufficient location resolution.  However,
   the information from
   civic location of an IEEE 802.16 base station may be of little
   use to emergency personnel

   Wire databases to the home are likely geo or vice versa prior to conveyance is not desirable.  The
   location should be sent in the most promising
   solution for residential users where a service provider knows the
   customer's service address.  The service provider can then perform
   address verification, similar form it was determined.  Conversion
   between geo and civic requires a database.  PSAPs may need to convert
   from whatever form they receive to another for responder purposes.
   They have a suitable database.  However, if a conversion is done
   before the current system in some
   jurisdictions.

5.3.3.  End-System Measured PSAP, and the database used is not exactly the one the
   PSAP uses, the double conversion has a high probability of
   introducing an error.

6.2.  Location Information

   Global Positioning System (GPS) sensors may Determination

   Location information can be embedded directly in entered by the user or installer of a
   device ("manual configuration"), measured by the end device.  GPS produces relatively high precision location
   fixes in open-sky conditions, but system, can be
   delivered to the technology still faces several
   challenges in terms end system by some protocol or measured by a third
   party and inserted into the call signaling.  Choice of performance (time-to-fix location
   determination mechanisms and time-to-first-
   fix), as well as obtaining successful their properties are out of scope for
   this document.

   In some cases, an entity may have multiple sources of location fixes within shielded
   structures, or underneath the ground (tunnels, basements, etc.).  It
   also requires all devices to be equipped with
   information, possibly partially contradictory.  This is particularly
   likely if the appropriate GPS
   capability.  GPS technology location information is improving (e.g.  Galileo), determined both by the end
   system and a third party.  Although self measured location (e.g.
   GPS) is
   increasingly successful in attractive, access network provided location could be much
   more difficult conditions such as dense
   urban canyons accurate, and inside commercial structures.  It is currently
   accurate to tens of meters using more reliable in some kind of "assist", which may environments (indoor high
   rise in dense urban areas for example).

6.2.1.  User-entered location information

   Location information can be
   operated maintained by the access network (A-GPS) end user or by a government (WAAS).
   Newer multi-frequency systems will improve accuracy without assist.

   GPS equipped devices vary depending on which element initiates
   requests, which element actually determines final location, assist
   mechanisms, etc.  Some common implementations include:
   1.  GPS S/A (standalone), device initiated
   2.  GPS S/A, network initiated
   3.  AGPS-device initiated, network determined
   4.  AGPS-device initiated, network augmented
   5.  AGPS-network initiated, network determined
   6.  AGPS-network initiated, network augmented

5.3.4.  Third-party Measured Location Information

   Wireless triangulation:  Elements in the network infrastructure
      triangulate end systems based on signal strength, angle
   installer of arrival an endpoint in the endpoint itself, or time of arrival.  Common mechanisms deployed include.

      1.  Time Difference Of Arrival - TDOA
      2.  Uplink Time Difference Of Arrival - U-TDOA
      3.  Angle of Arrival - AOA
      4.  RF-Fingerprinting
      5.  Advanced Forward Link Trilateration - AFLT
      6.  Enhanced Forward Link Trilateration - EFLT
      Sometimes triangulation and measured mechanisms are combined, for
      example A-GPS with AFLT in a database.

   Location beacons:  A short range wireless beacon, e.g., using
      Bluetooth information provided by end users is almost always less
   reliable than measured or infrared, announces its wire database information, as users may
   mistype location to mobile devices in
      the vicinity.

5.4.  Location and References to Location

   Location information or may be expressed as the actual enter civic or geo
   value but address information
   that does not correspond to a recognized (i.e. valid, see Section
   Section 6.10) address.  Users can be transmitted as by-value (wholly contained within the
   signaling message) or by-reference (a URI pointing neglect to change the value
   residing on data when the
   location of a remote node waiting to be dereferenced).  There are
   pros and cons to each form:
   location-by-value:
      pro-  Value available to each device along the path immediately
         for further processing.
      con-  Size, especially if constrained to changes during or after movement.

   All that said, there are always a UDP transport.  Value
         fixed at the time the value is acquired from small number of cases where the access
         network.  Value can be changed
   automated mechanisms used by the endpoint, which may be
         considered untrustworthy for this critical usage.
   location-by-reference
      pro-  Small size.  Value can be fixed at time of dereference.
         Value cannot be changed by endpoint
      con-  URI resolution requires location source be available and
         accessible by dereferencer.  Dereferencing takes time.
         Dereferencing may fail.

5.5.  End System Location Configuration

   Unless a user agent has access network to provisioned or locally measured determine location information, it must obtain it
   fail to accurately reflect the actual location of the endpoint.  For
   example, the user may deploy his own WAN behind an access network,
   effectively removing an endpoint some distance from the access network.
   network's notion of its location.  There are several Location Configuration Protocols (LCPs) that can must be
   used for this purpose.

   DHCP  can deliver civic [RFC4676] or geospatial [RFC3825]
      information.  User agents would need some mechanism
   provided to support both formats.
      Note that provision a location for an endpoint by the user agent can or by
   the access network on behalf of a user.  The use DHCP, via of the DHCP REQUEST or
      INFORM messages, even if it uses other means to acquire its IP
      address.

   Insert reference mechanism
   introduces the possibility of users falsely declaring themselves to L7 acquisition protocol document>  is another
      choice.
   Link-Layer Discovery Protocol  [LLDP]), with proposed extensions
      [LLDP-MED], may also
   be used to deliver location information.
   SUPL  OMA <insert reference> somewhere they are not.  As an aside, normally, if an emergency
   caller insists that he is yet another choice.

   Other LCPs may at a location different from what any
   automatic location determination system reports he is, responders
   will always be devised by other standards bodies.  Each LCP has
   limitations in sent to the kinds of networks that can reasonably support it.
   For user's self-declared location.  However
   this reason, it is not possible to choose a single mandatory to
   deploy LCP.  For endpoints with common network connections (such as
   an Ethernet jack or a WiFi connection), unless every matter of local policy and is outside the scope of this
   document.

6.2.2.  Access network
   supported every protocol, "wire database" location information

   Location information can be maintained by the access network,
   relating some form of identifier for the end subscriber or alternatively, every device supported
   every protocol, serious incompatibilities would ensue.
   [I-D.ietf-ecrit-phonebcp] contains to
   a location database ("wire database").  In enterprise LANs, wiremap
   databases map Ethernet switch ports to building locations.  In DSL
   installations, the local telephone carrier maintains a (short) list mapping of protocols such
   devices must support.

   Where an access network can control the specification
   wire-pairs to subscriber addresses.

   Accuracy of EVERY
   endpoint that could make an emergency call that is directly connected location historically has been to the network, or indirectly connected (for example, a device on street address level.
   However, this is not sufficient for larger structures.  The PIDF-LO
   [RFC4119] with a
   LAN behind recent extension [I-D.ietf-geopriv-revised-civic-lo]
   permits interior building/floor/room and even finer specification of
   location within a network attachment unit), it may specify any protocol it
   wishes street address.  When possible, interior location
   should be supported.

   The threshold for each endpoint.  This when interior location is a very unusual case; nearly every
   access network can needed is approximately
   650 m2 (that is derived from fire brigade recommendations of spacing
   of alarm pull stations) should have, but interior space layout,
   construction materials and other factors should be used considered.  The
   ultimate goal is to support an Ethernet based LAN behind it

   For example, existing mobile networks are being used be able to support
   routers and LANs behind a find the person in need quickly if
   responders arrive at the location given.

   Even for IEEE 802.11 wireless data network WAN connection, with
   Ethernet connected phones connected to that.  It is possible that access points, wire databases may
   provide sufficient location resolution.  The location of the access network supports a protocol not on
   point as determined by the phonebcp list, and
   every handset supported in that network could use that protocol wiremap may be supplied as the location
   for
   emergency calls.  However, unless another element which each of the access
   network provider controls clients of the specification access point.  However, this may not
   be true for larger-scale systems such as IEEE 802.16 (WiMAX) and IEEE
   802.22 that typically have larger cells than those of can acquire IEEE 802.11.
   The civic location
   using that protocol and then that element can support one of the
   phonebcp's list an IEEE 802.16 base station may be of protocols, little
   use to emergency personnel, since the Ethernet connected phone won't endpoint could be
   able several
   kilometers away from the base station.

   Wire databases to acquire location.  In this case, if the access network
   provider supplies a router which includes home are likely to be the most promising
   solution for residential users where a DHCP server, it can
   acquire location using service provider knows the access network specific protocol, and
   customer's service address.  The service provider can then
   use perform
   address validation (see Section 6.10), similar to the current system
   in some jurisdictions.

6.2.3.  End-system measured location information to supply it to its clients

   Global Positioning System (GPS) and similar satellite based (e.g. the
   Ethernet connected phone) via DHCP.

   For most networks, it will not
   Galileo) receivers may be practical to control embedded directly in the
   specification end device.  GPS
   produces relatively high precision location fixes in open-sky
   conditions, but the technology still faces several challenges in
   terms of every device, performance (time-to-fix and time-to-first-fix), as well as
   obtaining successful location fixes within shielded structures, or arrange interworking with network
   specific LCPs.  For this reason, most
   underground.  It also requires all devices will need to support
   ALL of be equipped with the LCPs in [I-D.ietf-ecrit-lost], and access networks will
   have
   appropriate GPS capability.  GPS-derived locations are currently
   accurate to support at least one tens of these LCPs.

   Location for non-mobile meters.  Many mobile devices is normally expected to require using some
   kind of "assist", that may be acquired
   at operated by the access network attachment time and retained (A-GPS)
   or by a government (WAAS).

   GPS systems may be always on; where location will always be available
   accurately (assuming the device.  It should device can "see" enough satellites).  Mobile
   devices may not be
   refreshed when able to sustain the cached value becomes invalid (for example, if DHCP
   is power levels required to keep
   the acquisition protocol, refresh of location may occur measuring system active.  This means that when the
   IP address lease location is renewed).  At
   needed, the time device has to start up the measurement mechanism.  This
   typically takes tens of seconds, far too long to wait to be able to
   route an emergency call, the call.  For this reason, devices that don't have
   end-system measured location should mechanisms always on need another way to
   get a routing location.  Typically this would be refreshed, a location
   associated with the retained a radio link (cell site/sector).

6.2.4.  Network measured location used if information

   The access network may locate end devices.  Techniques include:
   Wireless triangulation:  Elements in the network infrastructure
      triangulate end systems based on signal strength, angle of arrival
      or time of arrival.  Common mechanisms deployed include:
      1.  Time Difference Of Arrival - TDOA
      2.  Uplink Time Difference Of Arrival - U-TDOA
      3.  Angle of Arrival - AOA
      4.  RF-Fingerprinting
      5.  Advanced Forward Link Trilateration - AFLT
      6.  Enhanced Forward Link Trilateration - EFLT
      Sometimes multiple mechanisms are combined, for example A-GPS with
      AFLT
   Location beacons:  A short range wireless beacon, e.g., using
      Bluetooth or infrared, announces its location acquisition does not immediately return a value.  Mobile to mobile devices may determine in
      the vicinity.  This allows devices to get location from the beacon
      source's location.

6.3.  Who adds location, endpoint or proxy

   The IETF emergency call architecture prefers endpoints to learn their
   location at network attachment time and
   periodically thereafter as a backup in case supply it on the call.  Outbound proxies that support
   devices that do not support location may have to add location determination to
   emergency calls at a proxy server.  Some calling networks have
   relationships with all access networks the time of call does not work.  Mobile device location may be
   refreshed when a TTL expires, connected
   to, and that may allow the device moves beyond some boundaries
   (as provided by [I-D.ietf-ecrit-lost]), etc.  Normally, mobile
   devices will acquire its proxy to accurately determine location at call time for use in an
   emergency call routing, but see Section 5.7

5.6.  Conveyance of Location

   When an emergency call is placed,
   the endpoint (normally) puts
   location information in endpoint.  However NATs and other middleboxes often make it
   impossible to determine a reference identifier the signaling with access network
   could use to determine the call.  We refer location.  Systems designers are
   discouraged from relying on proxies to
   that add location.  The technique
   may be useful in some limited circumstances as "conveyance" devices are upgraded
   to distinguish it from "configuration".
   Configuration gets location from meet the requirements of this document, or where relationships
   between access network networks and calling networks are feasible and can be
   relied upon to endpoint,
   conveyance sends get accurate location.

   Proxy insertion of location from endpoint to elements that route the
   call based complicates dial string recognition.  As
   noted in Section Section 6, local dial strings depend on that the location object and
   of the PSAP.  Using SIP, caller.  If the
   location information is conveyed following device does not know its own location, it
   cannot use the procedures in
   [I-D.ietf-sip-location-conveyance]. LoST service to learn the local emergency dial
   strings.  The form of calling network must provide another way for the device
   to learn the local dial string (and update it when the user moves to
   a location
   information obtained by where the acquisition protocol dial string(s) change) or do the dial string
   determination itself.

6.4.  Location and references to location

   Location information may not be expressed as the same actual civic or
   geospatial value but can be transmitted as by value (wholly contained
   within the conveyance protocol uses (PIDF-LO [RFC4119]).  Mapping signaling message) or by reference (a URI pointing to the
   endpoint may
   value residing on a remote node waiting to be required.  Calling networks which support devices
   which do not support location may have dereferenced).  Each
   form is better suited to add some applications than others.

   When location to emergency
   calls.  Some calling networks have relationships with is transmitted by value, the access
   network that may allow it location information is
   available to accurately determine each device; on the other hand, location objects can be
   large, and only represent a single snapshot of the
   endpoint, although NATs device's location.
   Location references are small and other middleboxes usually make it
   impossible can be used to determine represent a reference identifier the access network
   could use to determine time-
   varying location, but the location.

   For emergency call purposes, conversion added complexity of the dereference step
   introduces a risk that location information from
   civic will not be available to geo or vice versa prior parties that
   need it.

6.5.  End system location configuration

   Unless a user agent has access to conveyance is not desirable.  The provisioned or locally measured
   location should be sent in the form information, it was determined.  The PSAP may
   convert, if must obtain it needs to, and if conversion resulted from an earlier
   conversion, unacceptable errors may be introduced.

5.7.  Location Updates

   Location information may not the access network.
   There are several location configuration protocols (LCPs) that can be available at call setup time
   used for
   mobile devices.  For example, if a GPS-enabled cell phone is turned
   on and then immediately places an emergency call, it this purpose such as:
   DHCP  DHCP can deliver civic [RFC4676] or geospatial [RFC3825]
      information.  User agents need to support both formats.  Note that
      a user agent can take
   significant additional time before use DHCP, via the cell phone acquires a GPS fix
   and its location.  Thus, while it is desirous to base emergency
   routing on precise caller location information, DHCP REQUEST or INFORM
      messages, even if it is not possible in
   all circumstances uses other means to do so.  In some cases, the initial call setup
   will proceed based on, for example, cell and sector information and
   then add location information during acquire its IP address.
   HELD  HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a
      civic or geo, by value or by reference, as a layer 7 protocol.
      The query typically uses the call, rather than delaying IP address of the initial call setup by requestor as an unacceptable amount of time.

   In addition,
      identifier and returns the location of a mobile caller, e.g., in a vehicle value or
   aircraft, reference associated
      with that identifier.  HELD is typically transported on HTTP.

   Link-Layer Discovery Protocol  Layer Discovery Protocol [LLDP] with
      Media Endpoint Device extensions [LLDP-MED] can change significantly during the emergency call.  The
   PSAP must be able used to get updated deliver
      location information while it is
   processing directly from the call.

   Location updates where Layer 2 network
      infrastructure, and also supports both civic and geospatial
      formats identical in format to DHCP methods.

   Each LCP has limitations in the location kinds of networks that can reasonably
   support it.  For this reason, it is conveyed by value may be
   conveyed either in not possible to choose a single
   mandatory-to-deploy LCP.  For endpoints with common network
   connections (such as an Ethernet jack or a re-INVITE WiFi connection) serious
   incompatibilities would ensue unless every network supported every
   protocol, or UPDATE [RFC3311] request message
   (where UPDATE alternatively, every device supported every protocol.
   For this reason, a list of LCPs is preferred) or the PSAP may subscribe established in
   [I-D.ietf-ecrit-phonebcp].  Every endpoint that could be used to the location
   information
   place emergency calls must implement all of the caller, using SIP presence mechanisms RFC 3856
   [RFC3856]).  Authorization for subscriptions protocols on the
   list.  Every access network must deploy at least one of them.  It is for future study.
   When location
   recognized that this is conveyed by reference, additional dereference
   operations yield updated location.

5.8.  Location Validation

   In some jurisdictions, location must an onerous requirement, that it would be validated prior
   desirable to a device
   placing an actual emergency call, and eliminate.  However, since it is always a recommended
   practice.  Validation in this context means both the variability of the
   networks that there is prevent a
   mapping single protocol from being acceptable, it
   must be the address endpoints that implement all of them, and to accommodate
   a PSAP wide range of devices, networks must deploy at least one of them.

   Often, network operators and device designers believe that the PSAP understands how
   to direct responders they have
   a simpler environment and some other network specific mechanism can
   be used to the provide location.  This is not as easy as  Unfortunately, it
   sounds.  There are, for example, many cases of two names for the same
   street, or two streets with is very rare to
   actually be able to limit the same name in range of devices that may be connected
   to a city.  In some
   countries, the current system provides validation. network.

   For example, in existing mobile networks are being used to support
   routers and LANs behind a wireless data network WAN connection, with
   Ethernet connected phones connected to that.  It is possible that the United States,
   access network could support a protocol not on the Master Street Address Guide (MSAG) records all
   valid street addresses list, and is used require
   every handset in that network to ensure use that protocol for emergency
   calls.  However, the service
   addresses in Ethernet connected phone billing records correspond won't be able to valid emergency
   service street addresses.  Validation
   acquire location, and the user of the phone is normally a concern for civic
   addresses, although there could unlikely to be a concern
   dissuaded from placing an emergency call on that a given geo is
   within at least one PSAP service boundary; phone.  The
   widespread availability of gateways, routers and other network-
   broadening devices means that is, a "valid" geo is
   one indirectly connected endpoints are
   possible on nearly every network.  Network operators and vendors are
   cautioned that shortcuts to meeting this requirement are seldom
   successful.

   Location for which there non-mobile devices is a mapping.

   The LoST resolver[I-D.ietf-ecrit-lost] includes a validation
   function.  Validation normally expected to be acquired
   at network attachment time and retained by the device.  It should ideally be performed
   refreshed when a the cached value becomes invalid.  For example, if
   DHCP is the acquisition protocol, refresh of location may occur when
   the IP address lease is
   entered into renewed.  At the time of an emergency call,
   the location should be refreshed, with the retained location used if
   the location acquisition does not immediately return a Location Information Server (which is normally value.  Mobile
   devices may determine location at network attachment time and
   periodically thereafter as a
   provisioning mechanism backup in case location determination at
   the access carrier's operation and support
   system).  It time of call does not work.  Mobile device location may be
   refreshed when a TTL expires, the device moves beyond some boundaries
   (as provided by [I-D.ietf-ecrit-lost]).  Normally, mobile devices
   will acquire its location at call time for use in an emergency call
   routing.  See Section Section 6.8 for a further discussion on
   location updates for dispatch location.

6.6.  When location should be confirmed periodically, because the mapping
   database undergoes slow change; configured

   Devices should get routing location immediately after obtaining local
   network configuration information.  The presence of NAT and VPN
   tunnels (that assign new streets are added or removed,
   community names change, postal codes change, etc.  Endpoints may wish IP addresses to validate locations they receive from communications) can obscure
   identifiers used by LCPs to determine location, especially using
   HELD.  In some cases, such as residential NAT devices, the NAT is
   before the access network, network demarcation point and will
   need to validate manually entered locations.  Proxies which insert
   location may wish to validate locations they receive from a LIS.
   Test functions (Section 13) should also re-validate.

5.9.  Default Location

   Occasionally, a failure may occur where thus the IP address
   seen by the access network cannot
   determine is the actual right identifier for location of
   the caller. residence.  In these many enterprise environments, VPN tunnels can
   obscure the actual IP address.  Some VPN mechanisms can be bypassed
   (a query to the LCP can be designated to go through the direct IP
   path, using the correct IP address, and not through the tunnel).  In
   other cases, it must
   supply a default no bypass is possible.  Of course, LCPs that use Layer 2
   mechanisms (DHCP Location options and LLDP-MED) are usually immune
   from such problems because they do not use the IP address as the
   identifier for the device seeking location.  The default

   It is desirable that routing location should information be as
   accurate as the network can determine.  For example, in a cable
   network, periodically
   refreshed.  A LIS supporting a default location for million subscribers each Cable Modem Termination System
   (CMTS), with refreshing
   once per day would need to support a representative location query rate of 1,000,00 / (24 *
   60 * 60) = 12 queries per second.

   It is desirable for all cable modems served by
   that CMTS could routing location information to be provided requested
   immediately before placing an emergency call.  However, if the network there is unable to resolve the
   subscriber to
   any unit less than significant delay in getting more recent location, the CMTS.  Default locations must call
   should be
   marked as such (how?) so that the PSAP knows that placed with the most recent location information the device
   has.  In mobile handsets, routing is not
   accurate.

5.10.  Uninitialized Devices often accomplished with the cell
   site and Location

   Support sector of devices that are not registered, the tower serving the call, because it can take
   many seconds to start up the location determination mechanism and don't have valid
   obtain an accurate location.

   There is a tradeoff between the time it takes to get a routing
   location and the accuracy (technically, confidence and uncertainty)
   obtained.  Routing an emergency call
   back identifiers quickly is complex.  In some jurisdictions, required.  However,
   if location can be substantially improved by waiting a short time
   (e.g. for some
   services, support sort of emergency calls from so called "uninitialized"
   devices, "quick fix"), it's preferable to wait. 3
   seconds, that is the current nominal time for example, a mobile phone which does not have quick fix, is a very
   long time to wait for help, and systems designers should attempt to
   provide accurate routing location in much less time.

   NENA recommends IP based systems complete calls in two seconds (last
   dial press to ring at PSAP).

6.7.  Conveying location in SIP

   When an active
   service contract emergency call is placed, the endpoint should put location in
   the United States signaling with the call.  That is required referred to support calls as "conveyance" to
   9-1-1.  It
   distinguish it from "configuration".  In SIP, the location
   information is attractive for such devices to conveyed following the procedures in
   [I-D.ietf-sip-location-conveyance].  The form of the location
   information obtained by the acquisition protocol may not be able the same
   as the conveyance protocol uses (PIDF-LO [RFC4119]).  Mapping by the
   endpoint to PIDF may be used in an
   emergency.  However, the requirement required.

6.8.  Location updates

   As discussed above, it make take some time for some measurement
   mechanisms to do so has caused get a huge
   number of prank calls location accurate enough for dispatch, and a
   routing location with less accuracy may be provided to get 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
   established early.  The PSAP needs the phone works.  An unitialized device that can place
   an emergency call must supply dispatch location before it
   sends the same as a fully enabled
   device.

6.  Routing the Call call to the PSAP

   Emergency calls are routed based on one or more responder.  This requires an update of the following
   criteria expressed in
   location.

   In addition, the call setup request (INVITE):

   Location:  Since each PSAP serves location of a limited geographic region and
      transferring existing calls delays mobile caller, e.g., in a vehicle or
   aircraft, can change significantly during the emergency response, calls
      need to be routed to the call.  While
   most appropriate PSAP.  In often this
      architecture, emergency call setup requests contain change is not significant, the PSAP must be able to
   get updated location
      information, expressed in civic or geospatial coordinates, information while it is processing the call.

   Subscription is preferred so that
      allows such routing.  If there the LIS notifies the PSAP when
   accurate location is updated rather than requiring a poll operation
   from the PSAP to the LIS.

   A PSAP has no or imprecise (e.g., cell
      tower and sector) information at call setup time, an on-going
      emergency call may also be transferred way to another PSAP based on
      location information that becomes available in mid-call.

   Type request an update of emergency service:  In some jurisdictions, emergency calls
      for fire, police, ambulance a location-by-value.  If
   the UAC gets new location, it must reINVITE or mountain rescue are directed UPDATE to
      just those emergency-specific PSAPs.  We support this mechanism by
      optionally labeling calls with a service identifier
      [I-D.ietf-ecrit-service-urn].
   Media capabilities of caller:  In some cases, emergency call centers supply the
   new location.

   Generally, the PSAP can wait for specific caller media preferences, such as typed text or
      video, are separate from voice systems.  Also, even if media
      capability does not affect an accurate location for dispatch.
   However, there is no fixed limit known in advance; it depends on the selection
   nature of the PSAP, there may be
      call takers within emergency.  At some point the PSAP that are specifically trained, e.g., must dispatch.  In a
   subscription environment, the PSAP could update the parameters in interactive text or sign language communications.  Again, we
      use the caller capabilities [RFC3840] mechanism
   filter (immediate response required).  In a HELD dereference, there
   is no way to label cancel and route
      such calls.

   Routing the PSAP will have to choose a ResponseTime
   that it will wait for calls by even if it wants to dispatch sooner than that.
   (Change as the discussion on ResponseTime evolves).

6.9.  Multiple locations

   Handling multiple locations is discussed in
   [I-D.ietf-geopriv-pdif-lo-profile].  Conflicting location and by service information
   is the primary function
   LoST [I-D.ietf-ecrit-lost] provides. particularly harmful if different routes (PSAPs) result from LoST accepts a query
   queries for the multiple locations.  Guidelines for dealing with
   location (by-value)
   multiple locations are also given in either civic or geo form, plus a service
   identifier, and returns an xml data structure containing [I-D.ietf-ecrit-lost].
   Generally, if a URI (or
   set of URIs) to route the call to.  Normal SIP [RFC3261] routing
   functions are used to resolve UA gets multiple locations, it must choose the URI one to
   use.  If a next hop destination.

   The endpoint can complete the LoST mapping from its proxy is inserting location at boot
   time, and periodically thereafter.  It should attempt has multiple locations, it
   must choose the one to obtain a
   "fresh" location, use.

   The ability of the UA or proxy to understand how and from that a current mapping when whom it places an
   emergency call, and if accessing either
   learned its location acquisition
   function or mapping function fails, it should use location, and include this cached value.
   The call would follow its normal outbound call processing.  Networks
   that support devices that do not implement LoST mapping themselves
   would have information element in the outbound proxy do
   location object that is sent to the mapping.  The proxy must have PSAP, provides the location call-taker
   with many pieces of the endpoint, which is often difficult information to make decisions upon, and guidance
   for what to ask the
   calling network caller and what to accurately determine.  The endpoint may have its
   location, but would not normally include it on tell the responders.

   The call signaling.
   There should indicate the location information that has been used
   for routing, so that the same location information is no used for all
   call routing decisions.  The location conveyance mechanism provided in
   [I-D.ietf-sip-location-conveyance]
   to allow contains a proxy parameter for this
   purpose.

6.10.  Location validation

   It is recommended that location must be validated prior to a device
   placing an actual emergency call; some jurisdictions require the endpoint supply location, because that would open
   this be done.  Validation in this context means both that there is a
   mapping from the endpoint address to an attack by any proxy on a PSAP and that the path PSAP understands how
   to
   get it direct responders to reveal the location.  The Proxy CAN redirect a call to  Determining the
   service URN which, if addresses that
   are valid can be difficult.  There are, for example, many cases of
   two names for the device recognized same street, or two streets with the significance, would
   include location same name in a
   city.  In some countries, the redirected call.  All networks should detect
   emergency calls and supply default location and/or routing if it is
   not already performed.

   With the URI obtained from mapping, whether by the endpoint or the
   proxy, current system provides validation.
   For example, in the proxy routes United States, the call.  Normal SIP[RFC3261] mechanisms are Master Street Address Guide
   (MSAG) records all valid street addresses and is used to route calls to the URI obtained from the LoST query.

   Often, ensure that
   the SIP routing of an emergency call will first route to an
   incoming call proxy service addresses in the domain operated by the phone billing records correspond to valid
   emergency service.
   That proxy service street addresses.  Validation is called an "Emergency Services Routing Proxy" (ESRP).

   The ESRP, which normally a concern
   for civic 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 one where there is a normal SIP proxy server, mapping.

   LoST [I-D.ietf-ecrit-lost] includes a location validation function.
   Validation should ideally be performed when a location is entered
   into a Location Information Server.  It should be confirmed
   periodically, because the mapping database undergoes slow change; new
   streets are added or removed, community names change, postal codes
   change, etc.  Endpoints may use a variety of
   PSAP state information, the location of wish to validate locations they receive
   from the caller, access network, and other
   criteria will need to onward route the call validate manually entered
   locations.  Proxies that insert location may wish to the PSAP.

7.  Signaling of Emergency Calls

   As discussed above, validate
   locations they receive from a LIS.  Test functions (Section 15)
   should also re-validate.

6.11.  Default location is carried in all emergency calls in

   Occasionally, the
   call signaling.  Since emergency calls carry privacy-sensitive
   information, they are subject to access network cannot determine the requirements for geospatial
   protocols [RFC3693]. actual location
   of the caller.  In particular, signaling information these cases, it must supply a default location.
   The default location should be
   carried in TLS, i.e., in 'sips' mode.  While requiring TLS is
   actually the way as accurate as the standards are written, it is unacceptable to
   have an emergency call fail to complete because network can
   determine.  For example, in a TLS connection was
   not created, cable network, a default location for any reason.  In many cases, persistent TLS
   connections can
   each Cable Modem Termination System (CMTS), with a representative
   location for all cable modems served by that CMTS could be maintained between elements to minimize provided
   if the time
   needed network is unable to establish them.

   The use of SIP Identity [RFC4474] resolve the subscriber to protect any unit less
   than the headers of CMTS.  Default locations must be marked as such so that the
   message could improve end-to-end integrity
   PSAP knows that the location is not accurate.

6.12.  Other location considerations

   The endpoint is responsible for mapping any form of location it
   receives from an LCP into PIDF-LO form if the information.

   Details LCP did not directly
   return a PIDF.

   To prevent against spoofing of how the DHCP server, devices implementing
   DHCP for location is carried in call signaling can be found in
   [I-D.ietf-sip-location-conveyance].

8.  Caller Preferences

   SIP Caller Preferences [RFC3841] configuration should use DHCP security mechanisms
   [RFC3118].

   Location may be used to signal how the PSAP
   should handle for routing by multiple proxy servers on the call.  For example, a language preference expressed
   path.  Mechanism such as S/MIME in an Accept-Language header may SIP signaling [RFC3261] cannot be
   used because they obscure location.  Only hop-by-hop mechanisms such
   as a hint to cause the PSAP to
   route the call to a call taker who speaks the requested language.

9.  Including a Valid Call-Back Identifier

   The call-taker TLS should be used.  Location information is sensitive and must be able to reach the emergency caller if the
   original
   protected [RFC3693].  Although support of TLS is mandatory in
   [RFC3261], many devices do not support it.  Implementing location
   conveyance in SIP mandates inclusion of TLS support.

7.  Uninitialized devices

   Support of devices that are not registered, or that don't have valid
   call back identifiers is disconnected. complex.  In traditional emergency calls,
   wireline and wireless some jurisdictions, for some
   services, support of emergency calls include a callback identifier
   for this purpose.  In SIP systems, from so-called "uninitialized"
   devices is required.  For example, cellular providers in the caller should include a
   Contact header field indicating its device URI, if available, or
   possibly a GRUU[I-D.ietf-sip-gruu] if United
   States must support calls need to be routed via 9-1-1 from a
   proxy.  This identifier would mobile phone that does not
   have an active service contract.  It is attractive for such devices
   to be used able to initiate call-backs
   immediately by the call-taker if, for example, the call is
   prematurely dropped.

   In addition, a call-back identifier should be included either as the
   URI used in an emergency.  However, the From header field [RFC3261] preferably verified by SIP
   Identity[RFC4474].  This identifier would be used requirement to initiate a call-
   back at
   do so has caused a later time and may reach the caller, not necessarily on huge number of prank calls to the
   same emergency
   service.  In some countries, it is common to attempt to place an
   emergency call from an unitialized device (and at the same location) as in the original emergency
   call.  Both local bazaars to
   prove to a would-be purchaser that the Contact and From specific requirements are detailed
   in [I-D.ietf-ecrit-phonebcp]

   Emergency phone works.  For this reason,
   PSAP authorities generally discourage support of for unititialized devices.

   An unitialized
   devices (see Section 5.10.  If an uninitialized device does that can place an emergency call, some kind of call back URI must be provided.

   Finally, there may be two other call identifiers included in an
   emergency call.  An identifier may be included which can be used to
   identify supply
   location the caller, same as opposed to the device or the subscriber of a
   specific calling service.  This identifier may fully enabled device, must carry a call back
   URI that can be used to retrieve
   information about the caller that is independent of calling service.
   For example, Alice may have home, office and mobile telephony
   services, but she is call the same Alice in all of them.  Information
   about Alice may be kept by an entity independent of any telephony
   service provider.  The caller identity is a URI device back, and is placed should have
   identifiers in a
   SIP Call-Info header [RFC3261] using the token "?" following the
   recommendations in [I-D.ietf-ecrit-phonebcp].

   The communications service provider may also include an identifier signaling that may can be used to retrieve information specific to identify the device.

8.  Routing the call held by to the service provider.  This identifier, also a URI may be placed in PSAP

   Emergency calls are routed based on one or more of the Call-Info header using following
   criteria expressed in the token "?" per
   [I-D.ietf-ecrit-phonebcp].

10.  Mid-Call Services and Behavior

   A call setup request (INVITE):
   Location:  Since each PSAP may need to REFER[RFC3515] serves a call limited geographic region and
      transferring existing calls delays the emergency response, calls
      need to a bridge for
   conferencing.  The caller should also be prepared routed to have the most appropriate PSAP.  In this
      architecture, emergency call
   transferred (usually attended, but possibly blind) as
   per[I-D.ietf-sipping-service-examples].

   While setup requests contain location
      information, expressed in a call, a number of other call features, civic or geospatial coordinates, that
      allows such as call
   waiting, must be disabled.  This routing.  If there is no or imprecise (e.g., cell
      tower and sector) information at call setup time, an on-going
      emergency call may also discussed be transferred to another PSAP based on
      location information that becomes available in
   [I-D.ietf-ecrit-phonebcp].

11.  Call Termination

   It is undesirable mid-call.
   Type of emergency service:  In some jurisdictions, emergency calls
      for the caller fire, police, ambulance or mountain rescue are directed to terminate an
      just those emergency-specific PSAPs.  This mechanism is supported
      by marking emergency call.
   Strategies calls with the proper service identifier
      [I-D.ietf-ecrit-service-urn].
   Media capabilities of caller:  In some cases, emergency call centers
      for devices to handle specific caller attempts to terminate media preferences, such as typed text or
      video, are separate from PSAPs serving voice calls.  Routing based
      on media would be accomplished at an ESRP.  Also, even if media
      capability does not affect the selection of the PSAP, there may be
   found
      call takers within the PSAP that are specifically trained, e.g.,
      in [I-D.ietf-ecrit-phonebcp]. interactive text or sign language communications, where routing
      within the PSAP call termination is
   accomplished with normal SIP call termination procedures.

12.  Media

   PSAPs should accept media streams based on RTP [RFC3550].  Traditionally,
   voice has been the only media stream accepted offer would be provided.

   Routing for calls by PSAPs.  In some
   countries, text, in location and by service is the form of BAUDOT codes primary function
   LoST [I-D.ietf-ecrit-lost] provides.  LoST accepts a query with
   location (by-value) in either civic or similar tone encoded
   signaling within geospatial form, plus a voiceband is accepted ("TTY") for persons who have
   hearing disabilities.  With the Internet comes
   service identifier, and returns a wider array URI (or set of
   potential media which a PSAP should accept.  Using SIP signaling
   includes the capability URIs) to negotiate media. route the
   call to.  Normal SIP offer/answer
   [RFC3264] negotiations should be [RFC3261] routing functions are used to agree on resolve
   the media streams URI to be used.  PSAPs should accept real-time text [RFC4103].  All PSAPs a next hop destination.

   The endpoint can complete the LoST mapping from its location at boot
   time, and periodically thereafter.  It should accept G.711 A law (and mu Law in North America) encoded voice
   as described in [RFC3551].  Newer text forms are rapidly appearing,
   with Instant Messaging now very common, PSAPs attempt to obtain a
   "fresh" location, and from that a current mapping when it places an
   emergency call.  If accessing either its location acquisition or
   mapping functions fail, it should accept IM with
   at least [RFC3428] as well as [RFC3920].

13.  Testing

   Since use this cached value.  The call
   would follow its normal outbound call processing.

   Determining when the emergency calling architecture consists of device leaves the area provided by the LoST
   service can tax small mobile devices.  For this reason, the LoST
   server should return a simple (small number of
   pieces operated by independent entities, it is important to points) polygon for
   geo reported location [I-D.ietf-geopriv-pdif-lo-profile].  This can
   be able
   to test whether an emergency call enclosing subset of the area when the reported point is likely to succeed without
   actually occupying not
   near an edge or a smaller edge section when the human resources at reported location is
   near an edge.  Civic location is uncommon for mobile devices, but
   reporting that the same mapping is good within a PSAP.  Both signaling and
   media paths need to community name, or
   even a street, may be tested since NATs very helpful for WiFi connected devices that
   roam and firewalls may allow obtain civic location from the
   session setup request to reach AP they are connected to.

   Networks that support devices that do not implement LoST mapping
   themselves would have the PSAP, while preventing outbound proxy do the
   exchange mapping.  The proxy
   must have the location of media.

   [I-D.ietf-ecrit-phonebcp] includes the endpoint, that is often difficult for
   the calling network to accurately determine.  The endpoint may have
   its location, but would not normally include it on the call
   signaling.  There is no mechanism provided in
   [I-D.ietf-sip-location-conveyance] to allow a description of an automated test
   procedure proxy to require the
   endpoint supply location, because that validates routing, signaling and media path
   continuity.  This test would be used at boot time, and whenever 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 service URN that, if the device
   recognized the significance, would include location changes enough that a new PSAP mapping is returned
   from LoST.  A manual operation for in the test redirected
   call.  All networks should also be possible.

14.  Example Call Flows

   TBD

15.  Alternatives Considered

   This is a non-normative appendix.  During discussions of emergency
   calling, a number of suggestions are commonly made.  Below, we
   discuss some of the reasons why these alternatives do not satisfy the
   requirements of detect emergency calling.

15.1.  tel URIs

   Instead of providing URIs to call calls and supply default
   location and/or routing proxies or end systems, it
   has been suggested that end systems be configured with a "tel" URI
   [RFC3966].  Such a "tel" URI would have to be routed to a
   geographically appropriate telephony gateway, as if it is unlikely that
   every building, enterprise not already performed.

   With the URI obtained from mapping, whether by the endpoint or residence will have its own gateway.
   VoIP devices can be used in networks that are completely unaware of
   VoIP services, with VoIP service providers that the
   proxy, the proxy routes the call.  Normal SIP [RFC3261] and [RFC3263]
   mechanisms are physically far
   removed used to route calls to the URI obtained from the caller's network location.  Thus, LoST
   query.

   Often, the use SIP routing of a tel
   URI simply moves the problem an emergency call will first route to an
   incoming call proxy in the outbound proxy, domain operated by the emergency service.
   That proxy is called an "Emergency Services Routing Proxy" (ESRP).
   The ESRP, which has to is a normal SIP proxy server, may use a variety of
   PSAP state information, the caller's location of the caller, and other
   criteria to determine onward route the appropriate telephony gateway.

   In addition, emergency telephone numbers are far from universal, with
   some such numbers used for non-emergency purposes elsewhere.  Thus,
   an outbound proxy would have call to ascertain the location of PSAP.  In order for the caller ESRP
   to guess whether route on media choice, the "tel" URI identifies initial INVITE has to supply an SDP
   Offer.

9.  Signaling of emergency call or some
   other number.

   Thus, "tel" URIs are not likely to be appropriate or sufficient for
   identifying calls

9.1.  Use of TLS

   As discussed above, location is carried in all emergency calls and do not, by themselves, solve in the
   call
   routing problem.

16.  Security Considerations

   Connecting ANY service signaling.  Since emergency calls carry privacy-sensitive
   information, they are subject to the Internet creates threads requirements for geospatial
   protocols [RFC3693].  In particular, signaling information should be
   carried in TLS, i.e., in 'sips' mode.  However, it is unacceptable to the service
   which did not exist before.  The
   have an emergency call service is especially
   critical compared to other services lately connected fail to the Internet.
   It must work reliably even in case of complete because a major disaster when thousands
   of citizens call TLS connection was
   not created, for help simultaneously.  Not only does any reason.  Thus the service
   need to call should be protected attempted with
   TLS, but also the liberties of if the citizens who might
   need to use TLS session establishment fails, the service must call should be considered.

   The emergency service is an obvious target for a deliberate attack,
   and specifically a denial of service attack.  Mechanisms must
   automatically retried without TLS.  In many cases, persistent TLS
   connections can be
   provided maintained between elements to help minimize the emergency networks survive such attacks while
   continuing to provide service time
   needed to genuine callers.

   Failure establish them [I-D.ietf-sip-outbound].  In other
   circumstances, use of any security mechanism should normally not prevent session resumption [RFC4507] is recommended.
   IPSEC [RFC2401] is an acceptable alternative to TLS.

9.2.  SIP signaling requirements for  User Agents

   SIP UAs that do local dial string interpretation, location, and
   emergency call to be established.  Unlike most systems, suspicious
   calls (that is, those where normal security mechanisms are not
   attempted or they fail to produce expected valid credentials) are
   normally not dropped, but are processed route will create SIP INVITE messages with the call taker made
   aware that Service
   URN in the information given (location, Request URI, the LoST-determined URI for example), may not be
   accurate.  As the discussion PSAP in Section 5 shows, providing accurate a
   Route header, and the location in the presence of a very wide variety of circumstances is
   challenging.  Exceptions may result Geolocation header.  The INVITE
   must also have appropriate call back identifiers To enable media
   sensitive routing, the call should include an SDP offer.

9.3.  SIP signaling requirements for proxy servers

   SIP Proxy servers in some of the security
   mechanisms not being path of an emergency call must be able to be deployed, and yet
   assist UAs that are unable to provide any of the location based
   routing steps and recognition of dial strings.  They are also
   expected to provide identity information may for the caller.

10.  Call backs

   The call-taker must be valid.

   When able to reach the emergency service is under deliberate attack, caller if the policies
   on
   original call acceptance may be changed.  More stringent compliance to
   security recommendations may be enforced, is disconnected.  In traditional emergency calls,
   wireline and wireless emergency calls include a callback identifier
   for this purpose.  In SIP systems, the caller must include a Contact
   header field indicating its device URI, if globally routable, or at least
   possibly a GRUU [I-D.ietf-sip-gruu] if calls with full
   security mechanisms in place may need to be processed before calls without
   them.

   The decision whether other security mechanisms should routed via a
   proxy.  This identifier would be used to initiate call-backs
   immediately by the call-taker if, for example, the call is
   prematurely dropped.  This is a change from [RFC3261] where Contact:
   is optional.

   In addition, a call-back identifier must be tried included either as the
   URI in the From header field [RFC3261] verified by SIP Identity
   [RFC4474] , or as a network asserted URI [RFC3325].  This identifier
   would be used to initiate a call-back at a later time and may reach
   the
   call be dropped depends caller, not necessarily on the policy of the citizen, same device (and at the policy of same
   location) as the original emergency call router and the policy of the PSAP and out as per normal SIP rules.

   Emergency authorities generally discourage support of the scope unitialized
   devices (see Section 7.  If an uninitialized device does place an
   emergency call, some kind of
   this document.

16.1.  Caller Authentication

   Fraudulent calls to PSAPs is call back URI must be provided (e.g. a significant concern.  Current systems
   rely on inherent security mechanisms
   GRUU) in the PSTN to make sure the
   identity of the owner of the telephone Contact: header.  It is known.  As Internet
   technologies are increasingly used useful to place calls, it is becoming
   easier be able to hide call the identity
   device back some time later as well by including some form of URI in
   a caller.  Use of the SIP Identity
   mechanism [RFC4474] is recommended.  If SIP Identity cannot be
   provided, carriers network asserted identity.

11.  Mid-call behavior

   A PSAP may need to REFER [RFC3515] a call to a bridge for
   conferencing.  The caller should make use of P-Asserted-Identity, [RFC3325]

   In keeping with established customs in circuit-switched emergency
   calling, authentication cannot also be made a prerequisite prepared to have the call
   transferred (usually attended, but possibly blind) as per
   [I-D.ietf-sipping-service-examples].

12.  Call termination

   It is undesirable for routing or
   accepting the caller to terminate an emergency call.  However, a
   PSAP call taker may be more
   suspicious termination is accomplished with normal SIP call
   termination procedures.

13.  Disabling of features

   Certain features that can be invoked while a caller and request additional information if normal call is active
   are not permitted when the call
   authenticity cannot be verified.

16.2.  Location Privacy

   Location is sensitive information, it must an emergency call.  Services such
   as Call Waiting, Call Transfer, Three Way Call and Flash Hold should
   be disabled.

   Certain features can interfere with calls from a PSAP and should be protected against
   disclosure to unauthorized persons.  In most jurisdictions placing
   disabled.  The domain of a PSAP can be determined from the domain
   answering an emergency call.  A time limit after an emergency call implies disclosure of location to all
   should be established during which any call from the entities
   needing location to properly route same domain and respond
   directed to the call.
   Nevertheless, even supplied Contact: or AoR should be accepted as a
   call-back from the PSAP.

14.  Media

   PSAPs should always accept RTP media streams [RFC3550].
   Traditionally, voice has been the only media stream accepted by
   PSAPs.  In some countries, text, in an emergency, callers the form of BAUDOT codes or
   similar tone encoded signaling within a voiceband is accepted ("TTY")
   for persons who have an expectation that
   their location will not be divulged outside hearing disabilities.  With the Internet comes a
   wider array of potential media that implied release.

   During acquisition of a PSAP should accept.  Using SIP
   signaling includes the location information, an eavesdropper or
   impersonator may obtain location.  When DHCP is used, authentication
   [RFC3118] capability to negotiate media.  Normal SIP
   offer/answer [RFC3264] negotiations should be used to protect agree on the location option.  Use of TLS
   media streams to be used.  PSAPs should accept real-time text
   [RFC4103].  All PSAPs should accept G.711 A law (and mu Law in other LCPs North
   America) encoded voice as described in [RFC3551].  Newer text forms
   are rapidly appearing, with Instant Messaging now very common, PSAPs
   should accept IM with at least [RFC3428] as well as [RFC3920].  Video
   may be used.  Similarly, TLS important to support Video Relay Service (Sign language
   interpretation) as well as modern video phones.

   Media should be used with SIP
   signaling when location kept secure, preferably by use of Secure RTP
   [RFC3711].

15.  Testing

   Since the emergency calling architecture consists of a number of
   pieces operated by independent entities, it is conveyed.  However, failure important to establish a
   security association should never be used able
   to drop test whether an emergency call.
   Rather, the operation should be attempted without the security
   mechanism.

16.3.  PSAP Impersonation

   See Section 16.4.

   With LoST-based call routing (Section 6), an attacker could modify
   the mapping entries for one or more locations, re-routing calls
   destined for them.  The security mechanisms for provisioning the data
   in the LoST database must be robust.

   LoST is likely to succeed without
   actually occupying the human resources at a distributed database, with many replicas of authoritative
   data.  An attacker may impersonate a valid LoST server PSAP.  Both signaling and supply
   fraudulent data.  An attacker
   media paths need to be tested since NATs and firewalls may also perpetrate a denial of service
   attack on LoST servers.  These issues are addressed in
   [I-D.ietf-ecrit-lost].

   Finally, allow the URI LoST returns would normally contain a domain name.
   The domain can be hijacked by several known attacks.  TLS should be
   used
   session setup request to place calls, with reach the domain name verified.  Using DNSSEC
   [RFC4033] on PSAP, while preventing the DNS entries is recommended.  As above, failure
   exchange of
   the security mechanism must not impede the processing media.

   [I-D.ietf-ecrit-phonebcp] includes a description of an emergency
   call; automated test
   procedure that validates routing, signaling and media path
   continuity.  This test would be used at boot time, and whenever the
   device location changes enough that a new PSAP mapping is returned
   from LoST.  A manual operation should proceed without security rather than
   abandoning for the call.

16.4.  Preventing Call Misdirection

   We need to prevent an emergency call reaching a destination other
   than a PSAP.  For example, a rogue UA able test should also be possible.

   The PSAP needs to intercept SIP requests
   might be able to impersonate a PSAP.

   In the absence control frequency and duration of a globally recognized certificate that ensures that the owner
   test, and since the process could be overused, it may temporarily or
   permanently suspend its operation.

   There is a legitimate PSAP, we rely on concern associated with testing during a so-called
   "avalanche-restart" event where, for example a large power outage
   affects a chain large number of trust enforced
   by the 'sips' URI schema.  The 'sips' URI schema forces each SIP hop
   to route the call only endpoints, that, when power is restored,
   all attempt to destinations supporting TLS transport.
   Each ESRP verifies that the next-hop destination chosen as described
   in Section 6 corresponds reboot and, possibly, test.  Devices need to the server certificate offered by that
   destination.

16.5.  Call Signaling Integrity

   Preventing randomize
   their initiation of a malicious outsider from manipulating call information in
   SIP requests can be assured by using "sips" (that is, TLS, hop-by-hop
   from caller boot time test to avoid the problem.

16.  Security Considerations

   Security considerations for emergency call taker.

16.6.  Media Integrity calling have been documented in
   [I-D.ietf-ecrit-security-threats], and Confidentiality

   Media integrity [I-D.barnes-geopriv-lo-sec].

   Ed.  Note: go through that doc and confidentiality can be assured by make sure any actions needed are
   captured in the use of
   SRTP[RFC3711]. BCP text.

17.  Acknowledgements

   This draft was created from a
   draft-schulzrinne-sipping-emergency-arch-02 together with sections
   from draft-polk-newton-ecrit-arch-considerations-02.

   Design Team members participating in this draft creation include
   Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger
   Marshall, Stu Goldman, Shida Schubert and Tom Taylor.  Further
   comments and input was provided by Richard Barnes, Barbara Stark and
   James Winterbottom.

18.  References

18.1.  Normative References

   [I-D.barnes-geopriv-lo-sec]
              Barnes, R., "Threats to GEOPRIV Location Objects",
              draft-barnes-geopriv-lo-sec-00 (work in progress),
              July 2007.

   [I-D.ietf-ecrit-lost]
              Hardie, T., "LoST: A Location-to-Service Translation
              Protocol", draft-ietf-ecrit-lost-05 draft-ietf-ecrit-lost-06 (work in progress),
              March
              August 2007.

   [I-D.ietf-ecrit-phonebcp]
              Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in support of Emergency  Calling",
              draft-ietf-ecrit-phonebcp-01 (work in progress),
              March 2007.

   [I-D.ietf-ecrit-requirements]
              Schulzrinne, H. and R. Marshall, "Requirements for
              Emergency Context Resolution with Internet Technologies",
              draft-ietf-ecrit-requirements-13 (work in progress),
              March 2007.

   [I-D.ietf-ecrit-security-threats]
              Taylor, T., "Security Threats and Requirements for
              Emergency Call Marking and Mapping",
              draft-ietf-ecrit-security-threats-05 (work in progress),
              August 2007.

   [I-D.ietf-ecrit-service-urn]
              Schulzrinne, H., "A Uniform Resource Name (URN) for
              Emergency and Other Well-Known Services", draft-ietf-ecrit-service-urn-06
              draft-ietf-ecrit-service-urn-07 (work in progress), March
              August 2007.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-01 (work in
              progress), July 2007.

   [I-D.ietf-geopriv-pdif-lo-profile]
              Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
              Considerations and Recommendations",
              draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),
              July 2007.

   [I-D.ietf-geopriv-revised-civic-lo]
              Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for PIDF-LO",
              draft-ietf-geopriv-revised-civic-lo-05 (work in progress),
              February 2007.

   [I-D.ietf-sip-gruu]
              Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
              (SIP)", draft-ietf-sip-gruu-14 (work in progress),
              June 2007.

   [I-D.ietf-sip-location-conveyance]
              Polk, J. and B. Rosen, "Session "Location Conveyance for the
              Session Initiation Protocol",
              draft-ietf-sip-location-conveyance-08 (work in progress),
              July 2007.

   [I-D.ietf-sip-outbound]
              Jennings, C. and R. Mahy, "Managing Client Initiated
              Connections in the Session Initiation Protocol
              Location Conveyance",
              draft-ietf-sip-location-conveyance-07  (SIP)",
              draft-ietf-sip-outbound-10 (work in progress),
              February July 2007.

   [I-D.ietf-sipping-config-framework]
              Petrie, D. and S. Channabasappa, "A Framework for Session
              Initiation Protocol User Agent Profile Delivery",
              draft-ietf-sipping-config-framework-12 (work in progress),
              June 2007.

   [I-D.rosen-iptel-dialstring]
              Rosen, B., "Dialstring parameter for the Session
              Initiation Protocol Uniform Resource  Identifier",
              draft-rosen-iptel-dialstring-05 (work in progress),
              March 2007.

   [LLDP]     IEEE, "IEEE802.1ab Station and Media Access Control",
              Dec 2004.

   [LLDP-MED]
              TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
              Endpoint Discovery".

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

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

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

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

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, October 2002.

   [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.,
              and D. Gurle, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", RFC 3428, December 2002.

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, April 2003.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              July 2003.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

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

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [RFC3856]  Rosenberg, J., "A Presence Event Package for the Session
              Initiation Protocol (SIP)", RFC 3856, August 2004.

   [RFC3920]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 3920, October 2004.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 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
              Format", RFC 4119, December 2005.

   [RFC4190]  Carlberg, K., Brown, I., and C. Beard, "Framework for
              Supporting Emergency Telecommunications Service (ETS) in
              IP Telephony", RFC 4190, November 2005.

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

   [RFC4507]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 4507, May 2006.

   [RFC4676]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4676, October 2006.

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

18.2.  Informative References

   [I-D.ietf-sipping-service-examples]
              Johnston, A., "Session Initiation Protocol Service
              Examples", draft-ietf-sipping-service-examples-12 draft-ietf-sipping-service-examples-13 (work in
              progress), January July 2007.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              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

   Brian Rosen
   NeuStar, Inc.
   470 Conrad Dr
   Mars, PA  16046
   US

   Email: br@brianrosen.net
   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone: +1 212 939 7042
   Email: hgs@cs.columbia.edu
   URI:   http://www.cs.columbia.edu

   James Polk
   Cisco Systems
   3913 Treemont Circle
   Colleyville, Texas  76034
   US

   Phone: +1-817-271-3552
   Email: jmpolk@cisco.com

   Andrew Newton
   SunRocket
   8045 Leesburg Pike, Suite 300
   Vienna,
   TranTech/MediaSolv
   4900 Seminary Road
   Alexandria, VA  22182  22311
   US

   Phone: +1 703 636 8052 845 0656
   Email: andy@hxr.us

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).