doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc6881.txt b/doc/rfc/rfc6881.txt
new file mode 100644
index 0000000..db837ae
--- /dev/null
+++ b/doc/rfc/rfc6881.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          B. Rosen
+Request for Comments: 6881                                       NeuStar
+BCP: 181                                                         J. Polk
+Category: Best Current Practice                            Cisco Systems
+ISSN: 2070-1721                                               March 2013
+
+
+          Best Current Practice for Communications Services in
+                      Support of Emergency Calling
+
+Abstract
+
+   The IETF and other standards organizations have efforts targeted at
+   standardizing various aspects of placing emergency calls on IP
+   networks.  This memo describes best current practice on how devices,
+   networks, and services using IETF protocols should use such standards
+   to make emergency calls.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6881.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Rosen & Polk              Best Current Practice                 [Page 1]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+   3. Overview of How Emergency Calls Are Placed ......................3
+   4. Which Devices and Services Should Support Emergency Calls? ......4
+   5. Identifying an Emergency Call ...................................4
+   6. Location and Its Role in an Emergency Call ......................5
+      6.1. Types of Location Information ..............................6
+      6.2. Location Determination .....................................6
+           6.2.1. User-Entered Location Information ...................6
+           6.2.2. Access Network "Wire Database" Location
+                  Information .........................................6
+           6.2.3. End System Measured Location Information ............7
+           6.2.4. Network Measured Location Information ...............7
+      6.3. Who Adds Location?  The Endpoint, or the Proxy? ............8
+      6.4. Location and References to Location ........................8
+      6.5. End System Location Configuration ..........................8
+      6.6. When Location Should Be Configured ........................10
+      6.7. Conveying Location ........................................11
+      6.8. Location Updates ..........................................11
+      6.9. Multiple Locations ........................................12
+      6.10. Location Validation ......................................12
+      6.11. Default Location .........................................13
+      6.12. Other Location Considerations ............................13
+   7. LIS and LoST Discovery .........................................13
+   8. Routing the Call to the PSAP ...................................14
+   9. Signaling of Emergency Calls ...................................15
+      9.1. Use of TLS ................................................15
+      9.2. SIP Signaling Requirements for User Agents ................16
+      9.3. SIP Signaling Requirements for Proxy Servers ..............17
+   10. Callbacks .....................................................18
+   11. Mid-Call Behavior .............................................19
+   12. Call Termination ..............................................19
+   13. Disabling of Features .........................................19
+   14. Media .........................................................20
+   15. Testing .......................................................21
+   16. Security Considerations .......................................22
+   17. IANA Considerations ...........................................22
+      17.1. Test Service URN .........................................22
+      17.2. 'test' Subregistry .......................................23
+   18. Acknowledgements ..............................................23
+   19. References ....................................................23
+      19.1. Normative References .....................................23
+      19.2. Informative References ...................................27
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                 [Page 2]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+1.  Introduction
+
+   This document describes how access networks, Session Initiation
+   Protocol [RFC3261] user agents, proxy servers, and Public Safety
+   Answering Points (PSAPs) support emergency calling, as outlined in
+   [RFC6443], which is designed to complement the present document in
+   section headings, numbering, and content.  Understanding [RFC6443] is
+   necessary to understand this document.  This Best Current Practice
+   (BCP) succinctly describes the requirements of end devices and
+   applications (requirements prefaced by "ED-"), access networks
+   (including enterprise access networks) (requirements prefaced by
+   "AN-"), service providers (requirements prefaced by "SP-"), and PSAPs
+   to achieve globally interoperable emergency calling on the Internet.
+
+   This document also defines requirements for "intermediate" devices
+   that exist between end devices or applications and the access
+   network.  For example, a home router is an intermediate device.
+   Reporting location on an emergency call (see Section 6) may depend on
+   the ability of such intermediate devices to meet the requirements
+   prefaced by "INT-".
+
+   The access network requirements apply to those networks that may be
+   used to place emergency calls using IETF protocols.  Local
+   regulations may impact the need to support this document's access
+   network requirements.
+
+   Other organizations, such as the National Emergency Number
+   Association (NENA), define the PSAP interface.  NENA's documents
+   reference this document.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   This document uses terms from [RFC3261], [RFC5012], and [RFC6443].
+
+3.  Overview of How Emergency Calls Are Placed
+
+   An emergency call can be distinguished (Section 5) from any other
+   call by a unique service URN [RFC5031] that is placed in the call
+   setup signaling when a home or visited emergency dial string is
+   detected.  Because emergency services are local to specific
+   geographic regions, a caller must obtain his location (Section 6)
+   prior to making emergency calls.  To get this location, either a form
+   of measuring (e.g., GPS) ([RFC6443] Section 6.2.3) device location in
+
+
+
+Rosen & Polk              Best Current Practice                 [Page 3]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   the endpoint is deployed or 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 is routed (Section 8) based on
+   location using the Location-to-Service Translation (LoST) protocol
+   [RFC5222], which maps a location to a set of PSAP URIs.  Each URI
+   resolves to a PSAP or an Emergency Services Routing Proxy (ESRP) that
+   serves a group of PSAPs.  The call arrives at the PSAP with the
+   location included in the SIP INVITE request.
+
+4.  Which Devices and Services Should Support Emergency Calls?
+
+   ED-1:  A device or application that implements SIP calling SHOULD
+      support emergency calling.  Some jurisdictions have regulations
+      governing which devices need to support emergency calling, and
+      developers are encouraged to ensure that devices they develop meet
+      relevant regulatory requirements.  Unfortunately, the natural
+      variation in those regulations also makes it impossible to
+      accurately describe the cases when developers do or do not have to
+      support emergency calling.
+
+   SP-1:  If a device or application expects to be able to place a call
+      for help, the service provider that supports it MUST facilitate
+      emergency calling.  Some jurisdictions have regulations governing
+      this.
+
+   ED-2:  Devices that create media sessions and exchange real-time
+      audio, video, and/or text and that 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.  Some jurisdictions have regulations governing this.
+
+5.  Identifying an Emergency Call
+
+   ED-3:  Endpoints SHOULD recognize dial strings of emergency calls.
+      If the service provider always knows the location of the device
+      (the correct dial string depends on which country a caller is in),
+      the service provider may recognize them; see SP-2.
+
+   SP-2:  Proxy servers SHOULD recognize emergency dial strings if for
+      some reason the endpoint does not recognize them.
+
+   ED-4/SP-3:  Emergency calls MUST be marked with a service URN in the
+      Request-URI of the INVITE.
+
+   ED-5/SP-4:  Geographically local dial strings MUST be recognized.
+
+
+
+
+
+Rosen & Polk              Best Current Practice                 [Page 4]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   ED-6/SP-5:  Devices MUST be able to be configured with the home
+      country from which the home dial string(s) can be determined.
+
+   ED-7/SP-6:  Emergency dial strings SHOULD be determined from LoST
+      [RFC5222].  Dial strings MAY be configured directly into the
+      device.
+
+   AN-1:  LoST servers MUST return dial strings for emergency services.
+
+   ED-8:  Endpoints that do not recognize emergency dial strings SHOULD
+      send dial strings as per [RFC4967].
+
+   SP-7:  If a proxy server recognizes dial strings on behalf of its
+      clients, it MUST recognize emergency dial strings represented by
+      [RFC4967] and SHOULD recognize the emergency dial strings
+      represented by a tel URI [RFC3966].
+
+   ED-9:  Endpoints SHOULD be able to have home dial strings
+      provisioned.
+
+   SP-8:  Service providers MAY provision home dial strings in devices.
+
+   ED-10:  Devices SHOULD NOT have one-button emergency calling
+      initiation.
+
+   ED-11/SP-9:  All sub-services for the 'sos' service specified in
+      [RFC5031] MUST be recognized.
+
+6.  Location and Its Role in an Emergency Call
+
+   Handling location for emergency calling usually involves several
+   steps to process, and multiple entities are involved.  In Internet
+   emergency calling, where the endpoint is located is determined using
+   a variety of measurement or wire-tracing methods.  Endpoints can be
+   configured with their own location by the access network.  In some
+   circumstances, a proxy server can insert location into the signaling
+   on behalf of the endpoint.  The location is mapped to the URI to send
+   the call to, and the location is conveyed to the PSAP (and other
+   entities) in the signaling.  Likewise, we employ Location
+   Configuration Protocols (LCPs), the Location-to-Service Mapping
+   Protocol, and Location Conveyance Protocols for these functions.  The
+   Location-to-Service Translation protocol [RFC5222] is the Location
+   Mapping Protocol defined by the IETF.
+
+
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                 [Page 5]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+6.1.  Types of Location Information
+
+   There are several forms of location.  All IETF location configuration
+   and location conveyance protocols support both civic and geospatial
+   (geo) forms.  The civic forms include both postal and jurisdictional
+   fields.  A cell tower/sector can be represented as a point (geo or
+   civic) or polygon.  Endpoints, intermediate devices, and service
+   providers receiving other forms of location representation MUST map
+   them into either a geo or civic for use in emergency calls.
+
+   ED-12/INT-1/SP-10:  Endpoints, intermediate devices, and service
+      providers MUST be prepared to handle location represented in
+      either civic or geo form.
+
+   ED-13/INT-2/SP-11/AN-2:  Entities MUST NOT convert (civic to geo or
+      geo to civic) from the form of location that the determination
+      mechanism (see Section 6.2) supplied prior to receipt by the PSAP.
+
+6.2.  Location Determination
+
+   ED-14/INT-3/AN-3:  Any location determination mechanism MAY be used,
+      provided the accuracy of the location meets local requirements.
+
+6.2.1.  User-Entered Location Information
+
+   ED-15/INT-4/AN-4:  Devices, intermediate devices, and/or access
+      networks SHOULD support a manual method to override the location
+      the access network determines.  When the override location is
+      supplied in civic form, it MUST be possible for the resultant
+      Presence Information Data Format Location Object (PIDF-LO)
+      received at the PSAP to contain any of the elements specified in
+      [RFC4119] and [RFC5139].
+
+6.2.2.  Access Network "Wire Database" Location Information
+
+   AN-5:  Access networks supporting copper, fiber, or other hard-wired
+      IP packet services SHOULD support location configuration.  If the
+      network does not support location configuration, it MUST require
+      every device or intermediate device that connects to the network
+      to support end system measured location.
+
+   AN-6/INT-5:  Access networks and intermediate devices providing wire
+      database location information SHOULD provide interior location
+      data (building, floor, room, cubicle) where possible.  It is
+      RECOMMENDED that interior location be provided when spaces exceed
+      approximately 650 square meters.  See [RFC6443] Section 6.2.2 for
+      a discussion of how this value was determined.
+
+
+
+
+Rosen & Polk              Best Current Practice                 [Page 6]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   AN-7/INT-6:  Access networks and intermediate devices (including
+      enterprise networks) that support intermediate range wireless
+      connections (typically 100 m or less of range) and that do not
+      support a more accurate location determination mechanism such as
+      triangulation MUST support location configuration where the
+      location of the access point is reflected as the location of the
+      clients of that access point.
+
+   AN-8/INT-7:  Where the access network provides location
+      configuration, intermediate devices MUST either be transparent to
+      it or provide an interconnected client for the supported
+      configuration mechanism and a server for a configuration protocol
+      supported by end devices downstream of the intermediate device
+      such that the location provided by the access network is available
+      to clients as if the intermediate device was not in the path.
+
+6.2.3.  End System Measured Location Information
+
+   ED-16/INT-8:  Devices MAY support end system measured location.  See
+      [RFC6443] Section 6 for a discussion of accuracy of location.
+
+   ED-17/INT-9/AN-9:  Devices that support endpoint measuring of
+      location MUST have at least a coarse location capability
+      (typically <1 km accuracy) for the routing of calls.  The location
+      mechanism MAY be a service provided by the access network.
+
+6.2.4.  Network Measured Location Information
+
+   AN-10:  Access networks MAY provide network measured location
+      determination.  Wireless access networks that do not supply
+      network measured location MUST require every device or
+      intermediate device connected to the network to support end system
+      measured location.  Uncertainty and confidence may be specified by
+      local regulation.  Where not specified, uncertainty of less than
+      100 meters with 95% confidence is RECOMMENDED for dispatch
+      location.
+
+   AN-11:  Access networks that provide network measured location MUST
+      have at least a coarse location (typically <1 km when not location
+      hiding) capability at all times for the routing of calls.
+
+   AN-12:  Access networks with a range of <10 meters (e.g., personal
+      area networks such as Bluetooth) MUST provide a location to mobile
+      devices connected to them.  The location provided SHOULD be that
+      reported by the upstream access network unless a more accurate
+      mechanism is available.
+
+
+
+
+
+Rosen & Polk              Best Current Practice                 [Page 7]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+6.3.  Who Adds Location?  The Endpoint, or the Proxy?
+
+   ED-18/INT-10:  Endpoints SHOULD attempt to configure their own
+      location using the Location Configuration Protocols (LCPs) listed
+      in ED-21.
+
+   SP-12: Proxies MAY provide location on behalf of devices if:
+
+   o  The proxy has a relationship with all access networks the device
+      could connect to, and the relationship allows it to obtain
+      location.
+
+   o  The proxy has an identifier, such as an IP address, that can be
+      used by the access network to determine the location of the
+      endpoint, even in the presence of NAT and VPN tunnels that may
+      obscure the identifier between the access network and the service
+      provider.
+
+   ED-19/INT-11/SP-13:  Where proxies provide location on behalf of
+      endpoints, the service provider MUST ensure that either the end
+      device is provided with the local dial strings for its current
+      location (where the end device recognizes dial strings) or the
+      service provider proxy MUST detect the appropriate local dial
+      strings at the time of the call.
+
+6.4.  Location and References to Location
+
+   ED-20/INT-12:  Devices SHOULD be able to accept and forward location-
+      by-value or location-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.
+
+6.5.  End System Location Configuration
+
+   Obtaining location from the access network may be preferable even if
+   the device can measure its own location, especially indoors where
+   most measurement mechanisms are not accurate enough.  The
+   requirements listed in this section do not apply to devices that can
+   accurately measure their own location.
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                 [Page 8]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   ED-21/INT-13:  Devices MUST support both the Dynamic Host
+      Configuration Protocol (DHCP) location options [RFC4776] [RFC6225]
+      and HTTP-Enabled Location Delivery (HELD) [RFC5985].  When devices
+      deploy a specific access network interface for which location
+      configuration mechanisms such as Link Layer Discovery Protocol -
+      Media Endpoint Discovery (LLDP-MED) [LLDP-MED] or 802.11v are
+      specified, the device SHOULD support the additional respective
+      access network specific location configuration mechanism.
+
+   AN-13/INT-14:  The access network MUST support either DHCP location
+      options or HELD.  The access network SHOULD support other location
+      configuration technologies that are specific to the type of access
+      network.
+
+   AN-14/INT-15:  Where a router is employed between a LAN and WAN in a
+      small (less than approximately 650 square meters) area, the router
+      MUST be transparent to the location provided by the WAN to the
+      LAN.  This may mean the router must obtain location as a client
+      from the WAN and supply an LCP server to the LAN with the location
+      it obtains.  Where the area is larger, the LAN MUST have a
+      location configuration mechanism satisfying the requirements of
+      this document.
+
+   ED-22/INT-16:  Endpoints SHOULD try all LCPs supported by the device
+      in any order or in parallel.  The first one that succeeds in
+      supplying location MUST be used.
+
+   AN-15/INT-17:  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.
+
+   ED-23/INT-18/SP-14:  When HELD is the LCP, the request MUST specify a
+      value of "emergencyRouting" for the "responseTime" parameter and
+      use the resulting location for routing.  If a value for dispatch
+      location will be sent, another request with the "responseTime"
+      parameter set to "emergencyDispatch" must be completed, with the
+      result sent for dispatch purposes.
+
+   ED-24:  Where the operating system supporting application programs
+      that need location for emergency calls does not allow access to
+      Layer 2 and Layer 3 functions necessary for a client application
+      to use DHCP location options and/or other location technologies
+      that are specific to the type of access network, the operating
+      system MUST provide a published API conforming to ED-12 through
+      ED-23 and ED-25 through ED-32.  It is RECOMMENDED that all
+      operating systems provide such an API.
+
+
+
+
+
+Rosen & Polk              Best Current Practice                 [Page 9]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+6.6.  When Location Should Be Configured
+
+   If an endpoint is manually configured, the requirements in this
+   section are not applicable.
+
+   ED-25/INT-19:  Endpoints SHOULD obtain location immediately after
+      obtaining local network configuration information.
+
+   ED-26/INT-20:  If the device is configured to use DHCP for
+      bootstrapping and does not use its own measurement to determine
+      location, it MUST include both options for location acquisition
+      (civic and geodetic), the option for LIS discovery, and the option
+      for LoST discovery as defined in [RFC4776], [RFC6225], [RFC5986],
+      and [RFC5223], respectively.
+
+   ED-27/INT-21:  If the device sends a DHCPINFORM message, it MUST
+      include both options for location acquisition (civic and
+      geodetic), the option for LIS discovery, and the option for LoST
+      discovery as defined in [RFC4776], [RFC6225], [RFC5986], and
+      [RFC5223], respectively.
+
+   ED-28/INT-22:  To minimize the effects of VPNs that do not allow
+      packets to be sent via the native hardware interface rather than
+      via the VPN tunnel, location configuration SHOULD be attempted
+      before such tunnels are established.
+
+   ED-29/INT-23:  Software that uses LCPs SHOULD locate and use the
+      actual hardware network interface rather than a VPN tunnel
+      interface to direct LCP requests to the LIS in the actual access
+      network.
+
+   AN-16:  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 unless they can accurately determine the
+      location for such addresses.
+
+   AN-17:  Placement of NAT devices where an LCP uses an IP address for
+      an identifier SHOULD consider the effect of the NAT on the LCP.
+      The address used to query the LIS MUST be able to correctly
+      identify the record in the LIS representing the location of the
+      querying device.
+
+   ED-30/INT-24:  For devices that are not expected to change location,
+      refreshing location on the order of once per day is RECOMMENDED.
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 10]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   ED-31/INT-25:  For devices that roam, refresh of location information
+      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.  If the device detects a link state
+      change that might indicate having moved, for example, when it
+      changes access points, the device SHOULD refresh its location.
+
+   ED-32/INT-26/AN-18:  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 time is
+      under 100 ms.  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.
+
+6.7.  Conveying Location
+
+   ED-33/SP-15:  Location sent between SIP entities MUST be conveyed
+      using the extension described in [RFC6442].
+
+6.8.  Location Updates
+
+   ED-34/AN-19:  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 implemented and used.
+
+   ED-35/AN-20:  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-36/AN-21:  The LIS SHOULD provide a location reference that
+      permits a subscription with appropriate filtering.
+
+   ED-37/AN-22:  For calls sent with location-by-reference, with a SIP
+      or Session Initiation Protocol Secure (SIPS) scheme, the server
+      resolving the reference MUST support a SUBSCRIBE [RFC6665] to the
+      presence event [RFC3856].  For other location-by-reference schemes
+      that do not support subscription, the PSAP will have to repeatedly
+      dereference the URI to determine if the device moved.
+
+   ED-38:  If location was sent by value and the endpoint gets an
+      updated location, it MUST send the updated location to the PSAP
+      via a SIP re-INVITE or UPDATE request.  Such updates SHOULD be
+      limited to no more than one update every 10 seconds, a value
+      selected to keep the load on a large PSAP manageable, and yet
+      provide sufficient indication to the PSAP of motion.
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 11]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+6.9.  Multiple Locations
+
+   ED-39/SP-16:  If the LIS has more than one location for an endpoint,
+      it MUST conform to the rules in Section 3 of [RFC5491].
+
+   ED-40:  If an endpoint has more than one location available to it, it
+      MUST choose one location to route the call towards the PSAP.  If
+      multiple locations are in a single Presence Information Data
+      Format (PIDF), the procedures in [RFC5491] MUST be followed.  If
+      the endpoint has multiple PIDFs and has no reasonable basis to
+      choose from among them, a random choice is acceptable.
+
+   SP-17:  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.  If
+      multiple locations are in a single PIDF, the procedures in
+      [RFC5491] MUST be followed.  If the proxy has multiple PIDFs and
+      has no reasonable basis to choose from among them, a random choice
+      is acceptable.
+
+   SP-18:  If a proxy is attempting to insert location but the endpoint
+      conveyed a location to it, the proxy MUST use the endpoint's
+      location for routing in the initial INVITE and MUST convey that
+      location towards the PSAP.  It MAY also include what it believes
+      the location to be in a separate Geolocation header.
+
+   SP-19:  All location objects received by a proxy MUST be delivered to
+      the PSAP.
+
+   ED-41/SP-20:  Location objects MUST be created with 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-42/SP-21:  A location with a method of "derived" MUST NOT be used
+      unless no other location is available.
+
+6.10.  Location Validation
+
+   AN-23:  A LIS SHOULD perform location validation of civic locations
+      via LoST before entering a location in its database.
+
+   ED-43:  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.
+
+
+
+Rosen & Polk              Best Current Practice                [Page 12]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+6.11.  Default Location
+
+   AN-24:  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.  See [RFC6443].
+
+   SP-22:  Proxies handling emergency calls MUST insert a default
+      location in the INVITE if the incoming INVITE does not contain a
+      location and the proxy does not have a method for obtaining a
+      better location.
+
+   AN-25/SP-23:  Default locations MUST be marked with method=Default,
+      and the proxy MUST be identified in a PIDF-LO "provided-by"
+      element.
+
+6.12.  Other Location Considerations
+
+   ED-44:  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-45/AN-26:  To prevent against spoofing of the DHCP server,
+      entities implementing DHCP for location configuration SHOULD use
+      DHCPv4 message authentication [RFC3118] or DHCPv6 message
+      authentication [RFC3315], although the difficulty in providing
+      appropriate credentials is significant.
+
+   ED-46:  If S/MIME [RFC5751] is used, the INVITE message MUST provide
+      enough information unencrypted for intermediate proxies to route
+      the call based on the location information included.  This would
+      include the Geolocation header and any bodies containing location
+      information.  Use of S/MIME with emergency calls is NOT
+      RECOMMENDED for this reason.
+
+   ED-47/SP-24:  Transport Layer Security (TLS) [RFC5746] MUST be used
+      to protect location (but see Section 9.1).  All SIP
+      implementations of this specification MUST support TLS.
+
+7.  LIS and LoST Discovery
+
+   ED-48:  Endpoints MUST support one or more mechanisms that allow them
+      to determine their public IP address, for example, Session
+      Traversal Utilities for NAT (STUN) [RFC5389].
+
+   ED-49:  Endpoints MUST support LIS discovery as described in
+      [RFC5986] and LoST discovery as described in [RFC5223].
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 13]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   ED-50:  The device MUST have a configurable default LoST server
+      parameter.
+
+   ED-51:  DHCP LoST discovery MUST be used, if available, in preference
+      to configured LoST servers.  That is, the endpoint MUST send
+      queries to this LoST server first, using other LoST servers only
+      if these queries fail.
+
+   AN-27:  Access networks that support DHCP MUST implement the LIS and
+      LoST discovery options in their DHCP servers and return suitable
+      server addresses as appropriate.
+
+8.  Routing the Call to the PSAP
+
+   ED-52:  Endpoints that obtain their own location SHOULD perform LoST
+      mapping to the PSAP URI.
+
+   ED-53:  Mapping SHOULD be performed at boot time and whenever a
+      location changes beyond the service boundary obtained from a prior
+      LoST mapping operation, or when the time-to-live value of that
+      response has expired.  The value MUST be cached for possible later
+      use.
+
+   ED-54:  The endpoint MUST 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-55:  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.  If the device cannot
+      update the LoST mapping and does not have a cached value, it MUST
+      signal an emergency call without a Route header containing a PSAP
+      URI.
+
+   SP-25:  Networks MUST be designed so that at least one proxy in the
+      outbound path will 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 SIP Route header field with a URI
+      of a PSAP.  The absence of such a Route header indicates that the
+      endpoint was unable to invoke LoST, and the proxy MUST perform the
+      LoST mapping and insert a Route header field with the URI
+      obtained.
+
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 14]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   SP-26:  To deal with old user agents that predate this specification
+      and with endpoints that do not have access to their own location
+      data, a proxy that recognizes 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 be placed in a Route header with the
+      service URN in the Request URI.
+
+   SP-27:  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-28:  A proxy server that 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.
+
+   ED-56/SP-29:  [RFC3261] and [RFC3263] procedures MUST be used to
+      route an emergency call towards the PSAP's URI.
+
+9.  Signaling of Emergency Calls
+
+9.1.  Use of TLS
+
+   ED-57/SP-30:  TLS is the primary mechanism used to secure the
+      signaling for emergency calls.  IPsec [RFC4301] MAY be used
+      instead of TLS for any hop.  Either TLS or IPsec MUST be used when
+      attempting to signal an emergency call.
+
+   ED-58/SP-31:  If TLS session establishment is not available or fails,
+      the call MUST be retried without TLS.
+
+   ED-59/SP-32:  Following the procedures described in [RFC5626] is
+      RECOMMENDED to maintain persistent TLS connections between
+      entities when one of the entities is an endpoint.  Persistent TLS
+      connection between proxies is RECOMMENDED using any suitable
+      mechanism.
+
+   ED-60/AN-28:  TLS SHOULD be used when attempting to retrieve location
+      (configuration or dereferencing) with HELD.  The use of the
+      mechanism described in [RFC5077] is RECOMMENDED to minimize the
+      time to establish TLS sessions without keeping server-side state.
+      IPsec MAY be used instead of TLS.
+
+   ED-61/AN-29:  When TLS session establishment fails, the location
+      retrieval MUST be retried without TLS.
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 15]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+9.2.  SIP Signaling Requirements for User Agents
+
+   ED-62: The initial SIP signaling method is an INVITE request:
+
+   1.   The Request URI SHOULD be the service URN in the "sos" tree.
+        If the device does not interpret local dial strings, the
+        Request-URI MUST be a dial string URI [RFC4967] with the dialed
+        digits.
+
+   2.   The To header field SHOULD be a service URN in the "sos" tree.
+        If the device does not interpret local dial strings, the To:
+        MUST be a dial string URI with the dialed digits.
+
+   3.   The From header field SHOULD contain the address of record (AoR)
+        of the caller.
+
+   4.   A Route header field SHOULD be present with a PSAP URI obtained
+        from LoST (see Section 8).  If the device does not interpret
+        dial plans or was unable to obtain a route from a LoST server,
+        no such Route header field will be present.
+
+   5.   A Contact header field MUST be globally routable, for example, a
+        Globally Routable User Agent URI (GRUU) [RFC5627], and be valid
+        for several minutes following the termination of the call,
+        provided that the User Agent Client (UAC) remains registered
+        with the same registrar, to permit an immediate callback to the
+        specific device that placed the emergency call.  It is
+        acceptable if the UAC inserts a locally routable URI and a
+        subsequent back-to-back user agent (B2BUA) maps that to a
+        globally routable URI.
+
+   6.   Other header fields MAY be included as per normal SIP behavior.
+
+   7.   If a geolocation URI is included in the INVITE, a Supported
+        header field MUST be included with a 'geolocation-sip' or
+        'geolocation-http" option tag, as appropriate [RFC6442].
+
+   8.   If a device understands the SIP location conveyance [RFC6442]
+        extension and has its location available, it MUST include
+        location as either location-by-value or location-by-reference,
+        or both, according to the rules within RFC 6442.
+
+   9.   An SDP offer SHOULD be included in the INVITE.  If voice is
+        supported, the offer SHOULD include the G.711 codec; see
+        Section 14.  As PSAPs may support a wide range of media types
+        and codecs, sending an offerless INVITE may result in a lengthy
+        return offer but is permitted.  Cautions in [RFC3261] on
+        offerless INVITEs should be considered before such use.
+
+
+
+Rosen & Polk              Best Current Practice                [Page 16]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   10.  If the device includes location-by-value, the user agent (UA)
+        MUST support multipart message bodies, since SDP will likely be
+        also in the INVITE.
+
+9.3.  SIP Signaling Requirements for Proxy Servers
+
+   SP-33: SIP proxy servers processing emergency calls:
+
+   1.  If the proxy interprets dial plans on behalf of user agents, the
+       proxy MUST look for the local emergency dial string at the
+       location of the end device and MAY look for the home dial string.
+       If it finds it, the proxy MUST:
+
+       *  Insert a Geolocation header field.  Location-by-reference MUST
+          be used because proxies are not allowed to insert bodies.
+
+       *  Insert the Geolocation-Routing header with appropriate
+          parameters.
+
+       *  Map the location to a PSAP URI using LoST.
+
+       *  Add a Route header with the PSAP URI.
+
+       *  Replace the Request-URI, which was the dial string, with the
+          service URN appropriate for the emergency dial string.
+
+       *  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, it MUST query a LoST server
+       immediately.  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 that 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 that 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 proxy MAY add a Geolocation header field.  Such an additional
+       location SHOULD NOT be used for routing; the location provided by
+       the UA should be used.
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 17]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   4.  Either a P-Asserted-Identity [RFC3325] or an Identity header
+       field [RFC4474], or both, SHOULD be included to identify the
+       sender.  For services that must support emergency calls from
+       unauthenticated devices, valid identity may not be available.
+       Proxies encountering a P-Asserted-Identity will need to pass the
+       header to the PSAP, which is in a different domain.  [RFC3325]
+       requires a "spec(T)" to determine what happens if either the "id"
+       privacy service or a Privacy header is present and requests
+       privacy.  In the absence of another spec(T), such proxies should
+       pass the header unmodified if and only if the connection between
+       the proxy and the PSAP is, as far as the proxy can determine,
+       protected by TLS with mutual authentication using keys reliably
+       known by the parties, encrypted with no less strength than AES,
+       and the local regulations governing the PSAP do not specify
+       otherwise.
+
+   5.  Proxies SHOULD NOT return a 424 error.  They should process the
+       INVITE as best they can.
+
+   6.  Proxies SHOULD NOT obey a Geolocation-Routing value of "no" or a
+       missing value if they must query LoST to obtain a route.
+       Emergency calls are always routed by location.
+
+10.  Callbacks
+
+   ED-63/SP-34:  Devices SHOULD have a globally routable URI in a
+      Contact header field that remains valid for several minutes past
+      the time the original call containing the URI completes, unless
+      the device registration expires and is not renewed.
+
+   SP-35:  Callbacks to the Contact header URI received within
+      30 minutes of an emergency call must reach the device regardless
+      of call features (e.g., do not disturb) or services (e.g., call
+      forwarding) that would normally cause the call to be routed to
+      some other entity.
+
+   SP-36:  Devices MUST have a persistent AoR URI either in a
+      P-Asserted-Identity header field or From protected by an Identity
+      header field suitable for returning a call sometime after the
+      original call.  Such a callback would not necessarily reach the
+      device that originally placed the call.
+
+
+
+
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 18]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+11.  Mid-Call Behavior
+
+   ED-64/SP-37:  During the course of an emergency call, PSAPs and
+      responders may need to transfer the call to some other entity.
+      The request for such a transfer is signaled by a REFER request
+      within the dialog with method=INVITE and a Refer-To header field
+      [RFC3515].  Devices MUST react to such a transfer request with the
+      appropriate INVITE.
+
+12.  Call Termination
+
+   ED-65:  Normal [RFC3261] procedures for termination MUST be used for
+      termination of the call.
+
+13.  Disabling of Features
+
+   ED-66/SP-38:  User agents and proxies MUST disable features that will
+      interrupt an ongoing emergency call, such as:
+
+   o  Call waiting
+
+   o  Call transfer
+
+   o  Three-way call
+
+   o  Hold
+
+   o  Outbound call blocking
+
+   when an emergency call is established, but see ED-65 with respect to
+   call waiting.  Also see ED-73 in Section 14.
+
+   ED-67/SP-39:  The emergency dial strings SHOULD NOT be permitted in
+      call forward numbers or speed dial lists.
+
+   ED-68/SP-40:  The user agent and proxies MUST disable call features
+      that would interfere with the ability of callbacks from the PSAP
+      to be completed, such as:
+
+   o  Do not disturb
+
+   o  Call forward (all kinds)
+
+   These features SHOULD be disabled for approximately 30 minutes
+   following termination of an emergency call.
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 19]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   ED-69:  Callbacks SHOULD be determined by retaining the domain of the
+      PSAP that answers an outgoing emergency call and instantiating a
+      timer that starts when the call is terminated.  If a call is
+      received from the same domain and within the timer period, and it
+      is sent to the URI in a Contact header or the AoR used in the
+      emergency call, then it should be assumed to be a callback.  The
+      suggested timer period is 5 minutes.  The mechanism described in
+      [RFC4916] can be used by the PSAP to inform the endpoint of the
+      PSAP's domain.  Recognizing a callback from the domain of the PSAP
+      will not always work, and further standardization will be required
+      to give the endpoint the ability to recognize a callback.
+
+14.  Media
+
+   ED-70:  Endpoints MUST send and receive media streams on RTP
+      [RFC3550].
+
+   ED-71:  Normal SIP offer/answer [RFC3264] negotiations MUST be used
+      to agree on the media streams to be used.
+
+   ED-72/SP-41:  G.711 A-law (and mu-law if they are intended to be used
+      in North America) encoded voice as described in [RFC3551] MUST be
+      supported.  If the endpoint cannot support G.711, a transcoder
+      MUST be used so that the offer received at the PSAP contains
+      G.711.  It is desirable to include wideband codecs such as G.722
+      and Adaptive Multi-Rate - WideBand (AMR-WB) in the offer.  PSAPs
+      SHOULD support narrowband codecs common on endpoints in their area
+      to avoid transcoding.
+
+   ED-73:  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-74:  Endpoints supporting Instant Messaging (IM) MUST support
+      either [RFC3428] or [RFC4975].
+
+   ED-75:  Endpoints supporting real-time text MUST comply with
+      [RFC4103].  The expectations for emergency service support for the
+      real-time text medium are described in [RFC5194] Section 7.1.
+
+   ED-76:  Endpoints supporting video MUST support H.264 per [RFC6184].
+
+
+
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 20]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+15.  Testing
+
+   ED-77:  INVITE requests to a service URN starting with "test."
+      indicate a request for an automated test, for example,
+      "urn:service:test.sos.fire".  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 404 (not found) MUST be returned if
+      the PSAP does not support the test mechanism.
+
+   ED-78:  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 location-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 therefore
+      location-hiding techniques, if they are being used, may be
+      employed for this dereference.  Use of SIPS for the request would
+      assure that the response containing the location is kept private.
+
+   ED-79:  A PSAP accepting a test call SHOULD accept a media loopback
+      [RFC6849] test and SHOULD support the "rtp-pkt-loopback" and
+      "rtp-media-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-80:  User agents SHOULD perform a full call test, including media
+      loopback, after a disconnect and subsequent change in IP address
+      not due to a reboot.  After an initial test, a full test SHOULD be
+      repeated approximately every 30 days with a random interval.
+
+   ED-81:  User agents MUST NOT place a test call immediately after
+      booting.  If the IP address changes after booting, the endpoint
+      should wait a random amount of time (in perhaps a 30-minute
+      period, sufficient for any avalanche-restart event to complete)
+      and then test.
+
+   ED-82:  PSAPs MAY refuse repeated requests for test from the same
+      device in a short period of time.  Any refusal is signaled with a
+      486 (busy here) or 488 (not acceptable here) response.
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 21]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+16.  Security Considerations
+
+   Security considerations for emergency calling have been documented in
+   [RFC5069] and [RFC6280].  This document suggests that security (TLS
+   or IPsec) be used hop by hop on a SIP call to protect location
+   information, identity, etc.  It also suggests that if the attempt to
+   create a security association fails the call be retried without the
+   security.  It's more important to get an emergency call through than
+   to protect the data; indeed, in many jurisdictions privacy is
+   explicitly waived when making emergency calls.  Placing a call
+   without security may reveal user information, including location.
+   The alternative -- failing the call if security cannot be established
+   -- is considered unacceptable.
+
+17.  IANA Considerations
+
+   This document registers service URNs in the Service URN Labels
+   registry per [RFC5031] for testing.
+
+17.1.  Test Service URN
+
+   A new entry in the URN Service Label registry has been added.  The
+   new service is "test", the reference is this document, and the
+   description is "self-test".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 22]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+17.2.  'test' Subregistry
+
+   A new subregistry has been created: 'test' Sub-Services.  The
+   registration process is Expert Review per [RFC5226].  The expert
+   review should consider that the entries in this registry nominally
+   track the entries in the 'sos' subregistry, although it is not
+   required that every entry in 'sos' have an entry in 'test', and it is
+   possible that entries in the 'test' subregistry may not necessarily
+   be in the 'sos' subregistry.  For example, testing of non-emergency
+   URNs may be allowed.  The reference is this document.  The initial
+   content of the subregistry is:
+
+   Service                    Reference   Description
+   ------------------------------------------------------------------
+   test.sos                   RFC 6881    test for sos
+   test.sos.ambulance         RFC 6881    test for sos.ambulance
+   test.sos.animal-control    RFC 6881    test for sos.animal-control
+   test.sos.fire              RFC 6881    test for sos.fire
+   test.sos.gas               RFC 6881    test for sos.gas
+   test.sos.marine            RFC 6881    test for sos.marine
+   test.sos.mountain          RFC 6881    test for sos.mountain
+   test.sos.physician         RFC 6881    test for sos.physician
+   test.sos.poison            RFC 6881    test for sos.poison
+   test.sos.police            RFC 6881    test for sos.police
+
+18.  Acknowledgements
+
+   Working group members participating in the creation and review of
+   this document include Hannes Tschofenig, Ted Hardie, Marc Linsner,
+   Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom,
+   Barbara Stark, Richard Barnes, and Peter Blatherwick.
+
+19.  References
+
+19.1.  Normative References
+
+   [LLDP-MED]  ANSI/TIA, "Link Layer Discovery Protocol - Media Endpoint
+               Discovery", TIA Standard, TIA-1057, April 2006.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3118]   Droms, R. and W. Arbaugh, "Authentication for DHCP
+               Messages", RFC 3118, June 2001.
+
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 23]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   [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.
+
+   [RFC3315]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+               and M. Carney, "Dynamic Host Configuration Protocol for
+               IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [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.
+
+   [RFC3856]   Rosenberg, J., "A Presence Event Package for the Session
+               Initiation Protocol (SIP)", RFC 3856, August 2004.
+
+   [RFC3966]   Schulzrinne, H., "The tel URI for Telephone Numbers",
+               RFC 3966, December 2004.
+
+   [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.
+
+   [RFC4301]   Kent, S. and K. Seo, "Security Architecture for the
+               Internet Protocol", RFC 4301, December 2005.
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 24]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   [RFC4474]   Peterson, J. and C. Jennings, "Enhancements for
+               Authenticated Identity Management in the Session
+               Initiation Protocol (SIP)", RFC 4474, August 2006.
+
+   [RFC4776]   Schulzrinne, H., "Dynamic Host Configuration Protocol
+               (DHCPv4 and DHCPv6) Option for Civic Addresses
+               Configuration Information", RFC 4776, November 2006.
+
+   [RFC4916]   Elwell, J., "Connected Identity in the Session Initiation
+               Protocol (SIP)", RFC 4916, June 2007.
+
+   [RFC4967]   Rosen, B., "Dial String Parameter for the Session
+               Initiation Protocol Uniform Resource Identifier",
+               RFC 4967, July 2007.
+
+   [RFC4975]   Campbell, B., Mahy, R., and C. Jennings, "The Message
+               Session Relay Protocol (MSRP)", RFC 4975, September 2007.
+
+   [RFC5031]   Schulzrinne, H., "A Uniform Resource Name (URN) for
+               Emergency and Other Well-Known Services", RFC 5031,
+               January 2008.
+
+   [RFC5139]   Thomson, M. and J. Winterbottom, "Revised Civic Location
+               Format for Presence Information Data Format Location
+               Object (PIDF-LO)", RFC 5139, February 2008.
+
+   [RFC5222]   Hardie, T., Newton, A., Schulzrinne, H., and H.
+               Tschofenig, "LoST: A Location-to-Service Translation
+               Protocol", RFC 5222, August 2008.
+
+   [RFC5223]   Schulzrinne, H., Polk, J., and H. Tschofenig,
+               "Discovering Location-to-Service Translation (LoST)
+               Servers Using the Dynamic Host Configuration Protocol
+               (DHCP)", RFC 5223, August 2008.
+
+   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+               May 2008.
+
+   [RFC5389]   Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+               "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+               October 2008.
+
+   [RFC5491]   Winterbottom, J., Thomson, M., and H. Tschofenig,
+               "GEOPRIV Presence Information Data Format Location Object
+               (PIDF-LO) Usage Clarification, Considerations, and
+               Recommendations", RFC 5491, March 2009.
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 25]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+   [RFC5626]   Jennings, C., Mahy, R., and F. Audet, "Managing Client-
+               Initiated Connections in the Session Initiation Protocol
+               (SIP)", RFC 5626, October 2009.
+
+   [RFC5627]   Rosenberg, J., "Obtaining and Using Globally Routable
+               User Agent URIs (GRUUs) in the Session Initiation
+               Protocol (SIP)", RFC 5627, October 2009.
+
+   [RFC5746]   Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
+               "Transport Layer Security (TLS) Renegotiation Indication
+               Extension", RFC 5746, February 2010.
+
+   [RFC5751]   Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+               Mail Extensions (S/MIME) Version 3.2 Message
+               Specification", RFC 5751, January 2010.
+
+   [RFC5985]   Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
+               RFC 5985, September 2010.
+
+   [RFC5986]   Thomson, M. and J. Winterbottom, "Discovering the Local
+               Location Information Server (LIS)", RFC 5986,
+               September 2010.
+
+   [RFC6184]   Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP
+               Payload Format for H.264 Video", RFC 6184, May 2011.
+
+   [RFC6225]   Polk, J., Linsner, M., Thomson, M., and B. Aboba,
+               "Dynamic Host Configuration Protocol Options for
+               Coordinate-Based Location Configuration Information",
+               RFC 6225, July 2011.
+
+   [RFC6442]   Polk, J., Rosen, B., and J. Peterson, "Location
+               Conveyance for the Session Initiation Protocol",
+               RFC 6442, December 2011.
+
+   [RFC6665]   Roach, A., "SIP-Specific Event Notification", RFC 6665,
+               July 2012.
+
+   [RFC6849]   Kaplan, H., Ed., Hedayat, K., Venna, N., Jones, P., and
+               N. Stratton, "An Extension to the Session Description
+               Protocol (SDP) and Real-time Transport Protocol (RTP) for
+               Media Loopback", RFC 6849, February 2013.
+
+
+
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 26]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+19.2.  Informative References
+
+   [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.
+
+   [RFC5012]   Schulzrinne, H. and R. Marshall, "Requirements for
+               Emergency Context Resolution with Internet Technologies",
+               RFC 5012, January 2008.
+
+   [RFC5069]   Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
+               Shanmugam, "Security Threats and Requirements for
+               Emergency Call Marking and Mapping", RFC 5069,
+               January 2008.
+
+   [RFC5077]   Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
+               "Transport Layer Security (TLS) Session Resumption
+               without Server-Side State", RFC 5077, January 2008.
+
+   [RFC5194]   van Wijk, A. and G. Gybels, "Framework for Real-Time Text
+               over IP Using the Session Initiation Protocol (SIP)",
+               RFC 5194, June 2008.
+
+   [RFC6280]   Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
+               Tschofenig, H., and H. Schulzrinne, "An Architecture for
+               Location and Location Privacy in Internet Applications",
+               BCP 160, RFC 6280, July 2011.
+
+   [RFC6443]   Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
+               "Framework for Emergency Calling Using Internet
+               Multimedia", RFC 6443, December 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 27]
+
+RFC 6881                Emergency Call Phone BCP              March 2013
+
+
+Authors' Addresses
+
+   Brian Rosen
+   NeuStar
+   470 Conrad Dr.
+   Mars, PA  16046
+   USA
+
+   Phone: +1 724 382 1051
+   EMail: br@brianrosen.net
+
+
+   James Polk
+   Cisco Systems
+   3913 Treemont Circle
+   Colleyville, TX  76034
+   USA
+
+   Phone: +1-817-271-3552
+   EMail: jmpolk@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Polk              Best Current Practice                [Page 28]
+