ecrit                                                           B. Rosen
Internet-Draft                                                   NeuStar
Intended status: Standards Track                                 J. Polk
Expires: September 6, 2007 March 21, 2008                                    Cisco Systems
                                                          March 05,
                                                      September 18, 2007

    Best Current Practice for Communications Services in support of
                           Emergency Calling
                    draft-ietf-ecrit-phonebcp-01.txt
                      draft-ietf-ecrit-phonebcp-02

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 September 6, 2007. March 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Requesting help in an emergency using a communications device such as
   a telephone or mobile is an accepted practice in most of the world.
   As communications devices increasingly utilize the Internet to
   interconnect and communicate, users will continue to expect to use
   such devices to request help, regardless of whether or not they
   communicate using IP.  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.

   The IETF has several efforts targeted at standardizing various
   aspects of placing emergency calls.  This memo describes best current
   practice on how devices devices, networks and services should use such
   standards to reliably make emergency calls calls.

Table of Contents

   1.  Requirements notation  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Which devices and services should support  Overview of how emergency calls are placed . .  4
   4.  Location . . . . . . . . .  3
   4.  Which devices and sevices should support emergency  calls  . .  3
   5.  Identifying an emergency call  . . . . . . . . . . . . . . . .  4
     4.1.  Endpoints learn their own location . .
   6.  Location and its role in an emergency call . . . . . . . . . .  5
     4.2.  Location Configuration Protocols
     6.1.  Types of location information  . . . . . . . . . . . . . .  5
     4.3.  Self reported
     6.2.  Location Determination . . . . . . . . . . . . . . . . . .  6
     4.4.  When Location should be Configured . .  5
       6.2.1.  User-entered location information  . . . . . . . . . .  6
     4.5.  Other  5
       6.2.2.  Access network "wire database" location considerations  .
               information  . . . . . . . . . . . . .  7
   5.  Determining an emergency call . . . . . . . .  5
       6.2.3.  End-system measured location  information  . . . . . .  6
       6.2.4.  Network measured location information  . .  7
   6.  Session Signaling . . . . . .  6
     6.3.  Who adds location, endpoint or proxy . . . . . . . . . . .  6
     6.4.  Location and references to location  . . . . .  9
     6.1.  SIP signaling requirements for User Agents . . . . . .  7
     6.5.  End system location configuration  . .  9
     6.2.  SIP signaling requirements for proxy servers and B2BUAs . 10
     6.3.  Mapping from Location to a PSAP URI . . . . . . . . .  7
     6.6.  When location should be configured . . 11
     6.4.  Routing the call . . . . . . . . . .  7
     6.7.  Conveying location in SIP  . . . . . . . . . . . 12
     6.5.  Responding to PSAP signaling . . . . .  8
     6.8.  Location updates . . . . . . . . . . 12
     6.6.  Disabling of features . . . . . . . . . . .  8
     6.9.  Multiple locations . . . . . . . 13
   7.  Location Update . . . . . . . . . . . . .  9
     6.10. Location validation  . . . . . . . . . . 13
   8.  Media . . . . . . . . .  9
     6.11. Default location . . . . . . . . . . . . . . . . . . . 14
   9.  Testing . . 10
     6.12. Other location considerations  . . . . . . . . . . . . . . 10
   7.  Uninitialized devices  . . . . . . . . . . . 14 . . . . . . . . . 10
   8.  Routing the call to the PSAP . . . . . . . . . . . . . . . . . 11
   9.  Signaling of emergency calls . . . . . . . . . . . . . . . . . 12
     9.1.  Testing Mechanism  Use of TLS . . . . . . . . . . . . . . . . . . . . 14 . . . . 12
     9.2.  SIP signaling requirements for User Agents . . . . . . . . 12
     9.3.  SIP signaling requirements for proxy servers . . . . . . . 13
   10. Security Considerations Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   11. Mid-call behavior  . . . . . . . . . . . . . . . . . . . . . . 14
   12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Threats against endpoints
   13. Disabling of features  . . . . . . . . . . . . . . . . . . . . 15
     10.2. Threats against the Emergency Service
   14. Media  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   11. Normative References
   15. Testing  . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses
   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   17. Acknowledgements . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 21

1. . . . . . . . . 17
   18. Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Appendix A.  BCP Requirements notation

   The key words "MUST", Sorted by Responsible Party  . . . . 22
     A.1.  Requirements of End Devices  . . . . . . . . . . . . . . . 22
     A.2.  Requirements of Service Providers  . . . . . . . . . . . . 30
     A.3.  Requirements of Access Networks  . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
   Intellectual Property and Copyright Statements . . . . . . . . . . 38

1.  Terminology

   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],
   [I-D.ietf-ecrit-requirements] and [I-D.ietf-ecrit-framework].

2.  Introduction

   This document describes how SIP User Agents and proxy servers support
   emergency calling, as outlined in [I-D.ietf-ecrit-framework].  Here,
   an emergency call refers to a communications session established by a
   user to a "Public Safety Answering Point" (PSAP) [I-D.ietf-ecrit-framework], which
   is a call
   center established by response agencies designed to accept emergency calls.
   We differentiate such calls from other sessions which are created by
   responders using public communications infrastructure often involving
   some kind of priority access as defined in Emergency
   Telecommunications Service (ETS) in IP Telephony [RFC4190].  By
   implication, this document describes the interface between complement the
   emergency services network present document in section headings,
   numbering and the Internet. content.  This memo also BCP succinctly describes how location may be obtained from the local
   requirements of end devices and applications, access
   infrastructure (broadband network), networks,
   service providers and thus specifies requirements PSAPs to support location in such infrastructure.

   Making an achieve globally interoperable
   emergency call involves the use of location information,
   referring to calling on the physical location Internet.

3.  Overview of the caller.  Location how emergency calls are 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 is used
   within
   placed in the call set-up signaling when a home or visited emergency calling system
   dial string is detected.  Because emergency services are local to route
   specific geographic regions, a call caller must obtain his location
   (Section 6) prior to the correct
   PSAP, as well as by the PSAP to choose the correct responder, and
   direct them to the person in need of assistance.

   The steps involved in an making emergency call from an IP based device are
   (with calls..  To get this location,
   either a rough ordering form of operation)
   1.  Device connects to access network, and obtains initial location
   2.  User dials visited location's emergency number
   3.  User device identifies call as emergency call
   4.  User measuring (e.g.  GPS) (Section Section 6.2.3) device includes
   location indication (by value in the endpoint is deployed, or by
       reference) the endpoint is configured
   (Section 6.5) with its location from the access network's Location
   Information Server (LIS).  The location is conveyed ( Section 6.7) in
   the SIP signaling with the call.  The call set-up messaging
   5.  emergency call set-up is routed to appropriate PSAP (Section 8)
   based on location of using the caller
   6.  call is established with PSAP
   7.  caller's LoST protocol [I-D.ietf-ecrit-lost])
   which maps a location is presented to PSAP operator for dispatch

   As a quick overview for a typical Ethernet connected telephone using
   SIP signaling:
   o  the phone "boots" and connects set of PSAP URIs.  Each URI resolves to its access network
   o  the phone would get location from the DHCP server [an L7 server] a
   PSAP or the first level switch's LLDP server.

   o  the phone obtains the local emergency dialstring(s) from the
      [I-D.ietf-ecrit-lost] server.
   o  It recognizes an emergency Emergency Services Routing Proxy (ESRP) which serves a
   group of PSAPs.  The call from the dialstrings and uses
      "urn:service:sos" to mark an emergency call.
   o  It would determine the PSAP's URI by using arrives at the
      [I-D.ietf-ecrit-lost] mapping server from PSAP with the location provided
   o  It would put its location
   included in the SIP INVITE as request.

4.  Which devices and sevices should support emergency  calls

   ED-1 if a PIDF-LO in user could reasonably expect to be able to place a call for
   help with the
      body of device, then the INVITE (or device or application SHOULD support
   emergency calling.

   SP-1 If a reference device or application expects to location in be able to place a Location
      header) [I-D.ietf-sip-location-conveyance] and forward the call to
      its first hop proxy.
   o  The proxy recognizes the call as an emergency call and routes the
      call using normal SIP routing mechanisms.
   o  The call is established and common media streams opened.

   Best Current Practice for SIP user agents including handling of audio
   and real-time text [RFC4103]media detailed in [RFC4504] SHOULD be
   applied.  This memo can be considered an addition to it for
   endpoints.

3.  Which devices and services should support emergency 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
   wider range of media types and provide higher functionality..  In
   general, if a user could reasonably expect to be able to call
   for
   help with the device, then help, the device or service should support
   emergency calling.  Certainly, any device or service that looks like
   and works like a telephone (wired or mobile) should support supports it SHOULD facilitate emergency
   calling, but increasingly, users have expectations that other devices
   and services should work.

   Using current (evolving) standards, devices
   calling.

   ED-2 Devices that create media sessions and exchange audio, video
   and/or text, and have the capability to establish sessions to a wide
   variety of addresses, and communicate over private IP networks or the
   Internet, should SHOULD support emergency calls.

4.  Location

   Location is central to the operation of

5.  Identifying an emergency services.  Location
   is used to route a call to the PSAP that serves the location, and it
   is used to dispatch responders to the person in need

   ED-3 Endpoints SHOULD do dial string recognition of help.  It is
   frequently the case that the user in an emergency is unable to
   provide a unique, valid location themselves.  For this reason,
   automatic location is the norm.

   In Internet dial
   strings.

   SP-2 Proxy servers SHOULD do dial string recognition of emergency calling, we "Determine" where
   dial strings if for some reason the endpoint is
   located using a variety of measurement or wiretracing methods.  We
   "Configure" endpoints does not recognize them.

   ED-4/SP-3 Emergency calls MUST be marked with their own location.  We "Map" a Service URN in the location
   to
   Request-URI of the URI to INVITE.

   ED-5/SP-4 Local dial strings MUST be recognized.

   ED-6/SP-5 Home dial strings MAY be recognized.

   ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST
   [I-D.ietf-ecrit-lost].

   ED-8 Endpoints which do not recognize emergency dial strings SHOULD
   send the call to, dial strings as per [RFC4967].

   SP-7 Proxy Servers MUST recognize emergency dial strings represented
   by [RFC4967] and we "Convey" the location SHOULD recognize dial strings represented by a tel
   URI [RFC3966].

   SP-8 Service providers MAY provide home dial strings by configuration
   [I-D.ietf-sipping-config-framework].

   ED-9 Endpoints SHOULD be able to the
   PSAP (and other elements) have home dial strings provisioned
   by configuration.

   ED-10 Devices SHOULD NOT have one button emergency calling
   initiation.

   ED-11/SP-9 All emergency services specified in
   [I-D.ietf-ecrit-service-urn] MUST be recognized.  Devices/Service
   Providers MUST be capable of recognizing all of the signaling.  These topics are
   detailed associated dial
   strings.

6.  Location and its role in [I-D.ietf-ecrit-framework].

4.1.  Endpoints learn their own location

   With an emergency call

   Location usually involves several steps to process and multiple
   elements are involved.  In Internet based communications services, determining emergency calling, where the
   caller
   endpoint is located is more problematic than in PSTN and mobile
   systems.  Existing wired phones are tethered with a wire that is
   connected directly to a call control device, a circuit switch.
   Cellular phones are tethered via a radio channel to a cell tower,
   which connects that cell phone to "Determined" using a circuit switch.  The primary
   difficulty with IP based phones is that the connectivity, whether
   wired variety of measurement or radio channel, is decoupled from the call control device.
   The communications service
   wiretracing methods.  Endpoints may not have any relationship be "Configured" with their own
   location by the access network carrier, and, with NAT and VPN tunnels, network.  In some circumstances, a proxy
   server may have no
   way to even find out who the access carrier is.

   For this reason, standards have been created for endpoints (devices)
   to obtain insert location information where it is the access network that
   knows into the location signaling on behalf of the
   endpoint.  To obtain location information,
   the endpoint can use a Location Configuration Protocol.  The endpoint location is a subscriber "Mapped" to both the access network and URI to send the communications
   service, call to,
   and thus the location is in a position to obtain its location from the
   access network, and supply it "Conveyed" to the communications service.  These
   issues, and the necessity for endpoints and access networks to
   support LCPs is detailed PSAP (and other elements) in [I-D.ietf-ecrit-framework].

4.2.
   the signaling.  Likewise, we employ Location Configuration Protocols,
   Location Mapping Protocols, and Location Conveyance Protocols

   For devices that operate on a network where the network operator
   controls the specification of every device connected to that network
   that could be used for emergency calls,
   these functions.  The Location-to-Service Translation protocol
   [I-D.ietf-ecrit-lost] is the method Location Mapping Protocol defined by which the
   IETF.

6.1.  Types of location
   is determined need not information

   There are several ways location can be an specified.  In IETF standard, but protocols,
   civic and geospatial (geo) forms are both supported.  The civic forms
   include both postal and jurisdictional fields.  A cell tower/sector
   can be any method
   that achieves the desired result.  Such represented as a method MUST point (geo or civic) or polygon.  Other forms
   of location representation must be specified, mapped into either a geo or civic
   for use in emergency calls.

   ED-12/SP-10 Endpoints and every device Service Providers MUST support it.  It is recommended that, be prepared to
   handle location represented in
   addition, the network SHOULD support one either civic or more of DHCP,
   [Placeholder for L7 LCP} geo form.

   ED-13/SP-11/AN-1 Elements MUST NOT convert (civic to geo or LLDP-MED.

   For all other devices, geo to
   civic) from the device MUST support DHCP, [Placeholder for
   L7 LCP] and LLDP-MED.  The form of location the determination mechanism
   supplied.

6.2.  Location Determination

   ED-14/AN-2 Any suitable location determination mechanism MAY be used.

6.2.1.  User-entered location information

   ED-15/AN-3 Devices and/or access network MUST networks SHOULD support at least one
   of these.

   DHCP [RFC2131] has been enhanced a manual
   method to provide "override" the location of a device.
   [RFC3825] describes how a geo-location (lat/lon/alt) may be obtained
   and [RFC4676] describes how the access network determines.
   Where a civic (street address) form of location can is provided, all fields in the PIDF-LO
   [RFC4119] and [I-D.ietf-geopriv-revised-civic-lo] MUST be
   obtained via DHCP.

   [Placeholder for HELD, RELO able to be
   specified.

6.2.2.  Access network "wire database" location  information

   AN-4 Access networks supporting copper, fiber or other L7 location determination
   methods]

   [LLDP] with [LLDP-MED] extensions provides hard wired IP
   packet service SHOULD support location configuration
   applicable in many enterprise environments.

   For devices that operate in a network where configuration.  If the network operator
   controls the specification of
   does not support location configuration, it MUST require every device connected to
   that network,
   but connects to the network attachment supports upstream networks to which
   communications devices are connected (such as any network that
   supports Ethernet connected telephones and terminal adapters), the
   method by which support end system measured location.

   AN-5 Access networks providing wire database location information
   SHOULD provide interior location data where possible.  It is determined need not be an IETF standard,
   but can
   RECOMMENDED that interior location be any method provided when spaces exceed
   approximately 650 m2.

   AN-6 Access networks (including enterprise networks) which achieves the desired result.  However,
   the network attachment MUST support at least one of DHCP [L7 LCP] or
   LLDP-MED for upstream communications devices to obtain location.  For
   smaller interior (e.g, LAN) networks, the DHCP, [L7 LCP]
   intermediate range wireless connections (typically 100m or LLDP-MED
   server should simply repeat less of
   range) and which do not support a more accurate location
   determination mechanism such as triangulation, MUST support location
   configuration which reports the location obtained from of the access
   network.  For larger networks, other mechanisms, such point as a DHCP Relay
   Agent [RFC3046] SHOULD be used to provide more accurate the
   location of
   endpoints.

4.3.  Self reported Location

   Self reported location, where a user enters location himself, is
   generally unacceptable in emergency calls, although it is being used
   prior to automatic location determination schemes being fielded.
   Local laws may govern what is acceptable in any country or area.
   Devices and/or the clients of that access networks point.

6.2.3.  End-system measured location  information

   ED-16 devices MAY support end-system measured location.  Uncertainty
   of less than 100 m with 95% confidence SHOULD be available for
   dispatch.

   ED-17/AN-7 Devices that support endpoint measuring of location MUST
   have at least a manual method to
   "override" the coarse location (<1km) capability at all times for
   routing of calls.  This mechanism MAY be a service provided by the
   access network.

6.2.4.  Network measured location information

   AN-8 Access networks MAY provide network determines.  The measured location
   determination.  Wireless access network generally only knows the which do not support network
   measured location of its demarcation point
   between MUST require all devices connected to the access network and the subscriber.  The subscriber could
   have an extended network behind the demarc unknown end-system measured location.  Uncertainty of less than 100 m
   with 95% confidence SHOULD be available for dispatch.

   AN-9 Access networks that provide network measured location MUST have
   at least a coarse location (<1km) capability at all times for routing
   of calls.

   AN-10 Access networks with range of <10M MUST provide a location to the access
   network.  A method
   mobile devices connected to account for this condition it.  The location provided SHOULD be that
   of the beacon location unless a more accurate mechanism is provided.

4.4.  When Location should be Configured

   Devices

6.3.  Who adds location, endpoint or proxy

   ED-18 Endpoints SHOULD get do location immediately after obtaining local network configuration information. themselves.

   SP-12 Proxies MAY provide location on behalf of devices it supports
   if:

   o  It is essential for has a relationship with all access networks the location device could
      connect to, and the relationship allows it to be
   determined BEFORE any VPN tunnels are established. obtain location.
   o  It is equally
   essential has an identifier that this location information is *not* overwritten can be used by any
   process engaged from establishing a VPN connection.  In other words, the established VPN access network to Chicago from
      determine the device location of the endpoint, particularly in Dallas MUST NOT
   overwrite the Dallas location for any reason especially an emergency
   call.

   It is desirable
      presence of NAT and VPN tunnels that may exist between the access
      network and the service provider.

   ED-19/SP-13 Where proxies provide location information be periodically refreshed.
   For devices which are not expected to roam, refreshing on the order
   of once per day is RECOMMENDED.  For devices which roam, refresh behalf of
   location SHOULD be more frequent, with endpoints,
   the frequency related proxy MUST provide a mechanism to supply emergency dial strings
   to the
   mobility of device if the device and recognizes them, or the ability proxy MUST track
   the location of the access network device with sufficient accuracy and timeliness to
   support the refresh operation.  There can
   be instances in which a
   device is aware able to recognize the local dial string at the time of when it moves, for example when it changes access
   points.  When this type of event occurs, the device SHOULD refresh
   its location.

   It is desirable for location information to be requested immediately
   before placing an
   emergency call.  However, if there is any delay in
   getting more recent location, the call

6.4.  Location and references to location

   ED-20 Devices SHOULD be placed with the most
   recent able to accept and forward location information the by value
   or by reference.  An end device has.  It is RECOMMENDED that
   the device receives location by reference
   (and does not wait longer than 1 sec to obtain updated location, and
   systems should ideally be designed such that the typical response is
   under 100ms.  These numbers are empirically derived, but are intended
   to keep total call signaling time below 2 seconds.  There are
   conflicts between also get the time it takes corresponding value) MUST be able to generate location when
   measuring techniques are used and the desire
   perform a dereference operation to route the call
   quickly.  If an accurate location cannot be determined quickly, obtain a
   rough value.

6.5.  End system location SHOULD be returned within 100ms which can be used to
   route the call. configuration

   ED-21 endpoints MUST support all of: DHCP Location options [RFC4676]
   and [RFC3825], HELD[I-D.ietf-geopriv-http-location-delivery] and
   LLDP-MED[LLDP-MED].

   AN-11 The location access network MUST support at least one of the nearest base station in DHCP location
   options, HELD or LLDP-MED.

   AN-12 Where a
   wireless network router is an example of employed between a rough location.

4.5.  Other location considerations

   If the LCP does not return location LAN and WAN in the form of a PIDF-LO
   [RFC4119], small
   (less than approximately 650m2), the endpoint LAN MUST map reflect the location information it receives
   from
   provided by the configuration protocol WAN to a PIDF-LO.

   To prevent against spoofing of the DHCP server, devices implementing
   DHCP for location configuration LAN.

   ED-22 Endpoints SHOULD use [RFC3118].

5.  Determining an emergency call

   An emergency call is distinguished try all LCPs supported by the device (or a downstream
   element) by an "address", which in most cases for Internet connected
   devices is still a dialstring, although other user interfaces may be
   used.

   Note: It is undesirable to have a single "button" emergency call user
   interface element.  These mechanisms have a very high false call
   rate.  PSAPs prefer devices to use their local emergency call
   dialstring.

   While any
   order or in some countries there is a single 3 digit dialstring parallel.  The first one that is
   used for all emergency calls (i.e. 911 in North America), succeeds in some
   countries there are several 3 digit numbers used for different types supplying
   location can be used.

   AN-13 Access networks that support more than one LCP MUST reply with
   the same location information (within the limits of calls.  For example, in Switzerland, 117 is used to call police,
   118 is used to call the fire brigade, and 144 is used data format
   for emergency
   medical assistance.  In other countries, there are no "short codes"
   or "service codes" the specific LCP) for 3 digit dialing of emergency services and all LCPs it supports.

6.6.  When location should be configured

   ED-23 Endpoints SHOULD obtain location immediately after obtaining
   local (PSTN) numbers are used.

   [I-D.ietf-ecrit-service-urn] introduces a universal emergency service
   URN scheme.  On network configuration information.

   ED-24 To minimize the wire, emergency calls SHOULD include this type effects of
   URI as a Route header [RFC3261].  The scheme includes a single
   emergency URN (urn:service:sos) non-bypassable VPNs, location
   configuration SHOULD be attempted before such tunnels are
   established.

   ED-25 Software which uses LCPs SHOULD locate and responder specific ones
   (urn:service:sos.police).  Using use the service:sos URN scheme,
   emergency calls actual
   hardware network interface.

   AN-14 Network administrators MUST take care in assigning IP addresses
   such that VPN address assignments can be recognized as such throughout distinguished from local
   devices (by subnet choice, for example), and LISs should not attempt
   to provide location to addresses that arrive via VPN connections.

   AN-15 Placement of NAT devices should consider the Internet.

   Devices MUST use effect of the service:sos URN scheme to mark emergency calls.

   To determine NAT
   on the LCP.

   ED-26 For devices which calls are emergency calls, some entity needs not expected to
   map a user entered dialstring into this URN scheme.  A user may
   "dial" 1-1-2, but roam, refreshing on the call would be sent to urn:service:sos.  This
   mapping
   order of once per day is SHOULD performed at the endpoint device, but MAY be
   performed at an intermediate entity (such as a SIP proxy server).

   Note: It is strongly RECOMMENDED that RECOMMENDED.

   ED-27 For devices recognize which roam, refresh of location SHOULD be more
   frequent, with the emergency
   dialstring(s) and map frequency related to the universal emergency URN.  If devices
   cannot do "dial plan interpretation", then mobility of the first signaling aware
   element (first hop proxy in SIP signaled devices) SHOULD do device
   and the
   mapping.  It is important to not require a large number ability of active
   elements handle a call before it is recognized as an emergency call

   In systems that the access network to support roaming, there may the refresh
   operation.  There can be instances in which a concept device is aware of "visited"
   and "home" networks.  Even when there
   it moves, for example when it changes access points.  When this type
   of event occurs, the device SHOULD refresh its location.

   ED-28/AN-16 It is RECOMMENDED that location determination not a "visited network", take
   longer than 250 ms to obtain routing location and systems SHOULD be
   designed such that the
   user may typical response is under 100ms.  However, as
   much as 3 seconds to obtain routing location MAY be roaming (or nomadic) tolerated if
   location accuracy can be substantially improved over what can be
   obtained in a different country from their
   home.  This gives rise to 250 ms.

6.7.  Conveying location in SIP

   ED-29/SP-14 Location sent between SIP elements MUST be conveyed using
   [I-D.ietf-sip-location-conveyance].

