GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp181

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]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp181.txt · Last modified: 2013/03/08 00:20 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki