<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3263 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml">
<!ENTITY rfc3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY rfc3265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml">
<!ENTITY rfc3118 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml">
<!ENTITY rfc3325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml">
<!ENTITY rfc3428 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3428.xml">
<!ENTITY rfc5389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml">
<!ENTITY rfc3515 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3515.xml">
<!ENTITY rfc3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3551 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY rfc3856 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3856.xml">
<!ENTITY rfc3966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml">
<!ENTITY rfc4103 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4103.xml">
<!ENTITY rfc4119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY rfc4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY rfc4474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY rfc5077 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml">
<!ENTITY rfc4776 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776.xml">
<!ENTITY rfc4916 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4916.xml">
<!ENTITY rfc4967 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4967.xml">
<!ENTITY rfc4975 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4975.xml">
<!ENTITY rfc5012 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5012.xml">
<!ENTITY rfc5031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml">
<!ENTITY rfc5069 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5069.xml">
<!ENTITY rfc5139 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5139.xml">
<!ENTITY rfc5194 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5194.xml">
<!ENTITY rfc5222 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml">
<!ENTITY rfc5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY rfc5223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5223.xml">
<!ENTITY rfc5491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5491.xml">
<!ENTITY rfc5626 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5626.xml">
<!ENTITY rfc5627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5627.xml">
<!ENTITY rfc5746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5746.xml">
<!ENTITY rfc5751 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5751.xml">
<!ENTITY rfc5985 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5985.xml">
<!ENTITY rfc5986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5986.xml">
<!ENTITY rfc6184 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6184.xml">
<!ENTITY rfc6225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6225.xml">
<!ENTITY rfc6280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6280.xml">
<!ENTITY rfc6442 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6442.xml">
<!ENTITY rfc6443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6443.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact='yes'?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>

<rfc category="bcp" number="XXXX" seriesNo="NNN" ipr="trust200902" submissionType="IETF" consensus="yes">

  <front>
    <title abbrev="Emergency Call Phone BCP">Best Current Practice for
    Communications Services in Support of Emergency Calling</title>

    <author fullname="Brian Rosen" initials="B.R" surname="Rosen">
      <organization>NeuStar</organization>
      <address>
        <postal>
          <street>470 Conrad Dr.</street>
          <city>Mars</city>
          <region>PA</region>
          <code>16046</code>
          <country>USA</country>
        </postal>
        <phone>+1 724 382 1051</phone>
        <email>br@brianrosen.net</email>
      </address>
    </author>

    <author fullname="James Polk" initials="J.P." surname="Polk">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>3913 Treemont Circle</street>
          <city>Colleyville</city>
          <region>TX</region>
          <code>76034</code>
          <country>USA</country>
        </postal>
        <phone>+1-817-271-3552</phone>
        <email>jmpolk@cisco.com</email>
      </address>
    </author>

    <date month="February" year="2013" />

    <area>rai</area>

    <workgroup>ecrit</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on http://www.rfc-editor.org/rfcsearch.html. -->

<!-- [rfced] Please let us know if any changes are required for the
following:

a) The following terms were used used inconsistently
in the document.  We chose to use the forms on the right, mostly
per usage in the published RFCs from this group (e.g., RFCs 5012,
6443, 6444).  Please let us know any objections.

call back / call-back / callback (noun)
User Agent / user agent
by-reference / location-by-reference
by-value / location-by-value

b) We see both "location by reference" and "location-by-reference";
in some instances, the different terms appear to be used in the same
way.  Please let us know if these should be made consistent.
This question also applies to "location by value or by reference" in
Section 6.4. -->

<abstract>
<t>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.</t>
</abstract>
</front>

<middle>
<section title="Introduction">
<t>This document describes how access networks, Session Initiation Protocol
<xref target="RFC3261"/> user agents, proxy servers, and Public Safety Answering
Points (PSAPs) support emergency calling, as 
outlined in <xref target="RFC6443"></xref>, which is designed to complement the
present document in section headings, numbering, and content. 

<!-- [rfced] Introduction:  As RFC 6443 identifies PSAP as
"Public Safety Answering Point," we have updated this document to
match.  Please let us know any objections.

Original:
 This document describes how access networks, Session Initiation
 Protocol [RFC3261] user agents, proxy servers and Public Safety
 Access Points (PSAPs) support emergency calling, as outlined in
 [I-D.ietf-ecrit-framework], which is designed to complement the
 present document in section headings, numbering and content.

Changed to:
 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 <xref target="RFC6443"></xref> 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. </t>
<t>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 <xref target="Location"></xref>) 
may depend on the ability of such intermediate devices to meet the requirements prefaced by "INT-".</t>
<t>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.</t>
<t>Other organizations, such as the National Emergency Number Association
(NENA), define the PSAP interface.  NENA's documents reference this
document.</t>
</section>

<section title="Terminology">
<t>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 <xref 
target="RFC2119"></xref>.</t>
<t>This document uses terms from <xref target="RFC3261"></xref>, <xref target="RFC5012"></xref>, and <xref target="RFC6443"></xref>.</t>
</section>

<section title="Overview of How Emergency Calls Are Placed">
<t>An emergency call can be distinguished (<xref target="Identifying"></xref>) from any other call 
by a unique service URN <xref target="RFC5031"></xref> 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 (<xref 
target="Location"></xref>) prior to making emergency calls. To get this location, either a form of 
measuring (e.g., GPS) (<xref target="EndSystemMeasuredLocation"></xref>) device location in 
the endpoint is deployed or the endpoint is configured (<xref 
target="LocationConfiguration"></xref>) with its location from the access network's Location
Information Server (LIS).

<!-- [rfced] Section 3:  We do not see GPS mentioned in
Section 6.2.3.  We also see that this sentence is very similar to a
sentence in Section 3 of RFC 6443 where GNSS is mentioned and
Section 6.2.3 of that document is mentioned.  Please let us know if
any updates are needed for this document.

Original:
 To get this location, either a form
 of measuring (e.g., GPS) (Section 6.2.3) device location in 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 (<xref target="Conveyance"></xref>) in the SIP 
signaling with the call. The call is routed (<xref target="Routing"></xref>) based on location 
using the Location-to-Service Translation (LoST) protocol <xref target="RFC5222"></xref>, which maps a location to 
a set of PSAP URIs. Each URI 
resolves to a PSAP or an Emergency Service Routing Proxy (ESRP) that serves a group of PSAPs. The 
call arrives at the PSAP with the location included in the SIP INVITE request. </t>
</section>

<section anchor="WhichDevices" title="Which Devices and Services Should Support Emergency Calls?">
<t>
  <list style="hanging">
  <t hangText="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.</t>

  <t hangText="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.</t>
  <t hangText="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.</t>
</list></t>
</section>

<section anchor="Identifying" title="Identifying an Emergency Call">
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="SP-2:">Proxy servers SHOULD recognize emergency dial strings if for some 
reason the endpoint does not recognize them. </t>
<t hangText="ED-4/SP-3:">Emergency calls MUST be marked with a service URN in the Request-URI of the INVITE.</t>
<t hangText="ED-5/SP-4:">Geographically local dial strings MUST be recognized.</t>
<t hangText="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.</t>
<t hangText="ED-7/SP-6:">Emergency dial strings SHOULD be determined from LoST 
<xref target="RFC5222"></xref>.  Dial strings MAY be configured directly into the device.</t>
<t hangText="AN-1:">LoST servers MUST return dial strings for emergency services.</t>
<t hangText="ED-8:">Endpoints that do not recognize emergency dial strings SHOULD send dial strings as per 
<xref target="RFC4967"></xref>.</t>
<t hangText="SP-7:">If a proxy server recognizes dial strings on behalf of its clients, it MUST recognize emergency dial strings represented by <xref 
target="RFC4967"></xref> and SHOULD recognize the emergency dial strings represented by a tel URI <xref 
target="RFC3966"></xref>.</t>
<t hangText="ED-9:">Endpoints SHOULD be able to have home dial strings provisioned.</t>
<t hangText="SP-8:">Service providers MAY provision home dial strings in devices.</t>
<t hangText="ED-10:">Devices SHOULD NOT have one-button emergency calling initiation.</t>
<t hangText="ED-11/SP-9:">All sub-services for the 'sos' service specified in
<xref target="RFC5031"></xref> MUST be recognized.</t> 
</list></t>
</section>

<section anchor="Location" title="Location and Its Role in an Emergency Call">
<t>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 
<xref target="RFC5222"></xref> is the Location Mapping Protocol defined by the 
IETF.</t>

<section anchor="LocationTypes" title="Types of Location Information">
<t>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.
</t>
 <t>
 <list style="hanging">
<t hangText="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.</t>
<t hangText="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 <xref target="LocationDetermination"/>) supplied prior to receipt by the
PSAP.</t>
 </list></t>
</section>

<section anchor="LocationDetermination" title="Location Determination">
 <t>
 <list style="hanging">
<t hangText="ED-14/INT-3/AN-3:">Any location determination mechanism MAY be
used, provided the accuracy of the location meets local requirements.</t>
 </list></t>

<section anchor="UserLocation" title="User-Entered Location Information">
 <t>
 <list style="hanging">
<t hangText="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 <xref target="RFC4119"></xref> and <xref
target="RFC5139"></xref>.</t>
 </list></t>
</section>

<section anchor="WireDatabase" title='Access Network "Wire Database"
Location Information'>
 <t>
 <list style="hanging">
<t hangText="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.</t>
<t hangText="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 <xref target="RFC6443"/> Section 6.2.2 for a discussion of how this value was determined.</t>
<t hangText="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. </t> 
<t hangText="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.</t>
 </list></t>
</section>

<section anchor="EndSystemMeasuredLocation" title="End System Measured Location
Information">
 <t>
 <list style="hanging">
<t hangText="ED-16/INT-8:">Devices MAY support end system measured location. See <xref target="RFC6443"/> Section 6 for a discussion of accuracy of location.</t>
<t hangText="ED-17/INT-9/AN-9:">Devices that support endpoint measuring of location MUST have at least a coarse 
location capability (typically &lt;1 km accuracy) for the routing of calls. 
The location mechanism MAY be a service provided by the access network.</t>
 </list></t>
</section>

<section anchor="NetworkMeasuredLocation" title="Network Measured Location Information">
 <t>
 <list style="hanging">
<t hangText="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.</t>
<t hangText="AN-11:">Access networks that provide network measured location MUST have at least a coarse location 
(typically &lt;1 km when not location hiding) capability at all times for the routing of calls.</t>
<t hangText="AN-12:">Access networks with a range of &lt;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.</t>
 </list></t>
</section>
</section>

<section anchor="WhoAddsLocation" title="Who Adds Location, Endpoint, or
Proxy?">
 <t>
 <list style="hanging">
<t hangText="ED-18/INT-10:">Endpoints SHOULD attempt to configure their own
location using the Location Configuration Protocols (LCPs) listed in ED-21.</t>
 </list></t>
<t>SP-12: Proxies MAY provide location on behalf of devices if:
<list style="symbols">
<t>The proxy has a relationship with all access networks the device could connect to, and the 
relationship allows it to obtain location.</t>
<t>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.</t>
</list></t>
 <t>
 <list style="hanging">
<t hangText="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.</t>
 </list></t>
</section>

<section anchor="LocationReference" title="Location and References to
Location">
 <t>
 <list style="hanging">
<t hangText="ED-20/INT-12:">Devices SHOULD be able to accept and forward location by value or by reference. An end 
device that receives location by reference (and does not also get the corresponding value) MUST be 
able to perform a dereference operation to obtain a value.</t>
 </list></t>
</section>

<section anchor="LocationConfiguration" title="End System Location Configuration">
<t>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.</t>
 <t>
 <list style="hanging">
<t hangText="ED-21/INT-13:">Devices MUST support both the Dynamic Host Configuration
Protocol (DHCP) location options <xref target="RFC4776"></xref> 
<xref target="RFC6225"></xref> and HTTP-Enabled Location Delivery (HELD) <xref
target="RFC5985"></xref>. When devices deploy a specific access network
interface for which location configuration mechanisms such as Link Layer
Discovery Protocol - Media Endpoint Discovery (LLDP-MED) <xref
target="LLDP-MED"/> or 802.11v are specified, the device SHOULD support the
additional respective access network specific location configuration mechanism.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t> 
</list></t>
</section>

<section anchor="WhenConfigure" title="When Location Should Be Configured">
<t>If an endpoint is manually configured, the requirements in this section are
not applicable.</t>
 <t>
 <list style="hanging">
<t hangText="ED-25/INT-19:">Endpoints SHOULD obtain location immediately after obtaining local network configuration information.</t>
<t hangText="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 <xref target="RFC4776"></xref>, <xref target="RFC6225"></xref>,
<xref target="RFC5986"></xref>, and <xref target="RFC5223"></xref>.</t> 
<t hangText="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 <xref target="RFC4776"></xref>, <xref target="RFC6225"></xref>, 
<xref target="RFC5986"></xref>, and <xref target="RFC5223"></xref>.</t> 
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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. </t>
<t hangText="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.</t>
<t hangText="ED-30/INT-24:">For devices that are not expected to change location, refreshing location on the order of once per day is RECOMMENDED.</t>
<t hangText="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.</t>
<t hangText="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.</t>
 </list></t>
</section>

<section anchor="Conveyance" title="Conveying Location">
 <t>
 <list style="hanging">
<t hangText="ED-33/SP-15:">Location sent between SIP entities MUST be conveyed
using <xref target="RFC6442"></xref>.</t>
 </list></t>
</section>

<section anchor="LocationUpdate" title="Location Updates">
 <t>
 <list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="ED-36/AN-21:">The LIS SHOULD provide a location reference that
permits a subscription with appropriate filtering.</t>
<t hangText="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 <xref target="RFC3265"></xref> to the presence 
event <xref target="RFC3856"></xref>. 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. </t>
<t hangText="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.</t>
 </list></t>
</section>

<section anchor="MultipleLocations" title="Multiple Locations">
 <t>
 <list style="hanging">
<t hangText="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 <xref
target="RFC5491"></xref>.</t>
<t hangText="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
<xref target="RFC5491"></xref> MUST be followed.  If the endpoint has
multiple PIDFs and has no reasonable basis to choose from among them, a random choice is acceptable.</t>
<t hangText="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
<xref target="RFC5491"></xref> MUST be followed.  If the proxy has
multiple PIDFs and has no reasonable basis to choose from among them, a random choice is acceptable.</t>
<t hangText="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.</t>
<t hangText="SP-19:">All location objects received by a proxy MUST be delivered to the PSAP.</t>
<t hangText="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.</t>
<t hangText="ED-42/SP-21:">A location with a method of "derived" MUST NOT be
used unless no other location is available.</t>
 </list></t>
</section>

<section anchor="Validation" title="Location Validation">
 <t>
 <list style="hanging">
<t hangText="AN-23:">A LIS SHOULD perform location validation of civic locations via LoST before entering a location in its database.</t>
<t hangText="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.</t>
 </list></t>

<!-- [rfced] Sections 6.10 and subsequent:  As there was no ED-43
(i.e., numbering went from ED-42 to ED-44, and ED-43 was skipped),
we changed "ED-44" to ED-43" and renumbered all subsequent ED-
items accordingly.  Please let us know any objections.

Original:
   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-44 Endpoints SHOULD validate ...

Changed to:
   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 ... -->

</section>

<section anchor="DefaultLocation" title="Default Location">
 <t>
 <list style="hanging">
<t hangText="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 <xref target="RFC6443"></xref>.</t>
<t hangText="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.</t>
<t hangText="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.</t>
 </list></t>
</section>

<section anchor="OtherLocation" title="Other Location Considerations">
 <t>
 <list style="hanging">
<t hangText="ED-44:">If the LCP does not return location in the form of a PIDF-LO <xref 
target="RFC4119"></xref>, the endpoint MUST map the location information it receives from the configuration protocol to a PIDF-LO.</t>
<t hangText="ED-45/AN-26:">To prevent against spoofing of the DHCP server, entities implementing DHCP for 
location configuration SHOULD use <xref target="RFC3118"></xref>, although the
difficulty in providing appropriate credentials is significant.</t>
<t hangText="ED-46:">If S/MIME <xref target="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.</t>
<t hangText="ED-47/SP-24:">Transport Layer Security (TLS)
<xref target="RFC5746"></xref> MUST be used to protect location (but see <xref
target="TLS"></xref>).  All implementations MUST support TLS. </t>
 </list></t>
</section>
</section>

<section title="LIS and LoST Discovery">
 <t>
 <list style="hanging">
<t hangText="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) <xref target="RFC5389"></xref>.</t>
<t hangText="ED-49:">Endpoints MUST support LIS discovery as described in <xref
target="RFC5986"></xref> and LoST discovery as described in <xref
target="RFC5223"></xref>. </t>
<t hangText="ED-50:">The device MUST have a configurable default LoST server parameter. 
</t>
<t hangText="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.</t>
<t hangText="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.</t>
 </list></t>
</section>

<section anchor="Routing" title="Routing the Call to the PSAP">
 <t>
 <list style="hanging">
<t hangText="ED-52:">Endpoints that obtain their own location SHOULD perform
LoST mapping to the PSAP URI.</t>
<t hangText="ED-53:">Mapping SHOULD be performed at boot time and whenever
location changes beyond the service boundary obtained from a prior LoST mapping
operation or the time-to-live value of that response has expired.
The value MUST be cached for possible later use.</t>

<!-- [rfced] Section 8:  We had difficulty parsing this sentence.
If the suggested text is not correct, please clarify.

Original:
 ED-54 Mapping SHOULD be performed at boot time and whenever location
 changes beyond the service boundary obtained from a prior LoST
 mapping operation or the time-to-live value of that response has
 expired.

Suggested (using updated numbering per our question above):
 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. -->

<t hangText="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 <xref target="Location"></xref>), it MUST use the cached value.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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 <xref target="Identifying"></xref>) 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.</t>
<t hangText="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 <xref 
target="DefaultLocation"></xref>) MUST be supplied.</t>
<t hangText="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.</t>
<t hangText="ED-56/SP-29:"><xref target="RFC3261"></xref> and <xref target="RFC3263"></xref> procedures MUST be 
used to route an emergency call towards the PSAP's URI.</t>
 </list></t>
</section>

<section anchor="Signaling" title="Signaling of Emergency Calls">
<section anchor="TLS" title="Use of TLS">
 <t>
 <list style="hanging">
<t hangText="ED-57/SP-30:">TLS is the primary mechanism used to secure the signaling for emergency calls.  IPsec <xref target="RFC4301"/> MAY be used instead of TLS for any hop.  Either TLS or IPsec MUST be used when attempting to signal an emergency call.
</t>
<t hangText="ED-58/SP-31:">If TLS session establishment is not available or fails, the call MUST be retried without TLS.</t>
<t hangText="ED-59/SP-32:">Following the procedures described in <xref
target="RFC5626"></xref> 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.</t>
<t hangText="ED-60/AN-28:">TLS SHOULD be used when attempting to retrieve location (configuration or 
dereferencing) with HELD.  The use of <xref target="RFC5077"></xref> is RECOMMENDED to minimize
the time to establish TLS sessions without keeping server-side state.  IPsec MAY be used instead of TLS.</t>
<t hangText="ED-61/AN-29:">When TLS session establishment fails, the location
retrieval MUST be retried without TLS.</t>
 </list></t>
</section>

<section anchor="UAsignaling" title="SIP Signaling Requirements for User Agents">
<t>ED-62: The initial SIP signaling method is an INVITE request:
<list style="numbers">
<t>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 <xref 
target="RFC4967"></xref> with the dialed digits.</t>
<t>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.</t>
<t>The From header field SHOULD contain the address of record (AoR) of the
caller.</t>
<t>A Route header field SHOULD be present with a PSAP URI obtained from LoST (see <xref 
target="Routing"></xref>). 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.</t>
<t>A Contact header field MUST be globally routable, for example, a
Globally Routable User Agent URI (GRUU) <xref 
target="RFC5627"></xref>, 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.</t>
<t>Other header fields MAY be included as per normal SIP behavior.</t>
<t>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.
<xref target="RFC6442"></xref>.</t>
<t>If a device understands the SIP location conveyance 
<xref target="RFC6442"></xref> extension and has its location available, it
MUST include location as either location-by-value or location-by-reference, or
both.</t>
<t>An SDP offer SHOULD be included in the INVITE. If voice is supported, the
offer SHOULD include the G.711 codec; see <xref target="Media"></xref>.  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
<xref target="RFC3261"/> on offerless INVITEs should be considered before such
use.</t>
<t>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.</t>
</list></t>
</section>

<section anchor="ProxySignaling" title="SIP Signaling Requirements for Proxy Servers">
<t>SP-33: SIP proxy servers processing emergency calls:
<list style="numbers">
<t>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: 
<list style="symbols">
<t>Insert a Geolocation header field. Location-by-reference MUST be used 
because proxies must not insert bodies.</t>
<t>Insert the Geolocation-Routing header with appropriate parameters.</t>
<t>Map the location to a PSAP URI using LoST.</t>
<t>Add a Route header with the PSAP URI.</t>
<t>Replace the Request-URI (which was the dial string) with the service URN
appropriate for the emergency dial string.</t>

<!-- [rfced] Section 9.3:  We had difficulty with this sentence
and whether "which" is meant to be restrictive or non-restrictive.
Should "Request-URI (which was the dial string)" be
"Request-URI, which was the dial string" (non-restrictive)
or perhaps "Request-URI that was the dial string" (restrictive)?
Please clarify.

Original:
 *  Replace the Request-URI (which was the dial string) with the
    service URN appropriate for the emergency dial string. -->

<t>Route the call using normal SIP routing mechanisms.</t>
</list></t>
<t>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 <xref 
target="DefaultLocation"></xref>).  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.</t>
<t>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.</t>
<t>Either a P-Asserted-Identity <xref target="RFC3325"></xref> or an Identity header field <xref 
target="RFC4474"></xref>, 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. <xref
target="RFC3325"/> requires a "spec(T)" to determine what happens if the "id"
privacy service, or a Privacy header is present and requests privacy.

<!-- [rfced] Section 9.3:  We had trouble with this sentence.  Are
"id" privacy service and Privacy header the same thing, or two
different things?  If the suggested text is not correct, please
clarify.

Original:
 [RFC3325]
 requires a "spec(T)" to determine what happens if the "id"
 privacy service, or a Privacy header is present and requests
 privacy.

Suggested:
 [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.</t>
<t>Proxies SHOULD NOT return a 424 error. They should process the INVITE as best they can.</t>
<t>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.</t>
</list></t>
</section></section>

<section anchor="Callbacks" title="Callbacks">
 <t>
 <list style="hanging">
<t hangText="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.</t>
<t hangText="SP-35:">Callbacks to the Contact: header URI received within
30&nbsp;minutes of an emergency call
must reach the device regardless of call features or services
that would normally cause the call to be routed to some other entity.</t>
<t hangText="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 some time after the original call.  Such a callback would not
necessarily reach the device that originally placed the call.</t>
 </list></t>
</section>

<section anchor="MidCall" title="Mid-Call Behavior">
 <t>
 <list style="hanging">
<t hangText="ED-64/SP-37:">During the course of an emergency call, devices and
proxies MUST initiate a call transfer upon receipt of a REFER 
request within the dialog with method=INVITE and the Referred-by header field <xref target="RFC3515"></xref> in that request. </t>
 </list></t>
</section>

<section anchor="Termination" title="Call Termination">
 <t>
 <list style="hanging">
<t hangText="ED-65:">Normal <xref target="RFC3261"/> procedures for termination
MUST be used for termination of the call.</t>
 </list></t>
</section>

<section anchor="DisableFeatures" title="Disabling of Features">
 <t>
 <list style="hanging">
<t hangText="ED-66/SP-38:">User agents and proxies MUST disable features that
will interrupt an ongoing emergency call, such as:</t></list></t>
<t><list style="symbols">
<t>Call waiting</t>
<t>Call transfer</t>
<t>Three-way call</t>
<t>Hold</t>
<t>Outbound call blocking</t>
</list></t>
<t>when an emergency call is established, but see ED-65 with respect to call waiting.  Also see ED-73 in <xref target="Media"></xref>.</t>
 <t>
 <list style="hanging">
<t hangText="ED-67/SP-39:">The emergency dial strings SHOULD NOT be permitted in call forward numbers or speed dial lists.</t>
<t hangText="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:</t></list></t>
<t><list style="symbols">
<t>Do not disturb</t>
<t>Call forward (all kinds)</t>
</list></t>
<t>These features SHOULD be disabled for approximately 30 minutes following
termination of an emergency call.</t>
 <t>
 <list style="hanging">
<t hangText="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, sent to the
Contact: or AoR used 
in the emergency call, it should be assumed to be a callback.  The suggested
timer period is 5 minutes.  <xref target="RFC4916"/> may be used by the PSAP to
inform the endpoint of the domain of the PSAP.
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.

<!-- [rfced] Section 13:  We had trouble with the second and fourth
sentences in this paragraph.  Are one or more words missing?  If the
suggested text is not correct, please clarify.

Original (the entire paragraph is included for context):
 ED-70 Call backs SHOULD be determined by retaining the domain of the
 PSAP which answers an outgoing emergency call and instantiating a
 timer which starts when the call is terminated.  If a call is
 received from the same domain and within the timer period, sent to
 the Contact: or AoR used in the emergency call, it should be assumed
 to be a call back.  The suggested timer period is 5 minutes.
 [RFC4916] may be used by the PSAP to inform the endpoint of the
 domain of the PSAP.  Recognizing a call back 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 call back.

Suggested (using updated numbering per our question above):
 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 Contact: or 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] may be
    used by the PSAP to inform the endpoint of the domain of the PSAP.
    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. -->
</t>
</list></t>
</section>

<section anchor="Media" title="Media">
 <t>
 <list style="hanging">
<t hangText="ED-70:">Endpoints MUST send and receive media streams on RTP <xref target="RFC3550"></xref>.</t>
<t hangText="ED-71:">Normal SIP offer/answer <xref target="RFC3264"></xref> negotiations MUST be used to agree on the media streams to be used.</t>
<t hangText="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 <xref target="RFC3551"></xref> 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.</t>
<t hangText="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.</t>
<t hangText="ED-74:">Endpoints supporting Instant Messaging (IM) MUST support
either <xref target="RFC3428"></xref> or <xref target="RFC4975"></xref>.</t>
<t hangText="ED-75:">Endpoints supporting real-time text MUST use <xref
target="RFC4103"></xref>. The expectations for emergency service support for
the real-time text medium are described in <xref target="RFC5194"></xref>
Section 7.1.</t>
<t hangText="ED-76:">Endpoints supporting video MUST support H.264 per <xref
target="RFC6184"></xref>.</t>
 </list></t>
</section>

<section anchor="Testing" title="Testing">
 <t>
 <list style="hanging">
<t hangText="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.</t>
<t hangText="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 
location-hiding techniques, if they are being used, may be employed for this
dereference.

<!-- [rfced] Section 15:  We had difficulty with this sentence.  If
neither suggestion below is correct, please clarify.

Original:
 This alerts the LIS that the dereference is not for an
 actual emergency call and location hiding techniques, if they are
 being used, may be employed for this dereference.

Suggestion #1:
 This alerts the LIS that the
 dereference is not for an actual emergency call, and
 location-hiding techniques, if they are being used, may be employed
 for this dereference.

Suggestion #2:
 This alerts the LIS that the
 dereference is not for an actual emergency call and that
 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.
</t>
<t hangText="ED-79:">A PSAP accepting a test call SHOULD accept a media loopback test
<xref target="RFCYYYY"></xref> and SHOULD support the "rtp-pkt-loopback" and "rtp-start-loopback" 
options.

<!-- [rfced] Section 15:  We do not see "rtp-start-loopback" used
anywhere in [I-D.ietf-mmusic-media-loopback]; we only see
rtp-pkt-loopback and rtp-media-loopback.  Please let us know how
this sentence should be updated.