6.8.  Location updates

   ED-30/AN-17 Where the absolute location, or the problem accuracy of location
   of which dialstring(s) to
   recognize, the "home" or "visited"?  While endpoint may change between the "home" dialstrings
   SHOULD be recognized, it time the call is required (by law in some countries) that received at
   the "visited" dialstrings PSAP and the time dispatch is completed, location update
   mechanisms MUST be recognized.  "Visited" dialstrings
   would provided.

   ED-31/AN-18 mobile devices MUST be essential if a guest used provided with a roaming phone.  Dial plan
   interpretation may need mechanism to take "visited" emergency dialstrings into
   account.

   To give an example get
   repeated location updates to track the motion of this difference in dialstrings: If the device
   is from North America, the home and visited emergency dialstring is
   "9-1-1".  If that devices roams to the UK, the home emergency
   dialstring is still "9-1-1", but the visited emergency dialstring
   would become "9-9-9".  If during
   the device roams to Paris, complete processing of the home
   dialstring remains call.

   ED-32/AN-19 The LIS SHOULD provide a location reference which permits
   a subscription with appropriate filtering.

   ED-33/AN-20 For calls sent with location-by-reference, with a SIP or
   SIPS scheme, the same, "9-1-1", but server resolving the visited dialstring
   changes from 999 reference MUST support a
   SUBSCRIBE [RFC3118] to "1-1-2".

   The home emergency dialstrings MAY be provisioned into the device (or presence event [RFC3856].  For other element doing dialstring to universal emergency call URN
   mapping).  [I-D.ietf-ecrit-lost]) provides dialstrings for
   location-by-reference schemes, a given repeated location and SHOULD be used dereference by devices to learn the local (i.e.
   "visited" dialstrings.  "Home" dialstrings MAY be learned by
   configuration.

6.  Session Signaling

   SIP signaling [RFC3261] is expected
   PSAP MUST be supported supported.

   ED-34 If location was sent by upgraded PSAPs.
   Gateways MAY be used between Internet connected devices value, and older
   PSAPs.  Some countries may support other signaling protocols into
   PSAPs.

6.1.  SIP signaling requirements for User Agents

   The initial SIP signaling Method is an INVITE.
   1.   The Request URI SHOULD be a PSAP URI obtained from LoST (see
        Section 6.3).  If the device cannot access a LoST server, the
        To: SHOULD be a service URN in the "sos" tree.  If endpoint gets updated
   location, it MUST send the device
        cannot do local dialstring interpretation, updated location to the Request-URI PSAP via reINVITE
   or UPDATE.  Such updates SHOULD be a dialstring URI [I-D.rosen-iptel-dialstring]with the
        dialed digits.  A sips URI [RFC3261] MUST be specified, unless
        the operation must be retried due limited to no more than one update
   every 10 seconds.

6.9.  Multiple locations

   ED-35 If a failure UA has more than one location available to establish a
        TLS connection.
   2.   The To: header it, it MUST be present and SHOULD be a service URN in
        the "sos" tree.  If
   choose one location to use to route the device cannot do local dialstring
        interpretation, call towards the To: SHOULD be PSAP.

   SP-15 If a dialstring URI with proxy inserts location on behalf of an endpoint, and it
   has multiple locations available for the
        dialed digits. sips endpoint it MUST be specified, unless the operation must
        be retried due choose one
   location to a failure use to establish a TLS connection.
   3.   The From: header MUST be present and SHOULD be the AoR of route the
        caller.

        NOTE: unintialized devices may not have an AoR available
   4.   A Via: header MUST be present and SHOULD include call towards the URI of PSAP.

   SP-16 If a proxy is attempting to assert location but the
        device
   5.   A Route header SHOULD be present with UA conveyed
   a location to it, the service URN in proxy must use the
        "sos" tree, UA?s location for routing
   and MUST convey that location towards the loose route parameter.
   6.   Either PSAP.  It MAY also include
   what it believes the location to be.

   SP-17 All location objects received by a P-Asserted-Identity [RFC3325] or an Identity header
        [RFC4474], or both, SHOULD proxy MUST be included delivered to identify
   the sender.
   7.   A Contact header PSAP.

   ED-36/SP-18 Location objects MUST be present (which might contain a GRUU
        [I-D.ietf-sip-gruu]) to permit an immediate call-back to information about the
        specific device
   method by which placed the emergency call.
   8.   Other headers MAY be included location was determined, such as per normal sip behavior
   9.   A Supported: header MUST be GPS, manually
   entered, or based on access network topology included with the 'geolocation'
        option tag [I-D.ietf-sip-location-conveyance], unless the device
        does not understand in a PIDF- LO
   ?method? element.  In addition, the concept source of SIP Location.

   10.  If the device's location is by-reference, a Geolocation: header
        [I-D.ietf-sip-location-conveyance]
   information MUST be present containing included in a PIDF-LO "provided-by" element.

   ED-37/SP-19 The "used-for-routing" parameter MUST be set to the URI
   location that was used to query LoST.

6.10.  Location validation

   AN-21 Location validation of civic locations via LoST SHOULD be
   performed by the PIDF-LO reference for that device.  Whichever LIS before entering a location is used for routing in its database.

   ED-38 Endpoints SHOULD validate civic locations when they receive
   them from their LCP.  Validation SHOULD be performed in conjunction
   with the message towards LoST route query to minimize load on the PSAP or
        ESRP, even if there is only one, LoST server.

6.11.  Default location

   AN-22 When the Geolocation "message-
        routed-on-this-uri" header parameter access network cannot determine the actual location of
   the caller, it MUST supply a default location.  The default SHOULD be added
   chosen to be as close to the
        corresponding URI in probable location of the Geolocation header.
   11.  if a device understands as the SIP Location Conveyance
        [I-D.ietf-sip-location-conveyance] extension and has its
        location available, it
   network can determine.

   SP-20 Proxies handling emergency calls MUST include insert a default location either by-value or
        by-reference.  If it is by-value,
   if the INVITE contains call does not contain a
        Supported header location.

   AN-23/SP-21 Default locations MUST be marked with a "geolocation" option tag, method=Default and a "cid-
        URL" [RFC2396] as the value
   an appropriate provided-by in the Geolocation header,
        indicating which message body part contains the PIDF-LO.

6.12.  Other location considerations

   ED-39 If the
        INVITE contains a LCP does not return location by-reference, it includes in the same
        Supported header with form of a PIDF-LO
   [RFC4119], the "geolocation" option tag, and includes endpoint MUST map the URI of location information it receives
   from the PIDF-LO on a remote node in configuration protocol to a Geolocation header.
        [I-D.ietf-geopriv-pdif-lo-profile] PIDF-LO.

   ED-40/AN-24 To prevent against spoofing of the DHCP server, elements
   implementing DHCP for location configuration SHOULD use [RFC3118].

   ED-41 S/MIME MUST NOT be used
   12.  If a device understands to protect the SIP Location Conveyance extension
        and has its location unavailable Geolocation header or unknown to that device, it
   bodies.

   ED-42/SP-22 TLS MUST include a Supported header with a "geolocation" option tag,
        and not include a Geolocation header, and not include be used to protect location (but see Section 9).

7.  Uninitialized devices

   ED-43 Uninitialized devices SHOULD NOT lead a PIDF-LO
        message body.
   13.  A normal SDP offer user to believe an
   emergency call could be placed on it unless local regulations require
   it.

   ED-44/AN-25/SP-23 Uninitialized devices SHOULD NOT be included in capable of
   placing an emergency call unless local regulations require it.

   ED-45/AN-26/SP-24 Uninitialized devices that can place emergency
   calls MUST supply location the INVITE.  The offer same as a fully capable device would.

   ED-46/SP-25 Unitialized Devices MUST supply a call back URI.  See
   Section 7.

   ED-47/SP-26 Unitialized Devices MUST include identifiers in the G.711 codec, see Section 8.
   14.  If
   signaling that can be used by the service provider to identify the
   device includes location-by-value, and to allow filtering of calls from the UA MUST support
        multipart message bodies, since SDP will likely be also in device by the
        INVITE.
   15.  A UAC SHOULD include PSAP/
   ESRP.

8.  Routing the Geolocation "inserted-by=endpoint"
        header parameter.  This informs downstream elements which device
        entered call to the PSAP

   ED-48 Endpoints who obtain their own location SHOULD perform LoST
   mapping to the PSAP URI.

   ED-49 Mapping SHOULD be performed at this URI (either cid-URL or location-by-
        reference URI).

6.2.  SIP signaling requirements for proxy servers boot time and B2BUAs

   SIP Proxy servers processing emergency calls:
   1.  If whenever location
   changes beyond the proxy does dial plan interpretation on behalf of user
       agents, service boundary obtained from a prior LoST
   mapping operation or the proxy time-to-live value of that response has
   expired.  The value MUST look be cached for the local emergency dialstring possible use.

   ED-50 The endpoint SHOULD attempt to update its location at the location time
   of the end device. an emergency call.  If it finds it it MUST:
       *  Obtain the location (or cannot obtain a reference to it) for new location quickly
   (See Section 6), it MUST use the cached value.

   ED-51 The endpoint
       *  Insert a Geolocation header as per 10-12 above
       *  Include SHOULD attempt to update the Geolocation "inserted-by=server" AND "routed-by-
          this-uri" parameters.
       *  Map LoST mapping at the location to a PSAP uri using LoST.
       *  Add
   time of an emergency call.  If it cannot obtain a Route header with new mapping
   quickly, it MUST use the service URN appropriate for cached value.

   SP-27 All proxies in the outbound path SHOULD recognize emergency dialstring.

       *  Replace
   calls with a Request URI of the Request-URI (which was service URN in the dialstring) with "sos" tree.  An
   endpoint places a service URN in the
          PSAP Request URI obtained from LoST.
       *  Route to indicate that the
   endpoint understood the call using normal SIP routing mechanisms.
   2.  The "inserted-by=" header parameter MUST NOT be modified or
       deleted in transit.
   3.  If was an emergency call.  A proxy that
   processes such a Geolocation "message-routed-on-this-uri" call looks for the presence of a Route header parameter
       exists when with a new SIP server processes
   URI of a message, and PSAP.  Absence of such a Route header indicates the message
       is routing is now UAC was
   unable to be done based on another Geolocation URI
       (by-value or by-reference), invoke LoST and the "message-routed-on-this-uri"
       header parameter proxy MUST be removed from perform the old Geolocation URI LoST mapping and
       inserted
   insert a Route header with the now applicable location URI in the Geolocation
       header.

6.3.  Mapping from Location obtained.

   SP-28 To deal with old user agents that predate this specification
   and with UAs that do not have access to their own location data,
   proxies that recognize a PSAP URI

   To route call as an emergency call, we make use of the [I-D.ietf-ecrit-lost]
   mapping service which takes a location expressed by a PIDF-LO and
   returns one or more PSAP URIs.  The request includes the service URN
   which call that is used to determine which entity should receive not marked
   as such (see Section 5) MUST also perform this mapping, with the call.
   Ideally, mapping from best
   location to it has available for the endpoint.  The resulting PSAP URI
   would be accomplished
   at become the time Request URI.

   SP-29 Proxy servers performing mapping SHOULD use location obtained
   from the emergency call access network for the mapping.  If no location is placed.  However, it could
   available, a default location (see Section 6.11) MUST be that
   when the emergency occurs, the LoST supplied.

   SP-30 A proxy server is unavailable which attempts mapping and fails to the
   caller, or busy.  To guard against that, devices get a
   mapping MUST cache provide a default mapping.  The  A suitable default mapping MUST
   would be performed at boot time, and whenever the mapping obtained previously for the default location changes such that
   appropriate for the previous mapping may no longer
   valid.  To facilitate this operation, LoST provides a mechanism that
   a device caller.

   ED-52/SP-31 [RFC3261] and [RFC3263] procedures MUST be used to route
   an emergency call towards the PSAP's URI.

   ED-53 Initial INVITES MUST provide an Offer [RFC3264].

9.  Signaling of emergency calls

   ED-54 Best Current Practice for SIP user agents including handling of
   audio, video and real-time text [RFC4103] SHOULD be applied.  This
   memo can use be considered as an addition to determine when it should refresh for endpoints.

9.1.  Use of TLS

   ED-55/SP-32 sips: MUST be specified when attempting to signal an
   emergency call with SIP.

   ED-56/SP-33 If TLS session establishment fails, the mapping.
   Devices where location changes SHOULD use this mechanism call MUST be
   retried with sip:.

   ED-57/SP-34 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain
   a desired mapping.

   User agents that can obtain location information
   persistent TLS connections between elements.

   ED-58/AN-27 https: MUST perform be specified when attempting to retrieve
   location (configuration or dereferencing) with HELD.

   ED-59/AN33 If TLS session establishment fails, the
   mapping from location information to PSAP URI using
   [I-D.ietf-ecrit-lost].
   retrieveal MUST be retried with http:.

9.2.  SIP signaling requirements for User Agents

   ED-60 The mapping is performed whenever the UA
   acquires new location information that initial SIP signaling Method is outside the bounds of an INVITE:
   1.   The Request URI SHOULD be the
   current PSAP coverage region specified service URN in the LoST response or the
   time-to-live value of that response has expired.

   Determining when "sos" tree, If
        the device leaves the area provided by the LoST
   service can tax small mobile devices.  For this reason, cannot do local dial string interpretation, the LoST
   server
        Request-URI SHOULD return a simple (small number of points) polygon for
   geo reported location.  This can be an enclosing subset of the area
   when the reported point is not near an edge, or a smaller edge
   section when the reported location is near an edge.  Civic location
   is uncommon for mobile devices, but reporting that dialstring URI [RFC4967] with the same mapping
   is good within a community name, or even a street, may dialed
        digits.
   2.   The To: header MUST be very
   helpful for WiFi connected devices that roam present and obtain civic
   location from the AP they are connected to.

   All proxies in the outbound path SHOULD recognize emergency calls
   with be a Request URI of the service URN in
        the "sos" tree.  A proxy
   recognizing such a call (which indicates that  If the endpoint understood device cannot do local dial string
        interpretation, the call was an emergency call, but was unable to map its location to To: SHOULD be a PSAP URI) MUST perform dialstring URI with the LoST mapping
        dialed digits.
   3.   The From: header MUST be present and retarget SHOULD be the call to AoR of the
        caller.
   4.   A Via: header MUST be present and SHOULD include the PSAP URI (the service URN of the
        device.
   5.   A Route: header SHOULD remain as a Route header).

   To deal be present with old user agents that predate this specification a PSAP URI obtained from
        LoST (see Section 8) and with
   UAs that do not have access the loose route parameter.  A sips URI
        [RFC3261] SHOULD be specified, unless the operation must be
        retried due to their own location data, proxies that
   recognize a call as an emergency call that is not marked as such (see
   Section 5) or where the Request-URI is failure to establish a service:sos URN MUST also
   perform this mapping, with TLS connection.  If the best location it has available
        device does not do dial plan interpretation, no Route: header
        will be present.
   6.   A Contact header MUST be present which MUST be globally
        routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an
        immediate call-back to the
   endpoint.  The resulting PSAP URI would become specific device which placed the Request URI.

6.4.  Routing
        emergency call.

   7.   Other headers MAY be included as per normal sip behavior.
   8.   A Supported: header MUST be included with the call

   Normal routing mechanisms for 'geolocation'
        option tag [I-D.ietf-sip-location-conveyance], unless the specified URI should be used.  For
   SIP signaled devices, device
        does not understand the domain concept of SIP Location.
   9.   If a device understands the URI should be extracted, SIP Location Conveyance
        [I-D.ietf-sip-location-conveyance] extension and
   the DNS consulted for has its
        location available, it MUST include location either by- value or
        by-reference.
   10.  If a sip (or sips) SRV.  The resulting NAPTR, if
   present, should be used for the FQDN of device understands the server.

6.5.  Responding to PSAP signaling

   The PSAP is expected to use normal signaling (e.g.  SIP) as per IETF
   standards.  Devices SIP Location Conveyance extension
        and proxies should expect to:
   1.  Be REFERed has its location unavailable or unknown to a conference bridge; PSAPs often that device, it
        MUST include
       dispatchers, responders or specialists on a call.
   2.  Be REFERed to a secondary PSAP.  Some responder's dispatchers are
       not located in the primary PSAP.  The call may have to be
       transferred to another PSAP.  Most often this will be an attended
       transfer, or a bridged transfer.
   3.  (For devices that are Mobile) SUBSCRIBE to the Presence of the
       AoR (or equivalent for other signaling schemes) to get location
       updates.
   4.  Support Session Timer (or equivalent) to guard against session
       corruption

   Devices Supported header with an active emergency call (i.e.  SIP Dialog) a "geolocation" option tag,
        and MUST NOT
   generate include a BYE request (or equivalent for other non-SIP signaling).
   The PSAP must be the only entity that can terminate Geolocation header, and not include a call.
        PIDF-LO message body.
   11.  If the
   user "hangs up" an emergency call, the device should ring, and when
   answered, reconnect the caller to the PSAP.

   There can be a case where device understands the session signaling path is lost, SIP Location Conveyance extension
        and the
   user agent does not receive the BYE.  If the call supports LoST [I-D.ietf-ecrit-lost] then whichever location
        is hung up, the
   session timer expires, and 5 minutes elapses from used for routing the last message
   received by the device from towards the PSAP, PSAP or ESRP, even
        if there is only one, the call may Geolocation "message-routed-on- this-
        uri" header parameter SHOULD be declared lost.
   If added to the corresponding URI
        in the 5 minute interval an incoming call is received from Geolocation header.
   12.  A normal SDP offer SHOULD be included in the
   domain of INVITE.  The offer
        MUST include the PSAP, G.711 codec, see Section 14.
   13.  If the device should drop includes location-by-value, the old call and alert for UA MUST support
        multipart message bodies, since SDP will likely be also in the (new) incoming call.

6.6.  Disabling of features

   The calling device and/or service SHOULD disable outgoing call
   features such as:
   o  Call Waiting
   o  Call Transfer
   o  Three Way Call
   o  Flash hold
   o  Outbound Call Blocking

   The emergency dialstrings SHOULD NOT be permitted in Call Forward
   numbers or speed dial lists.

   The device and/or service
        INVITE.
   14.  A UAC SHOULD disable the following incoming call
   features include a "inserted-by=endpoint" header parameter
        on calls from the PSAP:
   o  Call Waiting (all kinds)
   o  Do Not Disturb
   o  Call Forward (all kinds) (if the PSAP calls back within some
      (30min) interval)

7.  Location Update

   Devices all Geolocation headers .  This informs downstream elements
        which are mobile may not be able to report an accurate
   location when an emergency call is placed.  Some deployments of
   location measurement are not always on, and when an emergency call is
   initiated, device entered the time to get an accurate "first fix" may location at this URI (either cid-URL or
        location-by-reference URI).
   15.  SIP Caller Preferences [RFC3841] MAY be several
   seconds.  That is too long to wait used to begin processing of signal how the call.
   In such cases, a fast fix, or
        PSAP should handle the location of a tower serving call.  For example, a
   wireless mobile device language preference
        expressed in an Accept-Language header may be used as a hint to route the call, with accurate
   location coming later on, after the call is answered.  It is possible
   that
        cause the PSAP that should handle to route the call once to a call taker who speaks the accurate location
   is available is different from
        requested language.

9.3.  SIP signaling requirements for proxy servers

   SP-35 SIP Proxy servers processing emergency calls:
   1.  If the PSAP serving proxy does dial plan interpretation on behalf of user
       agents, the tower or proxy MUST look for the
   first fix location.

   Mobile devices may be moving while an local emergency call is in progress.
   The PSAPs, and/or the responders may change as dialstring at
       the location changes.

   For these reasons, and others, update of location is needed.
   Generally, updates should occur after the call is completed.  The
   PSAP controls location update.  For calls sent with location-by-
   value, the PSAP MAY reINVITE the endpoint end device and MAY look for the 200 OK from home
       dialstring.  If it finds it, the
   endpoint proxy MUST:
       *  Insert a Geolocation header as per 10-12 above.  Location-by-
          reference MUST include be used because proxies may not insert bodies.
       *  Include the location.  For calls send Geolocation "inserted-by=server" AND "routed-by-
          this-uri" parameters.
       *  Map the location to a PSAP uri using LoST.

       *  Add a Route header with location-by-
   reference, the service URN appropriate for the
          emergency dialstring.
       *  Replace the Request-URI (which was the dialstring) with a the
          PSAP URI obtained from LoST.
       *  Route the call using normal SIP or SIPS scheme, routing mechanisms.
   2.  If the server resolving proxy recognizes the
   reference MUST support a SUBSCRIBE [RFC3118] to service URN in the presence event
   [RFC3856].  For other location-by-reference schemes, Request URI, and
       does not find a Route header with a repeated
   location dereference by the PSAP URI, it MUST run LoST
       routing.  If a location was provided (which should be supported.

8.  Media

   Endpoints MUST send and receive media streams on RTP [RFC3550].
   Traditionally, voice has been the only media stream accepted by
   PSAPs.  In some countries, text, in case),
       the form of BAUDOT codes or
   similar tone encoded signaling within proxy uses that location to query LoST.  The proxy may have
       to dereference a location by reference to get a value.  If a voiceband
       location is accepted ("TTY")
   for persons who have hearing disabilities.  With not present, and the Internet comes proxy can query a
   wider array of potential media LIS which a PSAP should accept.  Using SIP
   signaling includes has
       the capability to negotiate media.  Normal SIP
   offer/answer [RFC3264] negotiations MUST be used to agree on location of the
   media streams to be used.

   Endpoints supporting voice UA it MUST support G.711 A law (and mu Law in
   North America) encoded voice as described in [RFC3551].  It do so.  If no location is
   desirable present,
       and the proxy does not have access to support wideband codecs in a LIS which could provide
       location, the offer Silence suppression
   (Voice Activity Detection methods) proxy MUST supply a default location (See
       Section 6.11).  The location (in the signaling, obtained from a
       LIS, or default) MUST NOT be used on emergency
   calls.  PSAP call takers sometimes get information on what is
   happening in the background a query to determine how LoST with the service
       URN received with the call.  The resulting URI MUST be placed in
       a Route: header added to process the call.

   Newer text forms are rapidly appearing, with Instant Messaging now
   very common, endpoints supporting IM
   3.  The "inserted-by=" parameter in any Geolocation: header received
       on the call MUST support either [RFC3428] NOT be modified or
   [RFC3920].  Endpoints supporting real-time text MUST use [RFC4103]. deleted in transit.
   4.  The expectations for emergency service support for the real-time text
   medium, described proxy SHOULD NOT modify any parameters in [I-D.ietf-sipping-toip], section 7.1 Geolocation:
       headers received in the call.  It MAY add a Geolocation: header.
       Such an additional location SHOULD NOT be
   fulfilled.

   Video may used for routing; the
       location provided by the UA should be important to support Video Relay Service (Sign language
   interpretation) as well as modern video phones.  Endpoints supporting
   video used.
   5.  Either a P-Asserted-Identity [RFC3325] or an Identity header
       [RFC4474], or both, MUST support H.264 per [RFC3984].

9.  Testing

9.1.  Testing Mechanism

   INVITE requests be included to identify the sender.

10.  Call backs

   SP-36 Unitialized devices MUST have a service urn with globally routable URI in a urn parameter of "test"
   indicates
   Contact: header.

   SP-37 Unitialized devices SHOULD have a request for an automated test.  For example,
   "urn:service.sos.fire;test".  As persistent URI in standard SIP, a 200 (OK) response
   indicates that
   P-Asserted-Identity: header.

11.  Mid-call behavior

   ED-61/SP-38 During the address was recognized course of an emergency call, devices and
   proxies MUST support REFER transactions and the Referred-by: header
   [RFC3515] to:
   1.  Be REFERed to a 404 (Not found) conference bridge; PSAPs often include
       dispatchers, responders or specialists on a call.
   2.  Be REFERed to a secondary PSAP.  Some responder's dispatchers are
       not located in the primary PSAP.  The call may have to be
       transferred to another PSAP.  Most often this will be an attended
       transfer, or a bridged transfer.(For devices that
   it was not.  A 486 (Busy Here) are Mobile).

   ED-62/SP-39User agents and proxies MUST Support Session
   Timer[RFC4028] to guard against session corruption.

12.  Call termination

   ED-63 UACs with an active emergency call (i.e.  SIP Dialog) MUST NOT
   generate a BYE request (or equivalent for other non-SIP signaling).
   The PSAP must be returned if the test service
   is busy, and only entity that can terminate a 488 (Not Acceptable Here) MUST call.  If the
   user "hangs up" an emergency call, the device should alert, and when
   answered, reconnect the caller to the PSAP.

   ED-64 There can be returned if a case where the PSAP session signaling path is lost,
   and the user agent does not support receive the test mechanism.

   In its response to BYE.  If the test, call is hung up,
   and the PSAP session timer expires the call MAY include a text body
   indicating be declared lost.  If in
   the identity interval, an incoming call is received from the domain of the
   PSAP, the requested service, and device SHOULD drop the
   location reported with old call and alert for the (new)
   incoming call.  For the latter,  Dropping of the PSAP old call SHOULD
   return location-by-value even only occur if the original location delivered with
   user is attempting to hang up; the test was by-reference.

   A PSAP accepting a test domain of an incoming call SHOULD accept a media loopback
   test[I-D.ietf-mmusic-media-loopback] and SHOULD support can
   only be determined from the "rtp-pkt-
   loopback" From header, which is not reliable, and "rtp-start-loopback" options.  The user agent
   could be spoofed.  Dropping an active call by a new call with a
   spoofed From: would
   specify be a loopback attribute DoS attack.

13.  Disabling of "loopback-source", the PSAP being the
   mirror. features

   ED-65/SP-40 User Agents should expect the PSAP to loop back no more than
   3 packets of each media type accepted, after which the PSAP would
   normally send BYE.

   User agents SHOULD perform a full call test, including media
   loopback, after a disconnect and subsequent change in IP address.
   After proxys MUST disable outgoing call
   features such as:
   o  Call Waiting
   o  Call Transfer
   o  Three Way Call
   o  Flash hold
   o  Outbound Call Blocking
   when an initial IP address assignment test, a full test emergency call is established.

   ED-66/SP-41 The emergency dialstrings SHOULD NOT be
   repeated approximately every 30 days with a random interval. permitted in Call
   Forward numbers or speed dial lists.

   ED-67/SP-42 The User agents MUST NOT place a test call immediately after booting, as
   a widespread power outage Agent and subsequent restoration would impose an
   inordinate load Proxies SHOULD disable the following
   incoming call features on call backs from the PSAP:
   o  Call Waiting
   o  Do Not Disturb
   o  Call Forward (all kinds)

   ED-68 Call backs SHOULD be determined by retaining the domain of the
   PSAP which answers an outgoing emergency call routing system.

   PSAPs MAY refuse repeated requests for test and instantiating a
   timer which starts when the call is terminated.  If a call is
   received from the same device in a
   short period of time.

10.  Security Considerations

   There are no new security considerations beyond those in the
   normative references.  This memo does not introduce any new
   protocols; it specifies use of several of them.

10.1.  Threats against endpoints

   The largest threat against the endpoint is inadvertent disclosure of
   its location.  The endpoint acquires location from a Location
   Configuration Protocol.  Some of the protocols are very limited as to
   the scope which messages domain and within the protocol are distributed.  DHCP
   for example is limited timer period, sent to
   the local subnet.  LLDP is limited to Contact: or AoR used in the
   link.  The [L7 LCP] is not limited and TLS SHOULD emergency call, it should be used assumed
   to protect
   location privacy.

   The location configuration server could be spoofed, thus providing
   wrong location, and misdirecting help when an emergency a call back.  The suggested timer period is
   placed.  When DHCP is the LCP [RFC3118] SHOULD 5 minutes.

14.  Media

   ED-69 Endpoints MUST send and receive media streams on RTP [RFC3550].

   ED-70 Normal SIP offer/answer [RFC3264] negotiations MUST be used to prevent
   spoofing if possible.  LLDP server spoofing would be limited to
   devices connected to
   agree on the link and is not seen media streams to be used.

   ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law
   in North America) encoded voice as a credible threat.
   Deployments should limit hubs and downstream switches described in [RFC3551].  It is
   desirable to IP connected
   devices that could support wideband codecs in the offer.

   ED-72 Silence suppression (Voice Activity Detection methods) MUST NOT
   be used to place on emergency calls.  [L7 LCP] SHOULD
   use DIGEST authentication (or better) to identify the LIS.

   The LoST server, which  PSAP call takers sometimes get
   information on what is happening in the source of Location to PSAP URI mapping,
   and local dialstrings, could be spoofed.  Use of DHCP background to obtain the
   location of the server limits the ability determine how
   to misdirect process the user.
   LoST protocol use SHOULD include TLS with server certs to prevent
   spoofing.

   The PSAP could be spoofed.  Client SHOULD call.

   ED-73 Endpoints supporting IM MUST support either [RFC3428] or
   [RFC3920].

   ED-74 Endpoints supporting real-time text MUST use TLS with server certs
   to prevent spoofing.

10.2.  Threats against the Emergency Service [RFC4103].  The largest threats to the Emergency Service are forgery of location
   and denial of
   expectations for emergency service attacks on support for the PSAP and/or ESRP.

   To mitigate forgery of location, location object real-time text
   medium, described in [I-D.ietf-sipping-toip], section 7.1 SHOULD be signed.
   Since access networks and PSAPs are usually local
   fulfilled.

   ED-75 Endpoints supporting video MUST support H.264 per [RFC3984].

15.  Testing

   ED-76 INVITE requests to each other,
   providing a PKI should not be onerous for many residential
   deployments.  However, enterprises may deploy access networks service urn with
   location, which is to be encouraged.  PKI covering all enterprises
   within a PSAP urn parameter of "test"
   indicates a request for an automated test.  For example,
   "urn:service.sos.fire;test".  As in standard SIP, a 200 (OK) response
   indicates that the address was recognized and a 404 (Not found) that
   it was not.  A 486 (Busy Here) MUST be returned if the test service area may
   is busy, and a 488 (Not Acceptable Here) MUST be much more problematic.

   To mitigate denial returned if the PSAP
   does not support the test mechanism.

   ED-77 In its response to the test, the PSAP MAY include a text body
   (text/plain) indicating the identity of service attacks, endpoint the PSAP, the requested
   service, and the location reported with the call.  For the latter,
   the PSAP SHOULD use TLS (which
   implies TCP) in return location-by-value even if the signaling towards original
   location delivered with the LoST server test was by-reference.  If the location-
   by-reference was supplied, and the PSAP/
   ESRP.  Return routability of signaling would help significantly.  Use
   of P-Asserted-Identity or SIP Identity is also REQUIRED of calling
   networks.

11.  Normative References

   [I-D.ietf-ecrit-framework]
              Rosen, B., "Framework dereference requires credentials,
   the PSAP SHOULD use credentials supplied by the LIS for test
   purposes.  This alerts the LIS that the dereference is not for an
   actual emergency call and location hiding techniques, if they are
   being used, may be employed for this dereference.  The response MAY
   include the connected identity of the PSAP per
   [I-D.ietf-sip-connected-identity].

   ED-78 A PSAP accepting a test call SHOULD accept a media loopback
   test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-
   pkt-loopback" and "rtp-start-loopback" options.  The user agent would
   specify a loopback attribute of "loopback-source", the PSAP being the
   mirror.  User Agents should expect the PSAP to loop back no more than
   3 packets of each media type accepted (which limits the duration of
   the test), after which the PSAP would normally send BYE.

   ED-79 User agents SHOULD perform a full call test, including media
   loopback, after a disconnect and subsequent change in IP address.
   After an initial IP address assignment test, a full test SHOULD be
   repeated approximately every 30 days with a random interval.

   ED-80 User agents MUST NOT place a test call immediately after
   booting.  If the IP address changes after booting, the UA should wait
   a random amount of time (in perhaps a 30 minute period, sufficient
   for any avalanche restart to complete) and then test.

   ED-81 PSAPs MAY refuse repeated requests for test from the same
   device in a short period of time.  Any refusal is signaled with a 486
   or 488 response.

16.  Security Considerations

   Security considerations for emergency calling have been documented in
   draft-ietf-ecrit-security- threats, and the forthcoming GEOPRIV
   security document(s).

   Ed.  Note: go through that doc and make sure any actions needed are
   captured in the BCP text.

17.  Acknowledgements

   Work group members participating in the creation and review of this
   document include include Hannes Tschofenig, Ted Hardie, Marc Linsner,
   Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom,
   Roger Marshall, Barbara Stark, Richard Barnes and Peter Blatherwick.

18.  Normative References

   [I-D.ietf-ecrit-framework]
              Rosen, B., "Framework for Emergency Calling in using Internet
              Multimedia", draft-ietf-ecrit-framework-00 draft-ietf-ecrit-framework-02 (work in
              progress), October 2006. July 2007.

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

   [I-D.ietf-ecrit-service-urn]

   [I-D.ietf-ecrit-requirements]
              Schulzrinne, H., "A Uniform Resource Name 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-05
              draft-ietf-ecrit-service-urn-07 (work in progress),
              August 2006. 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-05
              draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),
              October 2006.
              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-mmusic-media-loopback]
              Hedayat, K., "An Extension to the Session Description
              Protocol (SDP) for Media Loopback",
              draft-ietf-mmusic-media-loopback-05
              draft-ietf-mmusic-media-loopback-06 (work in progress),
              September 2006.
              April 2007.

   [I-D.ietf-sip-connected-identity]
              Elwell, J., "Connected Identity in the Session Initiation
              Protocol (SIP)", draft-ietf-sip-connected-identity-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-11 draft-ietf-sip-gruu-14 (work in progress),
              October 2006.
              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-service-examples]
              Johnston, A., "Session

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

   [I-D.ietf-sipping-toip]
              Wijk, A. and G. Gybels, "Framework for real-time text over
              IP using the Session Initiation Protocol  (SIP)",
              draft-ietf-sipping-toip-07 (work in progress),
              August 2006.

   [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, "IEEE 802.1AB-2005, "IEEE802.1ab Station and Media Access Control
              Connectivity Discovery (aka Link Layer Discovery Protocol
              - LLDP)", May Control",
              Dec 2004.

   [LLDP-MED]
              TIA, "ANSI/TIA-1057, "ANSI/TIA-1057 Link Layer Discovery Protocol for - Media
              Endpoint Devices (aka LLDP-MED)", Apr 2006. Discovery".

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

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

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

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

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

   [RFC3825]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
              Configuration Protocol Option for Coordinate-based
              Location Configuration Information", RFC 3825, July 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.

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

   [RFC3984]  Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
              M., and D. Singer, "RTP Payload Format for H.264 Video",
              RFC 3984, February 2005.

   [RFC4028]  Donovan, S. and J. Rosenberg, "Session Timers in the
              Session Initiation Protocol (SIP)", RFC 4028, April 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.

   [RFC4504]  Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
              Device Requirements and Configuration", RFC 4504,
              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.

Appendix A.  BCP Requirements Sorted by Responsible Party

A.1.  Requirements of End Devices

   ED-1 if a user could reasonably expect to be able to place a call for
   help with the device, then the device or application SHOULD support
   emergency calling.

   ED-2 Devices that create media sessions and exchange audio, video
   and/or text, and have the capability to establish sessions to a wide
   variety of addresses, and communicate over private IP networks or the
   Internet, SHOULD support emergency calls

   ED-3 Endpoints SHOULD do dial string recognition of emergency dial
   strings

   ED-4 Emergency calls MUST be marked with a Service URN in the
   Request-URI of the INVITE.

   ED-5 Local dial strings MUST be recognized.

   ED-6 Home dial strings MAY be recognized.

   ED-7 Local emergency dial strings SHOULD be determined from LoST LoST
   [I-D.ietf-ecrit-lost].

   ED-8 Endpoints which do not recognize emergency dial strings SHOULD
   send dial strings as per [RFC4967].

   ED-9 Endpoints SHOULD be able to have home dial strings provisioned
   by configuration.

   ED-10 Devices SHOULD NOT have one button emergency calling
   initiation.

   ED-11 All emergency services specified in
   [I-D.ietf-ecrit-service-urn] MUST be recognized.  Devices/Service
   Providers MUST be capable of recognizing all of the associated dial
   strings.

   ED-12 Endpoints and Service Providers MUST be prepared to handle
   location represented in either civic or geo form.

   ED-13 Elements MUST NOT convert (civic to geo or geo to civic) from
   the form of location the determination mechanism supplied.

   ED-14 Any suitable location determination mechanism MAY be used.

   ED-15 Devices and/or access networks SHOULD support a manual method
   to "override" the location the access network determines.  Where a
   civic form of location is provided, all fields in the PIDF- LO
   [RFC4119] and [I-D.ietf-geopriv-revised-civic-lo] MUST be able to be
   specified.

   ED-16 devices MAY support end-system measured location.  Uncertainty
   of less than 100 m with 95% confidence SHOULD be available for
   dispatch.

   ED-17 Devices that support endpoint measuring of location MUST have
   at least a coarse location (<1km) capability at all times for routing
   of calls.  This mechanism MAY be a service provided by the access
   network.

   ED-18 Endpoints SHOULD do location configuration themselves.

   ED-20 Devices SHOULD be able to accept and forward location by value
   or by reference.  An end device that receives location by reference
   (and does not also get the corresponding value) MUST be able to
   perform a dereference operation to obtain a value.

   ED-21 endpoints MUST support all of: DHCP Location options [RFC4676]
   and [RFC3825], HELD[I-D.ietf-geopriv-http-location-delivery] and
   LLDP-MED[LLDP-MED].

   ED-22 Endpoints SHOULD try all LCPs supported by the device in any
   order or in parallel.  The first one that succeeds in supplying
   location can be used.

   ED-23 Endpoints SHOULD obtain location immediately after obtaining
   local network configuration information.

   ED-24 To minimize the effects of non-bypassable VPNs, location
   configuration SHOULD be attempted before such tunnels are
   established.

   ED-25 Software which uses LCPs SHOULD locate and use the actual
   hardware network interface.

   ED-26 For devices which are not expected to roam, refreshing on the
   order of once per day is RECOMMENDED

   ED-27 For devices which roam, refresh of location SHOULD be more
   frequent, with the frequency related to the mobility of the device
   and the ability of the access network to support the refresh
   operation.  There can be instances in which a device is aware of when
   it moves, for example when it changes access points.  When this type
   of event occurs, the device SHOULD refresh its location.

   ED-28 It is RECOMMENDED that location determination not take longer
   than 250 ms to obtain routing location and systems SHOULD be designed
   such that the typical response is under 100ms.  However, as much as 3
   seconds to obtain routing location MAY be tolerated if location
   accuracy can be substantially improved over what can be obtained in
   250 ms.

   ED-29 Location sent between SIP elements MUST be conveyed using
   [I-D.ietf-sip-location-conveyance].

   ED-30 Where the absolute location, or the accuracy of location of the
   endpoint may change between the time the call is received at the PSAP
   and the time dispatch is completed, location update mechanisms MUST
   be provided.

   ED-31 mobile devices MUST be provided with a mechanism to get
   repeated location updates to track the motion of the device during
   the complete processing of the call.

   ED-32 The LIS SHOULD provide a location reference which permits a
   subscription with appropriate filtering.

   ED-33 For calls sent with location-by-reference, with a SIP or SIPS
   scheme, the server resolving the reference MUST support a SUBSCRIBE
   [RFC3118] to the presence event [RFC3856].  For other location-by-
   reference schemes, a repeated location dereference by the PSAP MUST
   be supported.

   ED-34 If location was sent by value, and the endpoint gets updated
   location, it MUST send the updated location to the PSAP via reINVITE
   or UPDATE.  Such updates SHOULD be limited to no more than one update
   every 10 seconds.

   ED-35 If a UA has more than one location available to it, it MUST
   choose one location to use to route the call towards the PSAP.

   ED-36/ Location objects MUST contain information about the method by
   which the location was determined, such as GPS, manually entered, or
   based on access network topology included in a PIDF- LO ?method?
   element.  In addition, the source of the location information MUST be
   included in a PIDF-LO "provided-by" element.

   ED-37 The "used-for-routing" parameter MUST be set to the location
   that was used to query LoST.

   ED-38 Endpoints SHOULD validate civic locations when they receive
   them from their LCP.  Validation SHOULD be performed in conjunction
   with the LoST route query to minimize load on the LoST server.

   ED-39 If the LCP does not return location in the form of a PIDF-LO
   [RFC4119], the endpoint MUST map the location information it receives
   from the configuration protocol to a PIDF-LO.

   ED-40 To prevent against spoofing of the DHCP server, elements
   implementing DHCP for location configuration SHOULD use [RFC3118].

   ED-41 S/MIME MUST NOT be used to protect the Geolocation header or
   bodies.

   ED-42 TLS MUST be used to protect location (but see Section 9).

   ED-43 Uninitialized devices SHOULD NOT lead a user to believe an
   emergency call could be placed on it unless local regulations require
   it.

   ED-44 Uninitialized devices SHOULD NOT be capable of placing an
   emergency call unless local regulations require it.

   ED-45 Uninitialized devices that can place emergency calls MUST
   supply location the same as a fully capable device would.

   ED-46 Unitialized Devices MUST supply a call back URI.  See Section 7

   ED-47 Unitialized Devices MUST include identifiers in the signaling
   that can be used by the service provider to identify the device and
   to allow filtering of calls from the device by the PSAP/ESRP.

   ED-48 Endpoints who obtain their own location SHOULD perform LoST
   mapping to the PSAP URI.

   ED-49 Mapping SHOULD be performed at boot time and whenever location
   changes beyond the service boundary obtained from a prior LoST
   mapping operation or the time-to-live value of that response has
   expired.  The value MUST be cached for possible use.

   ED-50 The endpoint SHOULD attempt to update its location at the time
   of an emergency call.  If it cannot obtain a new location quickly
   (See Section 6), it MUST use the cached value.

   ED-51 The endpoint SHOULD attempt to update the LoST mapping at the
   time of an emergency call.  If it cannot obtain a new mapping
   quickly, it MUST use the cached value.

   ED-52 [RFC3261] and [RFC3263] procedures MUST be used to route an
   emergency call towards the PSAP's URI.

   ED-53 Initial INVITES MUST provide an Offer [RFC3264]

   ED-54 Best Current Practice for SIP user agents including handling of
   audio, video and real-time text [RFC4103] SHOULD be applied.  This
   memo can be considered as an addition to it for endpoints.

   ED-55 sips: MUST be specified when attempting to signal an emergency
   call with SIP

   ED-56 If TLS session establishment fails, the call MUST be retried
   with sip:

   ED-57 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent
   TLS connections between elements

   ED-58 https: MUST be specified when attempting to retrieve location
   (configuration or dereferencing) with HELD

   ED-59 If TLS session establishment fails, the location retrieveal
   MUST be retried with http:

   ED-60 The initial SIP signaling Method is an INVITE:
   1.   The Request URI SHOULD be the service URN in the "sos" tree, If
        the device cannot do local dialstring interpretation, the
        Request-URI SHOULD be a dialstring URI [RFC4967] with the dialed
        digits.
   2.   The To: header MUST be present and SHOULD be a service URN in
        the "sos" tree.  If the device cannot do local dialstring
        interpretation, the To: SHOULD be a dialstring URI with the
        dialed digits.
   3.   The From: header MUST be present and SHOULD be the AoR of the
        caller.
   4.   A Via: header MUST be present and SHOULD include the URI of the
        device.
   5.   A Route: header SHOULD be present with a PSAP URI obtained from
        LoST (see Section 8 ) and the loose route parameter.  A sips URI
        [RFC3261] SHOULD be specified, unless the operation must be
        retried due to a failure to establish a TLS connection.  If the
        device does not do dial plan interpretation, no Route: header
        will be present.
   6.   A Contact header MUST be present which MUST be globally
        routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an
        immediate call-back to the specific device which placed the
        emergency call.

   7.   Other headers MAY be included as per normal sip behavior.
   8.   A Supported: header MUST be included with the 'geolocation'
        option tag [I-D.ietf-sip-location-conveyance], unless the device
        does not understand the concept of SIP Location.
   9.   If a device understands the SIP Location Conveyance
        [I-D.ietf-sip-location-conveyance] extension and has its
        location available, it MUST include location either by- value or
        by-reference.
   10.  If a device understands the SIP Location Conveyance extension
        and has its location unavailable or unknown to that device, it
        MUST include a Supported header with a "geolocation" option tag,
        and MUST NOT include a Geolocation header, and not include a
        PIDF-LO message body.
   11.  If a device understands the SIP Location Conveyance extension
        and supports LoST [I-D.ietf-ecrit-lost] then whichever location
        is used for routing the message towards the PSAP or ESRP, even
        if there is only one, the Geolocation "message-routed-on- this-
        uri" header parameter SHOULD be added to the corresponding URI
        in the Geolocation header.
   12.  A normal SDP offer SHOULD be included in the INVITE.  The offer
        MUST include the G.711 codec, see Section 14.
   13.  If the device includes location-by-value, the UA MUST support
        multipart message bodies, since SDP will likely be also in the
        INVITE.
   14.  A UAC SHOULD include a "inserted-by=endpoint" header parameter
        on all Geolocation headers .  This informs downstream elements
        which device entered the location at this URI (either cid-URL or
        location-by-reference URI).
   15.  SIP Caller Preferences [RFC3841] MAY be used to signal how the
        PSAP should handle the call.  For example, a language preference
        expressed in an Accept-Language header may be used as a hint to
        cause the PSAP to route the call to a call taker who speaks the
        requested language.

   ED-61 During the course of an emergency call, devices and proxies
   MUST support REFER transactions and the Referred-by: header [RFC3515]
   to:
   1.  Be REFERed to a conference bridge; PSAPs often include
       dispatchers, responders or specialists on a call.
   2.  Be REFERed to a secondary PSAP.  Some responder's dispatchers are
       not located in the primary PSAP.  The call may have to be
       transferred to another PSAP.  Most often this will be an attended
       transfer, or a bridged transfer.(For devices that are Mobile).

   ED-62 User agents and proxies MUST Support Session Timer [RFC4028] to
   guard against session corruption.

   ED-63 UACs with an active emergency call (i.e.  SIP Dialog) MUST NOT
   generate a BYE request (or equivalent for other non-SIP signaling).
   The PSAP must be the only entity that can terminate a call.  If the
   user "hangs up" an emergency call, the device should alert, and when
   answered, reconnect the caller to the PSAP.

   ED-64 There can be a case where the session signaling path is lost,
   and the user agent does not receive the BYE.  If the call is hung up,
   and the session timer expires the call MAY be declared lost.  If in
   the interval, an incoming call is received from the domain of the
   PSAP, the device SHOULD drop the old call and alert for the (new)
   incoming call.  Dropping of the old call SHOULD only occur if the
   user is attempting to hang up; the domain of an incoming call can
   only be determined from the From header, which is not reliable, and
   could be spoofed.  Dropping an active call by a new call with a
   spoofed From: would be a DoS attack.

   ED-65 User Agents and proxys MUST disable outgoing call features such
   as:
   o  Call Waiting
   o  Call Transfer
   o  Three Way Call
   o  Flash hold
   o  Outbound Call Blocking
   when an emergency call is established.

   ED-66 The emergency dialstrings SHOULD NOT be permitted in Call
   Forward numbers or speed dial lists.

   ED-67 The User Agent and Proxies SHOULD disable the following
   incoming call features on call backs from the PSAP:
   o  Call Waiting
   o  Do Not Disturb
   o  Call Forward (all kinds)

   ED-68 Call backs SHOULD be determined by retaining the domain of the
   PSAP which answers an outgoing emergency call and instantiating a
   timer which starts when the call is terminated.  If a call is
   received from the same domain and within the timer period, sent to
   the Contact: or AoR used in the emergency call, it should be assumed
   to be a call back.  The suggested timer period is 5 minutes.

   ED-69 Endpoints MUST send and receive media streams on RTP [RFC3550].

   ED-70 Normal SIP offer/answer [RFC3264] negotiations MUST be used to
   agree on the media streams to be used.

   ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law
   in North America) encoded voice as described in [RFC3551].  It is
   desirable to support wideband codecs in the offer.

   ED-72 Silence suppression (Voice Activity Detection methods) MUST NOT
   be used on emergency calls.  PSAP call takers sometimes get
   information on what is happening in the background to determine how
   to process the call.

   ED-73 Endpoints supporting IM MUST support either [RFC3428] or
   [RFC3920].

   ED-74 Endpoints supporting real-time text MUST use [RFC4103].  The
   expectations for emergency service support for the real-time text
   medium, described in [I-D.ietf-sipping-toip], section 7.1 SHOULD be
   fulfilled.

   ED-75 Endpoints supporting video MUST support H.264 per [RFC3984].

   ED-76 INVITE requests to a service urn with a urn parameter of "test"
   indicates a request for an automated test.  For example,
   "urn:service.sos.fire;test".  As in standard SIP, a 200 (OK) response
   indicates that the address was recognized and a 404 (Not found) that
   it was not.  A 486 (Busy Here) MUST be returned if the test service
   is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP
   does not support the test mechanism.

   ED-77 In its response to the test, the PSAP MAY include a text body
   (text/plain) indicating the identity of the PSAP, the requested
   service, and the location reported with the call.  For the latter,
   the PSAP SHOULD return location-by-value even if the original
   location delivered with the test was by-reference.  If the location-
   by-reference was supplied, and the dereference requires credentials,
   the PSAP SHOULD use credentials supplied by the LIS for test
   purposes.  This alerts the LIS that the dereference is not for an
   actual emergency call and location hiding techniques, if they are
   being used, may be employed for this dereference.  The response MAY
   include the connected identity of the PSAP per
   [I-D.ietf-sip-connected-identity].

   ED-78 A PSAP accepting a test call SHOULD accept a media loopback
   test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-
   pkt-loopback" and "rtp-start-loopback" options.  The user agent would
   specify a loopback attribute of "loopback-source", the PSAP being the
   mirror.  User Agents should expect the PSAP to loop back no more than
   3 packets of each media type accepted (which limits the duration of
   the test), after which the PSAP would normally send BYE.

   ED-79 User agents SHOULD perform a full call test, including media
   loopback, after a disconnect and subsequent change in IP address.

   After an initial IP address assignment test, a full test SHOULD be
   repeated approximately every 30 days with a random interval.

   ED-80 User agents MUST NOT place a test call immediately after
   booting.  If the IP address changes after booting, the UA should wait
   a random amount of time (in perhaps a 30 minute period, sufficient
   for any avalanche restart to complete) and then test.

   ED-81 PSAPs MAY refuse repeated requests for test from the same
   device in a short period of time.  Any refusal is signaled with a 486
   or 488 response.