Original:
 ED-80 A PSAP accepting a test call SHOULD accept a media loopback
 test [I-D.ietf-mmusic-media-loopback] and SHOULD support the
 "rtp-pkt-loopback" and "rtp-start-loopback" options. -->

The user agent would specify a loopback attribute of "loopback-source", the
PSAP being the 
mirror. User agents should expect the PSAP to loop back no more than 3 packets of each media type 
accepted (which limits the duration of the test), after which the PSAP would normally send BYE.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
 </list></t>
</section>

<section anchor="Security" title="Security Considerations">
<t>Security considerations for emergency calling have been documented in 
<xref target="RFC5069"></xref> and <xref target="RFC6280"></xref>.  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.</t>
</section>

<section title="IANA Considerations">
<t>This document registers service URNs in the Service URN Labels registry per <xref target="RFC5031"/> for testing.</t>
<section title="Test Service URN">
<t>A new entry in the URN Service Label registry is added.  The new service is "test", the reference is this document, and the description is "self test".</t></section>
<section title="'test' Subregistry">
<t>A new subregistry is created: the 'test' Sub-Service.  The registration
process is Expert Review per <xref target="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:</t>

<figure><artwork><![CDATA[
     Service               Reference            Description
--------------------------------------------------------------------
test.sos                [this document]  test for sos
test.sos.ambulance      [this document]  test for sos.ambulance
test.sos.animal-control [this document]  test for sos.animal-control
test.sos.fire           [this document]  test for sos.fire
test.sos.gas            [this document]  test for sos.gas
test.sos.marine         [this document]  test for sos.marine
test.sos.mountain       [this document]  test for sos.mountain
test.sos.physician      [this document]  test for sos.physician
test.sos.poison         [this document]  test for sos.poison
test.sos.police         [this document]  test for sos.police
]]></artwork></figure>

</section></section>

<section title="Acknowledgements">
<t>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.</t>
</section>

  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;
      &rfc3118;
      &rfc3261;
      &rfc3263;
      &rfc3264;
      &rfc3265;
      &rfc3428;
      &rfc5389;
      &rfc3515;
      &rfc3550;
      &rfc3551;
      &rfc3856;
      &rfc3966;
      &rfc4103;
      &rfc4119;
      &rfc4301;
      &rfc4474;
      &rfc4776;
      &rfc4916;
      &rfc4967;
      &rfc4975;
      &rfc5031;
      &rfc5139;
      &rfc5222;
      &rfc5223;
      &rfc5226;
      &rfc5491;
      &rfc5626;
      &rfc5627;
      &rfc5746;
      &rfc5751;
      &rfc5985;
      &rfc5986;
      &rfc6184;
      &rfc6225;

<!-- draft-ietf-sipcore-location-conveyance (Published; RFC 6442) -->
      &rfc6442;

<!-- draft-ietf-mmusic-media-loopback (RFC YYYY) -->
<reference anchor='RFCYYYY'>
<front>
<title>An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback</title>
<author initials='H' surname='Kaplan' fullname='Hadriel Kaplan' role="editor">
    <organization />
</author>
<author initials='K' surname='Hedayat' fullname='Kaynam Hedayat'>
    <organization />
</author>
<author initials='N' surname='Venna' fullname='Nagarjuna Venna'>
    <organization />
</author>
<author initials='P' surname='Jones' fullname='Paul Jones'>
    <organization />
</author>
<author initials='N' surname='Stratton' fullname='Nathan Stratton'>
    <organization />
</author>
<date month='February' year='2013' />
</front>
<seriesInfo name='RFC' value='YYYY' />
</reference>

      <reference anchor="LLDP-MED">
        <front>
          <title>Link Layer Discovery Protocol - Media Endpoint
          Discovery</title>
          <author>
            <organization>ANSI/TIA</organization>
          </author>
          <date month="April" year="2006" />
        </front>
       <seriesInfo name="TIA Standard," value="TIA-1057"/>
      </reference>
    </references>
    <references title="Informative References">
      &rfc3325;
      &rfc5012;
      &rfc5069;
      &rfc5077;
      &rfc5194;
      &rfc6280;

<!-- draft-ietf-ecrit-framework (Published; RFC 6443) -->
      &rfc6443;
     </references>

</back>
</rfc>