A.2.  Requirements of Service Providers

   SP-1 If a device or application expects to be able to place a call
   for help, the service that supports it SHOULD facilitate emergency
   calling.

   SP-2 Proxy servers SHOULD do dial string recognition of emergency
   dial strings if for some reason the endpoint does not recognize them.

   SP-3 Emergency calls MUST be marked with a Service URN in the
   Request-URI of the INVITE.

   SP-4 Local dial strings MUST be recognized.

   SP-5 Home dial strings MAY be recognized.

   SP-6 Local emergency dial strings SHOULD be determined from LoST LoST
   [I-D.ietf-ecrit-lost].

   SP-7 Proxy Servers MUST recognize emergency dial strings represented
   by [RFC4967] and SHOULD recognize dial strings represented by a tel
   URI [RFC3966].

   SP-8 Service providers MAY provide home dial strings by configuration
   [I-D.ietf-sipping-config-framework].

   SP-9 All emergency services specified in [I-D.ietf-ecrit-service-urn]
   MUST be recognized.  Devices/Service Providers MUST be capable of
   recognizing all of the associated dial strings.

   SP-10 Endpoints and Service Providers MUST be prepared to handle
   location represented in either civic or geo form.

   SP-11 Elements MUST NOT convert (civic to geo or geo to civic) from
   the form of location the determination mechanism supplied.

   SP-12 Proxies MAY provide location on behalf of devices it supports
   if:
   o  It has a relationship with all access networks the device could
      connect to, and the relationship allows it to obtain location.
   o  It has an identifier that can be used by the access network to
      determine the location of the endpoint, particularly in the
      presence of NAT and VPN tunnels that may exist between the access
      network and the service provider.

   SP-13 Where proxies provide location on behalf of endpoints, the
   proxy MUST provide a mechanism to supply emergency dia lstrings to
   the device if the device recognizes them, or the proxy MUST track the
   location of the device with sufficient accuracy and timeliness to be
   able to recognize the local dial string at the time of an emergency
   call.

   SP-14 Location sent between SIP elements MUST be conveyed using
   [I-D.ietf-sip-location-conveyance].

   SP-15 If a proxy inserts location on behalf of an endpoint, and it
   has multiple locations available for the endpoint it MUST choose one
   location to use to route the call towards the PSAP.

   SP-16 If a proxy is attempting to assert location but the UA conveyed
   a location to it, the proxy must use the UA?s location for routing
   and MUST convey that location towards the PSAP.  It MAY also include
   what it believes the location to be.

   SP-17 All location objects received by a proxy MUST be delivered to
   the PSAP.

   SP-18 Location objects MUST contain information about the method by
   which the location was determined, such as GPS, manually entered, or
   based on access network topology included in a PIDF- LO ?method?
   element.  In addition, the source of the location information MUST be
   included in a PIDF-LO "provided-by" element.

   SP-19 The "used-for-routing" parameter MUST be set to the location
   that was used to query LoST.

   SP-20 Proxies handling emergency calls MUST insert a default location
   if the call does not contain a location.

   SP-21 Default locations MUST be marked with method=Default and an
   appropriate provided-by in the PIDF-LO.

   SP-22 TLS MUST be used to protect location (but see Section 9).

   SP-23 Uninitialized devices SHOULD NOT be capable of placing an
   emergency call unless local regulations require it.

   SP-24 Uninitialized devices that can place emergency calls MUST
   supply location the same as a fully capable device would.

   SP-25 Unitialized Devices MUST supply a call back URI.  See Section 7

   SP-26 Unitialized Devices MUST include identifiers in the signaling
   that can be used by the service provider to identify the device and
   to allow filtering of calls from the device by the PSAP/ESRP.

   SP-27 All proxies in the outbound path SHOULD recognize emergency
   calls with a Request URI of the service URN in the "sos" tree.  An
   endpoint places a service URN in the Request URI to indicate that the
   endpoint understood the call was an emergency call.  A proxy that
   processes such a call looks for the presence of a Route header with a
   URI of a PSAP.  Absence of such a Route header indicates the UAC was
   unable to invoke LoST and the proxy MUST perform the LoST mapping and
   insert a Route header with the URI obtained.

   SP-28 To deal with old user agents that predate this specification
   and with UAs that do not have access to their own location data,
   proxies that recognize a call as an emergency call that is not marked
   as such (see Section 5) MUST also perform this mapping, with the best
   location it has available for the endpoint.  The resulting PSAP URI
   would become the Request URI.

   SP-29 Proxy servers performing mapping SHOULD use location obtained
   from the access network for the mapping.  If no location is
   available, a default location (see Section 6.11) MUST be supplied.

   SP-30 A proxy server which attempts mapping and fails to get a
   mapping MUST provide a default mapping.  A suitable default mapping
   would be the mapping obtained previously for the default location
   appropriate for the caller.

   SP-31 [RFC3261] and [RFC3263] procedures MUST be used to route an
   emergency call towards the PSAP's URI.

   SP-32 sips: MUST be specified when attempting to signal an emergency
   call with SIP

   SP-33 If TLS session establishment fails, the call MUST be retried
   with sip:

   SP-34 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent
   TLS connections between elements
   SP-35 SIP Proxy servers processing emergency calls:
   1.  If the proxy does dial plan interpretation on behalf of user
       agents, the proxy MUST look for the local emergency dialstring at
       the location of the end device and MAY look for the home
       dialstring.  If it finds it it MUST:
       *  Insert a Geolocation header as per 10-12 above.  Location-by-
          reference MUST be used because proxies may not insert bodies.
       *  Include the Geolocation "inserted-by=server" AND "routed-by-
          this-uri" parameters.
       *  Map the location to a PSAP uri using LoST.
       *  Add a Route header with the service URN appropriate for the
          emergency dialstring.
       *  Replace the Request-URI (which was the dialstring) with the
          PSAP URI obtained from LoST.
       *  Route the call using normal SIP routing mechanisms.
   2.  If the proxy recognizes the service URN in the Request URI, and
       does not find a Route header with a PSAP URI, it MUST run LoST
       routing.  If a location was provided (which should be the case),
       the proxy uses that location to query LoST.  The proxy may have
       to dereference a location by reference to get a value.  If a
       location is not present, and the proxy can query a LIS which has
       the location of the UA it MUST do so.  If no location is present,
       and the proxy does not have access to a LIS which could provide
       location, the proxy MUST supply a default location (See
       Section 6.11).  The location (in the signaling, obtained from a
       LIS, or default) MUST be used in a query to LoST with the service
       URN received with the call.  The resulting URI MUST be placed in
       a Route: header added to the call.
   3.  The "inserted-by=" parameter in any Geolocation: header received
       on the call MUST NOT be modified or deleted in transit.
   4.  The proxy SHOULD NOT modify any parameters in Geolocation:
       headers received in the call.  It MAY add a Geolocation: header.
       Such an additional location SHOULD NOT be used for routing; the
       location provided by the UA should be used.
   5.  Either a P-Asserted-Identity [RFC3325] or an Identity header
       [RFC4474], or both, MUST be included to identify the sender.

   SP-36 Unitialized devices MUST have a globally routable URI in a
   Contact: header

   SP-37 Unitialized devices SHOULD have a persistent URI in a
   P-Asserted-Identity: header

   SP-38 During the course of an emergency call, devices and proxies
   MUST support REFER transactions and the Referred-by: header [RFC3515]
   to:

   1.  Be REFERed to a conference bridge; PSAPs often include
       dispatchers, responders or specialists on a call.
   2.  Be REFERed to a secondary PSAP.  Some responder's dispatchers are
       not located in the primary PSAP.  The call may have to be
       transferred to another PSAP.  Most often this will be an attended
       transfer, or a bridged transfer.(For devices that are Mobile)

   SP-39User agents and proxies MUST Support Session Timer [RFC4028] to
   guard against session corruption.

   SP-40 User Agents and proxys MUST disable outgoing call features such
   as:
   o  Call Waiting
   o  Call Transfer
   o  Three Way Call
   o  Flash hold
   o  Outbound Call Blocking
   when an emergency call is established.

   SP-41 The emergency dialstrings SHOULD NOT be permitted in Call
   Forward numbers or speed dial lists.

   SP-42 The User Agent and Proxies SHOULD disable the following
   incoming call features on call backs from the PSAP:
   o  Call Waiting
   o  Do Not Disturb
   o  Call Forward (all kinds)

A.3.  Requirements of Access Networks

   AN-1 Elements MUST NOT convert (civic to geo or geo to civic) from
   the form of location the determination mechanism supplied.

   AN-2 Any suitable location determination mechanism MAY be used.

   AN-3 Devices and/or access networks SHOULD support a manual method to
   "override" the location the access network determines.  Where a civic
   form of location is provided, all fields in the PIDF- LO [RFC4119]
   and [I-D.ietf-geopriv-revised-civic-lo] MUST be able to be specified.

   AN-4 Access networks supporting copper, fiber or other hard wired IP
   packet service SHOULD support location configuration.  If the network
   does not support location configuration, it MUST require every device
   that connects to the network to support end system measured location.

   AN-5 Access networks providing wire database location information
   SHOULD provide interior location data where possible.  It is
   RECOMMENDED that interior location be provided when spaces exceed
   approximately 650 m2

   AN-6 Access networks (including enterprise networks) which support
   intermediate range wireless connections (typically 100m or less of
   range) and which do not support a more accurate location
   determination mechanism such as triangulation, MUST support location
   configuration which reports the location of the access point as the
   location of the clients of that access point.

   AN-7 Devices that support endpoint measuring of location MUST have at
   least a coarse location (<1km) capability at all times for routing of
   calls.  This mechanism MAY be a service provided by the access
   network.

   AN-8 Access networks MAY provide network measured location
   determination.  Wireless access network which do not support network
   measured location MUST require all devices connected to the network
   have end-system measured location.  Uncertainty of less than 100 m
   with 95% confidence SHOULD be available for dispatch.

   AN-9 Access networks that provide network measured location MUST have
   at least a coarse location (<1km) capability at all times for routing
   of calls.

   AN-10 Access networks with range of <10M MUST provide a location to
   mobile devices connected to it.  The location provided SHOULD be that
   of the beacon location unless a more accurate mechanism is provided.

   AN-11 The access network MUST support at least one of DHCP location
   options, HELD or LLDP-MED.

   AN-12 Where a router is employed between a LAN and WAN in a small
   (less than approximately 650m2), the LAN MUST reflect the location
   provided by the WAN to the LAN.

   AN-13 Access networks that support more than one LCP MUST reply with
   the same location information (within the limits of the data format
   for the specific LCP) for all LCPs it supports.

   AN-14 Network administrators MUST take care in assigning IP addresses
   such that VPN address assignments can be distinguished from local
   devices (by subnet choice, for example), and LISs should not attempt
   to provide location to addresses that arrive via VPN connections.

   AN-15 Placement of NAT devices should consider the effect of the NAT
   on the LCP.

   AN-16 It is RECOMMENDED that location determination not take longer
   than 250 ms to obtain routing location and systems SHOULD be designed
   such that the typical response is under 100ms.  However, as much as 3
   seconds to obtain routing location MAY be tolerated if location
   accuracy can be substantially improved over what can be obtained in
   250 ms.

   AN-17 Where the absolute location, or the accuracy of location of the
   endpoint may change between the time the call is received at the PSAP
   and the time dispatch is completed, location update mechanisms MUST
   be provided.

   AN-18 mobile devices MUST be provided with a mechanism to get
   repeated location updates to track the motion of the device during
   the complete processing of the call.

   AN-19 The LIS SHOULD provide a location reference which permits a
   subscription with appropriate filtering.

   AN-20 For calls sent with location-by-reference, with a SIP or SIPS
   scheme, the server resolving the reference MUST support a SUBSCRIBE
   [RFC3118] to the presence event [RFC3856].  For other location-by-
   reference schemes, a repeated location dereference by the PSAP MUST
   be supported.

   AN-21 Location validation of civic locations via LoST SHOULD be
   performed by the LIS before entering a location in its database.

   AN-22 When the access network cannot determine the actual location of
   the caller, it MUST supply a default location.  The default SHOULD be
   chosen to be as close to the probable location of the device as the
   network can determine.

   AN-23 Default locations MUST be marked with method=Default and an
   appropriate provided-by in the PIDF-LO.

   AN-24 To prevent against spoofing of the DHCP server, elements
   implementing DHCP for location configuration SHOULD use [RFC3118].

   AN-25 Uninitialized devices SHOULD NOT be capable of placing an
   emergency call unless local regulations require it.

   AN-26 Uninitialized devices that can place emergency calls MUST
   supply location the same as a fully capable device would.

   AN-27 https: MUST be specified when attempting to retrieve location
   (configuration or dereferencing) with HELD

Authors' Addresses

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

   Phone: +1 724 382 1051
   Email: br@brianrosen.net

   James M. Polk
   Cisco Systems
   3913 Treemont Circle
   Colleyville, TX  76034
   US

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

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