One document matched: draft-ietf-ecrit-phonebcp-03.xml
<?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 rfc2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY rfc2396 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2396.xml">
<!ENTITY rfc2401 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2401.xml">
<!ENTITY rfc3046 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.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 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 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 rfc3825 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3825.xml">
<!ENTITY rfc3841 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3841.xml">
<!ENTITY rfc3856 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3856.xml">
<!ENTITY rfc3920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3920.xml">
<!ENTITY rfc3966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml">
<!ENTITY rfc3984 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3984.xml">
<!ENTITY rfc4028 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4028.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 rfc4190 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4190.xml">
<!ENTITY rfc4474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY rfc4504 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4504.xml">
<!ENTITY rfc4507 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4507.xml">
<!ENTITY rfc4676 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4676.xml">
<!ENTITY rfc4967 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4967.xml">
<!ENTITY draft-ietf-ecrit-service-urn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-service-urn.xml">
<!ENTITY draft-ietf-sip-location-conveyance SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-location-conveyance.xml">
<!ENTITY draft-ietf-sipping-config-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-config-framework.xml">
<!ENTITY draft-ietf-sipping-toip SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-toip.xml">
<!ENTITY draft-ietf-sip-gruu SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-gruu.xml">
<!ENTITY draft-ietf-sip-outbound SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-outbound.xml">
<!ENTITY draft-ietf-sip-sips SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-sips.xml">
<!ENTITY draft-ietf-sip-connected-identity SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-connected-identity.xml">
<!ENTITY draft-ietf-ecrit-lost SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-lost.xml">
<!ENTITY draft-ietf-ecrit-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-framework.xml">
<!ENTITY draft-ietf-ecrit-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-requirements.xml">
<!ENTITY draft-ietf-ecrit-security-threats SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-security-threats.xml">
<!ENTITY draft-ietf-geopriv-pdif-lo-profile SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-pdif-lo-profile.xml">
<!ENTITY draft-ietf-sipping-service-examples SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-service-examples.xml">
<!ENTITY draft-ietf-geopriv-http-location-delivery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml">
<!ENTITY draft-ietf-geopriv-revised-civic-lo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-revised-civic-lo.xml">
<!ENTITY draft-ietf-mmusic-media-loopback SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-media-loopback.xml">
<!ENTITY draft-barnes-geopriv-lo-sec SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.barnes-geopriv-lo-sec.xml">
<!ENTITY draft-ietf-ecrit-dhc-lost-discovery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-dhc-lost-discovery.xml">
<!ENTITY draft-thomson-geopriv-lis-discovery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-lis-discovery.xml">
<!ENTITY draft-ietf-mmusic-ice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice.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 category="std" docName="draft-ietf-ecrit-phonebcp-03" ipr="full3978">
<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>US</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>US</country>
</postal>
<phone>+1-817-271-3552</phone>
<email>jmpolk@cisco.com</email>
</address>
</author>
<date day="19" month="November" year="2007" />
<area>rai</area>
<workgroup>ecrit</workgroup>
<abstract>
<t>The IETF and other standards organization 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 should use
such standards to make emergency calls.</t>
</abstract></front><middle>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
<t>This document uses terms from <xref target="RFC3261"></xref>, <xref target="I-D.ietf-ecrit-requirements"></xref> and
<xref target="I-D.ietf-ecrit-framework"></xref>.</t>
</section><section title="Introduction">
<t>This document describes how access networks, SIP user agents, proxy servers and PSAPs support emergency calling, as
outlined in <xref target="I-D.ietf-ecrit-framework"></xref>, which is designed to complement the
present document in section headings, numbering and content. This BCP succinctly describes the
requirements of end devicesand applications (requirements prefaced by "ED-"), 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
which 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 these requirements.</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="I-D.ietf-ecrit-service-urn"></xref>, which is placed in the
call set-up 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). 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 LoST protocol <xref target="I-D.ietf-ecrit-lost"></xref>, which maps a location to
a set of PSAP URIs. Each URI
resolves to a PSAP or an Emergency Services Routing Proxy (ESRP), which 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>ED-1 A device or application SHOULD support emergency calling if a user could reasonably expect
to be able to place a call for help with the device.</t>
<t>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.</t>
<t>ED-2 Devices that create media sessions and exchange audio, video and/or text, and have the
capability to establish sessions to a wide variety of addresses, and communicate over private IP
networks or the Internet, SHOULD support emergency calls.</t>
</section><section anchor="Identifying" title="Identifying an emergency call">
<t>ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If the service provider
always knows the location of the device, then the service provider could recognize them.</t>
<t>SP-2 Proxy servers SHOULD recognize emergency dial string if for some
reason the endpoint does not recognize them. This cannot be relied upon by the device if the service
provider cannot always determine the location of the device.</t>
<t>ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the Request-URI of the
INVITE.</t>
<t>ED-5/SP-4 Local dial strings MUST be recognized.</t>
<t>ED-6/SP-5 Home dial strings MAY be recognized.</t>
<t>ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST
<xref target="I-D.ietf-ecrit-lost"></xref>.</t>
<t>ED-8 Endpoints which do not recognize emergency dial strings SHOULD send dial strings as per
<xref target="RFC4967"></xref>.</t>
<t>SP-7 Proxy Servers MUST recognize emergency dial strings represented by <xref
target="RFC4967"></xref> and SHOULD recognize emergency dial strings represented by a tel URI <xref
target="RFC3966"></xref>.</t>
<t>SP-8 Service providers MAY provide home dial strings by configuration
<xref target="I-D.ietf-sipping-config-framework"></xref>.</t>
<t>ED-9 Endpoints SHOULD be able to have home dial strings provisioned by configuration.</t>
<t>ED-10 Devices SHOULD NOT have one button emergency calling initiation.</t>
<t>ED-11/SP-9 All emergency services specified in <xref target="I-D.ietf-ecrit-service-urn"></xref>
MUST be recognized.</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 elements are involved. In
Internet emergency calling, where the endpoint is located is "determined" using a variety of
measurement or wiretracing methods. Endpoints may be "configured" with their own location by the
access network. In some circumstances, a proxy server may 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 elements) in the signaling. Likewise, we employ Location
Configuration Protocols, the Location-to-Service Mapping Protocol, and Location Conveyance Protocols for these
functions. The Location-to-Service Translation protocol
<xref target="I-D.ietf-ecrit-lost"></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. In IETF protocols, civic and geospatial (geo)
forms are both supported. The civic forms include both postal and jurisdictional fields. A cell
tower/sector can be represented as a point (geo or civic) or polygon. Other forms of location
representation must be mapped into either a geo or civic for use in emergency calls.</t>
<t>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>ED-13/INT-2/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo to civic) from the form of
location the determination mechanism supplied.</t>
</section><section anchor="LocationDetermination" title="Location Determination">
<t>ED-14/INT-3/AN-2 Any suitable location determination mechanism MAY be used.</t>
<section anchor="UserLocation" title="User-entered location information">
<t>ED-15/INT-3/AN-3 Devices, intermediate Devices and/or access networks SHOULD support a manual method to "override" the
location the access network determines. Where a civic form of location is provided, all fields in
the PIDF-LO <xref target="RFC4119"></xref> and <xref target="I-D.ietf-geopriv-revised-civic-lo"></xref> MUST
be able to be specified.</t>
</section><section anchor="WireDatabase" title='Access network "wire database" location
information'>
<t>AN-4 Access networks supporting copper, fiber or other hard wired IP packet service SHOULD
support location configuration. If the network does not support location configuration, it MUST
require every device that connects to the network to support end system measured location.</t>
<t>AN-5/INT-4 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.</t>
<t>AN-6/INT-5 Access networks and intermediate devices (including enterprise networks) which support intermediate range wireless
connections (typically 100m or less of range) and which do not support a more accurate location
determination mechanism such as triangulation, MUST support location configuration where
the location of the access point is reflected as the location of the clients of that access point. 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 upstream of the intermediate device</t>
</section><section anchor="EndSystemMeasuredLocation" title="End-system measured location information">
<t>ED-16/INT-6 Devices MAY support end-system measured location. Uncertainty of less than 100 m with 95%
confidence SHOULD be available for dispatch.</t>
<t>ED-17/INT-7/AN-7 Devices that support endpoint measuring of location MUST have at least a coarse
location capability (typically <1km accuracy when not location hiding) at all times for routing of calls.
This mechanism MAY be a service provided by the access network.</t>
</section><section anchor="NetworkMeasuredLocation" title="Network-measured location information">
<t>AN-8 Access networks MAY provide network-measured location determination. Wireless access
network which do not support network measured location MUST require that all devices connected to the
network have end-system measured location. Uncertainty of less than 100 m with 95% confidence
SHOULD be available for dispatch.</t>
<t>AN-9 Access networks that provide network measured location MUST have at least a coarse location
(typically <1km when not location hiding) capability at all times for routing of calls.</t>
<t>AN-10 Access networks with range of <10 meters MUST provide a location to mobile devices connected
to it. The location provided SHOULD be that of the access point location unless a more accurate mechanism
is provided.</t>
</section></section><section anchor="WhoAddsLocation" title="Who adds location, endpoint or proxy">
<t>ED-18/INT-8 Endpoints SHOULD do configure their own location.</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>ED-19/INT-9/SP-13 Where proxies provide location on behalf of endpoints, the 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>
</section><section anchor="LocationReference" title="Location and references to location">
<t>ED-20/INT-10 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>
</section><section anchor="LocationConfiguration" title="End system location configuration">
<t>ED-21/INT-11 Devices MUST support all of: DHCP location options <xref target="RFC4676"></xref> and
<xref target="RFC3825"></xref>, HELD <xref target="I-D.ietf-geopriv-http-location-delivery"></xref>
and LLDP-MED <xref target="LLDP-MED"></xref>.</t>
<t>AN-11/INT-12 The access network MUST support at least one of: DHCP location options, HELD or LLDP-MED.
</t>
<t>AN-12/INT-13 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
meeting this BCP.</t>
<t>ED-22/INT-14 Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The
first one that succeeds in supplying location can be used.</t>
<t>AN-13/INT-15 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>ED-??/INT-??/SP-?? 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>ED-?? Where the operating system supporting application programs which 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 LLDP-MED, the operating system MUST provide a published API conforming to ED-12 through
ED-18 and ED-21 through ED-27. It is RECOMMENDED that all operating systems provide such an API.</t>
</section><section anchor="WhenConfigure" title="When location should be configured">
<t>ED-23/INT-16 Endpoints SHOULD obtain location immediately after obtaining local network configuration
information.When HELD is the LCP the client MUST support a random back-off period (between 30
seconds and 300 seconds) for re-trying the HELD query, when no response is received.</t>
<t>ED-??/INT-?? If the device is configured to use DHCP for bootstrapping, 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="RFC4676"></xref>, <xref target="RFC3825"></xref>,
<xref target="I-D.thomson-geopriv-lis-discovery"></xref> and
<xref target="I-D.ietf-ecrit-dhc-lost-discovery"></xref>.</t>
<t>ED-??/INT-?? If the device sends a DHCP INFORM 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="RFC4676"></xref>, <xref target="RFC3825"></xref>,
<xref target="I-D.thomson-geopriv-lis-discovery"></xref> and
<xref target="I-D.ietf-ecrit-dhc-lost-discovery"></xref>.</t>
<t>ED-24/INT-16 To minimize the effects of VPNs that do not allow split tunneling VPNs, location configuration SHOULD be attempted
before such tunnels are established.</t>
<t>ED-25/INT-17 Software which 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>AN-14 Network administrators MUST take care in assigning IP addresses such that VPN address
assignments can be distinguished from local devices (by subnet choice, for example), and LISs
SHOULD NOT attempt to provide location to addresses that arrive via VPN connections unless it can
accurately determine the location for such addresses. </t>
<t>AN-15 Placement of NAT devices SHOULD consider the effect of the NAT on the LCP. </t>
<t>ED-26/INT-18 For devices which are not expected to roam, refreshing location on the order of once per day is
RECOMMENDED.</t>
<t>ED-27/INT-19 For devices which 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 can detect that it has moved, for example when it
changes access points, the device SHOULD refresh its location.</t>
<t>ED-28/INT-20/AN-16 It is RECOMMENDED that location determination not take longer than 250 ms to obtain
routing location and systems SHOULD be designed such that the typical response is under 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>
</section><section anchor="Conveyance" title="Conveying location in SIP">
<t>ED-29/SP-14 Location sent between SIP elements MUST be conveyed using
<xref target="I-D.ietf-sip-location-conveyance"></xref>.</t>
</section><section anchor="LocationUpdate" title="Location updates">
<t>ED-30/AN-17 Where the absolute location or the accuracy of location of the endpoint may change
between the time the call is received at the PSAP and the time dispatch is completed, location
update mechanisms MUST be provided.</t>
<t>ED-31/AN-18 Mobile devices MUST be provided with a mechanism to get repeated location updates to
track the motion of the device during the complete processing of the call.</t>
<t>ED-32/AN-19 The LIS SHOULD provide a location reference which permits a subscription with
appropriate filtering.</t>
<t>ED-33/AN-20 For calls sent with location-by-reference, with a SIP or SIPS scheme, the server
resolving the reference MUST support a SUBSCRIBE <xref target="RFC3118"></xref> to the presence
event <xref target="RFC3856"></xref>. For other location-by-reference schemes, the PSAP will have to
repeatedly dereference the URI to determine if the device moved. </t>
<t>ED-34 If location was sent by value, and the endpoint gets 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.</t>
</section><section anchor="MultipleLocations" title="Multiple locations">
<t>ED-35 If a UA has more than one location available to it, it MUST choose one location to
route the call towards the PSAP.</t>
<t>SP-15 If a proxy inserts location on behalf of an endpoint, and it has multiple locations
available for the endpoint it MUST choose one location to use to route the call towards the PSAP.
</t>
<t>SP-16 If a proxy is attempting to insert location but the UA conveyed a location to it, the
proxy MUST use the UA's location for routing and MUST convey that location towards the PSAP. It MAY
also include what it believes the location to be in a separate Geolocation header.</t>
<t>SP-17 All location objects received by a proxy MUST be delivered to the PSAP.</t>
<t>ED-36/SP-18 Location objects MUST contain information about the method by which the location was
determined, such as GPS, manually entered, or based on access network topology included in a PIDF-
LO "method" element. In addition, the source of the location information MUST be included in a
PIDF-LO "provided-by" element.</t>
<t>ED-37/SP-19 The "used-for-routing" parameter MUST be set to the location that was used to query
LoST.</t>
</section><section anchor="Validation" title="Location validation">
<t>AN-21 A LIS should perform location validation of civic locations via LoST before
entering a location in its database.</t>
<t>ED-38 Endpoints SHOULD validate civic locations when they receive them from their LCP.
Validation SHOULD be performed in conjunction with the LoST route query to minimize load on the
LoST server.</t>
</section><section anchor="DefaultLocation" title="Default location">
<t>AN-22 When the access network cannot determine the actual location of the caller, it MUST supply
a default location. The default SHOULD be chosen to be as close to the probable location of the
device as the network can determine. See <xref target="I-D.ietf-ecrit-framework"></xref></t>
<t>SP-20 Proxies handling emergency calls MUST insert a default location if the call does not
contain a location and the proxy does not have a method for obtaining a better location.</t>
<t>AN-23/SP-21 Default locations MUST be marked with method=Default and an appropriate provided-by
in the PIDF-LO.</t>
</section><section anchor="OtherLocation" title="Other location considerations">
<t>ED-39 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>ED-40/AN-24 To prevent against spoofing of the DHCP server, elements implementing DHCP for
location configuration SHOULD use <xref target="RFC3118"></xref>.</t>
<t>ED-41 S/MIME MUST NOT be used to encrypt the SIP Geolocation header or bodies.</t>
<t>ED-42/SP-22 TLS MUST be used to protect location (but see <xref target="TLS"></xref>). IPSEC
<xref target="RFC2401"></xref> is an acceptable alternative.</t>
</section><section title="LIS and LoST Discovery">
<t>ED-xx Endpoints MUST support one or more mechanisms that allow them to determine
their public IP address. Examples include ICE <xref target="I-D.ietf-mmusic-ice"></xref>
and HTTP get.</t>
<t>ED-xx Endpoints MUST support LIS discovery as described in <xref target="I-D.thomson-geopriv-lis-discovery"></xref>, and
the LoST discovery as described in <xref target="I-D.ietf-ecrit-dhc-lost-discovery"></xref>. </t>
<t>ED-xx The device MUST have a configurable default LoST server parameter.
If the device is provided by or managed by service provider, it is expected that the
service provider will configure this option.</t>
</section></section><section anchor="UnitializedDevices" title="Uninitialized devices">
<t>ED-43 Uninitialized devices SHOULD NOT lead a user to believe an emergency call could be placed
on it unless local regulations require it.</t>
<t>ED-44/AN-25/SP-23 Uninitialized devices SHOULD NOT be capable of placing an emergency call
unless local regulations require it.</t>
<t>ED-45/AN-26/SP-24 Uninitialized devices that can place emergency calls MUST supply location the
same as a fully capable device would.</t>
<t>ED-46/SP-25 Unitialized devices MUST supply a call back URI. See <xref
target="UnitializedDevices"></xref>.</t>
<t>ED-47/SP-26 Unitialized devices MUST include identifiers in the signaling that can be used by
the service provider to identify the device and to allow filtering of calls from the device by the
PSAP/ESRP.</t>
</section><section anchor="Routing" title="Routing the call to the PSAP">
<t>ED-48 Endpoints who obtain their own location SHOULD perform LoST mapping to the PSAP URI.</t>
<t>ED-49 Mapping SHOULD be performed at boot time and whenever location changes beyond the service
boundary obtained from a prior LoST mapping operation or the time-to-live value of that response
has expired. The value MUST be cached for possible later use.</t>
<t>ED-50 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>ED-51 The endpoint SHOULD attempt to update the LoST mapping at the time of an emergency call.
If it cannot obtain a new mapping quickly, it MUST use the cached value.</t>
<t>SP-27 All proxies in the outbound path SHOULD recognize emergency calls with a Request URI of
the service URN in the "sos" tree. An endpoint places a service URN in the Request URI to indicate
that the endpoint understood the call was an emergency call. A proxy that processes such a call
looks for the presence of a SIP Route header field with a URI of a PSAP. Absence of such a Route header
indicates the UAC was unable to invoke LoST and the proxy MUST perform the LoST mapping and insert
a Route header field with the URI obtained.</t>
<t>SP-28 To deal with old user agents that predate this specification and with UAs that do not have
access to their own location data, 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>SP-29 Proxy servers performing mapping SHOULD use location obtained from the access network for
the mapping. If no location is available, a default location (see <xref
target="DefaultLocation"></xref>) MUST be supplied.</t>
<t>SP-30 A proxy server which attempts mapping and fails to get a mapping MUST provide a default
mapping. A suitable default mapping would be the mapping obtained previously for the default
location appropriate for the caller.</t>
<t>ED-52/SP-31 <xref target="RFC3261"></xref> and <xref target="RFC3263"></xref> procedures MUST be
used to route an emergency call towards the PSAP's URI.</t>
<t>ED-53 Initial INVITES MUST provide an Offer <xref target="RFC3264"></xref>.</t>
</section><section anchor="Signaling" title="Signaling of emergency calls">
<t>ED-54 Best Current Practice for SIP user agents <xref target="RFC4504"></xref> including handling
of audio, video and real-time text <xref target="RFC4103"></xref> MUST be applied. This memo can
be considered as an addition to <xref target="RFC4504"></xref> for endpoints.</t>
<section anchor="TLS" title="Use of TLS">
<t>ED-55/SP-32 TLS MUST be specified when attempting to signal an emergency call with SIP per
<xref target="I-D.ietf-sip-sips"></xref>. IPSEC <xref target="RFC2401"></xref> is an acceptable
alternative.</t>
<t>ED-56/SP-33 If TLS session establishment fails, the call MUST be retried without TLS.</t>
<t>ED-57/SP-34 <xref target="I-D.ietf-sip-outbound"></xref> is RECOMMENDED to maintain persistent
TLS connections between elements.</t>
<t>ED-58/AN-27 TLS MUST be specified when attempting to retrieve location (configuration or
dereferencing) with HELD. The use of <xref target="RFC4507"></xref> is RECOMMENDED to minimise
the time to establish TLS sessions.</t>
<t>ED-59/AN33 If TLS session establishment fails, the location retrieveal MUST be retried without TLS.</t>
</section><section anchor="UAsignaling" title="SIP signaling requirements for User Agents">
<t>ED-60 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 cannot interpert local
dial strings, the Request-URI SHOULD be a dial string URI <xref
target="RFC4967"></xref> with the dialed digits.</t>
<t>The To header SHOULD be a service URN in the "sos" tree. If the device
cannot do interpret local dial strings, the To: SHOULD be a dial string URI with the dialed
digits.</t>
<t>The From header MUST be present and SHOULD be the AoR of the caller.</t>
<t>A Via header MUST be present and SHOULD include the URI of the device.</t>
<t>A Route header SHOULD be present with a PSAP URI obtained from LoST (see <xref
target="Routing"></xref>) and the loose route parameter. If the device does not interpet dial plans, no
Route header will be present.</t>
<t>A Contact header MUST be present which MUST be globally routable, for example a GRUU <xref
target="I-D.ietf-sip-gruu"></xref>, to permit an immediate call-back to the specific device which
placed the emergency call.</t>
<t>Other headers MAY be included as per normal SIP behavior.</t>
<t>A Supported header MUST be included with the 'geolocation' option tag
<xref target="I-D.ietf-sip-location-conveyance"></xref>, unless the device does not understand the concept of SIP
location.</t>
<t>If a device understands the SIP location conveyance
<xref target="I-D.ietf-sip-location-conveyance"></xref> extension and has its location available, it MUST
include location either by-value or by-reference.</t>
<t>If a device understands the SIP Location Conveyance extension and has its location unavailable
or unknown to that device, it MUST include a Supported header with a "geolocation" option tag,
and MUST NOT include a Geolocation header, and not include a PIDF-LO message body.</t>
<t>If a device understands the SIP Location Conveyance extension and supports LoST
<xref target="I-D.ietf-ecrit-lost"></xref>, the Geolocation "used-for-routing"
header parameter MUST be added to the corresponding URI in the Geolocation
header.</t>
<t>A normal SDP offer SHOULD be included in the INVITE. If voice is supported the offer MUST include
the G.711 codec, see <xref target="Media"></xref>.</t>
<t>If the device includes location-by-value, the UA MUST support multipart message bodies, since
SDP will likely be also in the INVITE.</t>
<t>A UAC SHOULD include a "inserted-by=endpoint" header parameter on all Geolocation headers .
This informs downstream elements which device entered the location at this URI (either cid-URL or
location-by-reference URI).</t>
<t>SIP Caller Preferences <xref target="RFC3841"></xref> MAY be used to signal how the PSAP
should handle the call. For example, a language preference expressed in an Accept-Language header
may be used as a hint to cause the PSAP to route the call to a call taker who speaks the
requested language. SIP Caller Preferences may also be used to indicate a need to invoke a relay
service for communication with people with disabilities in the call.</t>
</list></t>
</section><section anchor="ProxySignaling" title="SIP signaling requirements for proxy servers">
<t>SP-35 SIP Proxy servers processing emergency calls:
<list style="numbers">
<t>If the proxy does 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 as above. Location-by-reference MUST be used
because proxies must not insert bodies.</t>
<t>Include the Geolocation "inserted-by=server" and "used-for-routing" 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>
<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
with a PSAP URI, it MUST run LoST routing. If a location was provided (which should be the
case), the proxy uses that location to query LoST. The proxy may have to dereference a location
by reference to get a value. If a location is not present, and the proxy can query a LIS which
has the location of the UA it MUST do so. If no location is present, and the proxy does not have
access to a LIS which could provide location, the proxy MUST supply a default location (See <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 "inserted-by=" parameter in any Geolocation: header received on the call MUST NOT be
modified or deleted in transit.</t>
<t>The proxy SHOULD NOT modify any parameters in Geolocation headers received in the call. It
MAY add a Geolocation header. Such an additional location SHOULD NOT be used for routing; the
location provided by the UA should be used.</t>
<t>Either a P-Asserted-Identity <xref target="RFC3325"></xref> or an Identity header <xref
target="RFC4474"></xref>, or both, MUST be included to identify the sender.</t>
</list></t>
</section></section><section anchor="Callbacks" title="Call backs">
<t>SP-36 Unitialized devices, like any device MUST have a globally routable URI in a Contact: header.</t>
<t>SP-37 Unitialized devices SHOULD have a persistent URI in a P-Asserted-Identity: header if there
is some way to assign such an identifier to the device.</t>
</section><section anchor="MidCall" title="Mid-call behavior">
<t>ED-61/SP-38 During the course of an emergency call, devices and proxies MUST support REFER
transactions and the Referred-by: header <xref target="RFC3515"></xref>.</t>
<t>ED-62/SP-39 User agents and proxies MUST support Session Timer <xref target="RFC4028"></xref> to
guard against session corruption.</t>
</section><section anchor="Termination" title="Call termination">
<t>ED-63 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT generate a BYE request (or
equivalent for other non-SIP signaling). The PSAP must be the only entity that can terminate a
call. If the user "hangs up" an emergency call, the device should alert the user, and when answered,
reconnect the caller to the PSAP.</t>
<t>ED-64 There can be a case where the session signaling path is lost, and the user agent does not
receive the BYE. If the call is hung up, and the session timer expires the call MAY be declared
lost. If in the interval, an incoming call is received from the domain of the PSAP, the device
SHOULD drop the old call and alert for the (new) incoming call. Dropping of the old call SHOULD
only occur if the user is attempting to hang up; the domain of an incoming call can only be
determined from the From header, which is not reliable, and could be spoofed. Dropping an active
call by a new call with a spoofed From: would be a DoS attack.</t>
</section><section anchor="DisableFeatures" title="Disabling of features">
<t>ED-65/SP-40 User Agents and proxys MUST disable outgoing call features such as
<list style="symbols">
<t>Call Waiting</t>
<t>Call Transfer</t>
<t>Three Way Call</t>
<t>Flash hold</t>
<t>Outbound Call Blocking</t>
</list>
when an emergency call is established. Also see ED-72 in <xref target="Media"></xref>.</t>
<t>ED-66/SP-41 The emergency dialstrings SHOULD NOT be permitted in Call Forward numbers or speed
dial lists.</t>
<t>ED-67/SP-42 The User Agent and Proxies SHOULD disable the following incoming call features on
call backs from the PSAP:
<list style="symbols">
<t>Call Waiting</t>
<t>Do Not Disturb</t>
<t>Call Forward (all kinds)</t>
</list></t>
<t>ED-68 Call backs SHOULD be determined by retaining the domain of the PSAP which answers an
outgoing emergency call and instantiating a timer which starts when the call is terminated. If a
call is received from the same domain and within the timer period, sent to the Contact: or AoR used
in the emergency call, it should be assumed to be a call back. The suggested timer period is 5
minutes.</t>
</section><section anchor="Media" title="Media">
<t>ED-69 Endpoints MUST send and receive media streams on RTP <xref target="RFC3550"></xref>.</t>
<t>ED-70 Normal SIP offer/answer <xref target="RFC3264"></xref> negotiations MUST be used to agree
on the media streams to be used.</t>
<t>ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law if they could be used in North America) encoded
voice as described in <xref target="RFC3551"></xref>. It is desirable to include wideband codecs such
as AMR-WB in the offer.</t>
<t>ED-72 Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency
calls. PSAP call takers sometimes get information on what is happening in the background to
determine how to process the call.</t>
<t>ED-73 Endpoints supporting IM MUST support either <xref target="RFC3428"></xref> or <xref
target="RFC3920"></xref>.</t>
<t>ED-74 Endpoints supporting real-time text MUST use <xref target="RFC4103"></xref>. The
expectations for emergency service support for the real-time text medium, described in <xref
target="I-D.ietf-sipping-toip"></xref>, Section 7.1 SHOULD be fulfilled.</t>
<t>ED-75 Endpoints supporting video MUST support H.264 per <xref target="RFC3984"></xref>.</t>
</section><section anchor="Testing" title="Testing">
<t>ED-76 INVITE requests to a service URN with a urn parameter of "test" indicates a request for an
automated test. For example, "urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response
indicates that the address was recognized and a 404 (Not found) that it was not. A 486 (Busy Here)
MUST be returned if the test service is busy, and a 488 (Not Acceptable Here) MUST be returned if
the PSAP does not support the test mechanism.</t>
<t>ED-77 In its response to the test, the PSAP MAY include a text body (text/plain) indicating the
identity of the PSAP, the requested service, and the location reported with the call. For the
latter, the PSAP SHOULD return location-by-value even if the original location delivered with the
test was by-reference. If the location-by-reference was supplied, and the dereference requires
credentials, the PSAP SHOULD use credentials supplied by the LIS for test purposes. This alerts the
LIS that the dereference is not for an actual emergency call and location hiding techniques, if
they are being used, may be employed for this dereference. The response MAY include the connected
identity of the PSAP per <xref target="I-D.ietf-sip-connected-identity"></xref>.</t>
<t>ED-78 A PSAP accepting a test call SHOULD accept a media loopback test
<xref target="I-D.ietf-mmusic-media-loopback"></xref> 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>ED-79 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>ED-80 User agents MUST NOT place a test call immediately after booting. If the IP address
changes after booting, the UA should wait a random amount of time (in perhaps a 30 minute period,
sufficient for any avalanche restart to complete) and then test.</t>
<t>ED-81 PSAPs MAY refuse repeated requests for test from the same device in a short period of
time. Any refusal is signaled with a 486 or 488 response.</t>
</section><section anchor="Security" title="Security Considerations">
<t>Security considerations for emergency calling have been documented in
<xref target="I-D.ietf-ecrit-security-threats"></xref>, and
<xref target="I-D.barnes-geopriv-lo-sec"></xref>. </t>
</section><section title="Acknowledgements">
<t>Work group members participating in the creation and review of this document include include
Hannes Tschofenig, Ted Hardie, Marc Linsner, Roger Marshall, Stu Goldman, Shida Schubert, James
Winterbottom, Barbara Stark, Richard Barnes and Peter Blatherwick.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2131;
&rfc2396;
&rfc2401;
&rfc3046;
&rfc3118;
&rfc3261;
&rfc3263;
&rfc3264;
&rfc3325;
&rfc3428;
&rfc3515;
&rfc3550;
&rfc3551;
&rfc3825;
&rfc3841;
&rfc3856;
&rfc3920;
&rfc3966;
&rfc3984;
&rfc4028;
&rfc4103;
&rfc4119;
&rfc4190;
&rfc4474;
&rfc4504;
&rfc4507;
&rfc4676;
&rfc4967;
&draft-ietf-ecrit-service-urn;
&draft-ietf-sip-location-conveyance;
&draft-ietf-sipping-config-framework;
&draft-ietf-sipping-toip;
&draft-ietf-sip-gruu;
&draft-ietf-sip-outbound;
&draft-ietf-sip-sips;
&draft-ietf-sip-connected-identity;
&draft-ietf-ecrit-lost;
&draft-ietf-ecrit-framework;
&draft-ietf-ecrit-requirements;
&draft-ietf-ecrit-security-threats;
&draft-ietf-geopriv-pdif-lo-profile;
&draft-ietf-geopriv-http-location-delivery;
&draft-ietf-geopriv-revised-civic-lo;
&draft-ietf-mmusic-media-loopback;
&draft-barnes-geopriv-lo-sec;
&draft-ietf-ecrit-dhc-lost-discovery;
&draft-thomson-geopriv-lis-discovery;
&draft-ietf-mmusic-ice;
<reference anchor="LLDP">
<front>
<title>IEEE802.1ab Station and Media Access Control</title>
<author fullname="">
<organization>IEEE</organization>
</author>
<date day="01" month="Dec" year="2004" />
</front>
</reference>
<reference anchor="LLDP-MED">
<front>
<title>ANSI/TIA-1057 Link Layer Discovery Protocol - Media Endpoint
Discovery</title>
<author fullname="">
<organization>TIA</organization>
</author>
<date year="" />
</front>
</reference>
</references>
<section title="BCP Requirements Sorted by Responsible Party">
<section title="Requirements of End Devices">
<t>ED-1 if a user could reasonably expect to be able to place a call for help with the device, then
the device or application SHOULD support emergency calling. </t>
<t>ED-2 Devices that create media sessions and exchange audio, video and/or text, and have the
capability to establish sessions to a wide variety of addresses, and communicate over private IP
networks or the Internet, SHOULD support emergency calls</t>
<t>ED-3 Endpoints SHOULD do dial string recognition of emergency dial strings</t>
<t>ED-4 Emergency calls MUST be marked with a Service URN in the Request-URI of the INVITE.</t>
<t>ED-5 Local dial strings MUST be recognized.</t>
<t>ED-6 Home dial strings MAY be recognized.</t>
<t>ED-7 Local emergency dial strings SHOULD be determined from LoST LoST
<xref target="I-D.ietf-ecrit-lost"></xref>.</t>
<t>ED-8 Endpoints which do not recognize emergency dial strings SHOULD send dial strings as per
<xref target="RFC4967"></xref>.</t>
<t>ED-9 Endpoints SHOULD be able to have home dial strings provisioned by configuration.</t>
<t>ED-10 Devices SHOULD NOT have one button emergency calling initiation.</t>
<t>ED-11 All emergency services specified in <xref target="I-D.ietf-ecrit-service-urn"></xref> MUST
be recognized. Devices/Service Providers MUST be capable of recognizing all of the associated dial
strings.</t>
<t>ED-12 Endpoints and Service Providers MUST be prepared to handle location represented in either
civic or geo form. </t>
<t>ED-13 Elements MUST NOT convert (civic to geo or geo to civic) from the form of location the
determination mechanism supplied.</t>
<t>ED-14 Any suitable location determination mechanism MAY be used.</t>
<t>ED-15 Devices and/or access networks SHOULD support a manual method to "override" the location
the access network determines. Where a civic form of location is provided, all fields in the PIDF-
LO <xref target="RFC4119"></xref> and <xref target="I-D.ietf-geopriv-revised-civic-lo"></xref> MUST be able
to be specified.</t>
<t>ED-16 devices MAY support end-system measured location. Uncertainty of less than 100 m with 95%
confidence SHOULD be available for dispatch. </t>
<t>ED-17 Devices that support endpoint measuring of location MUST have at least a coarse location
(<1km) capability at all times for routing of calls. This mechanism MAY be a service provided by
the access network.</t>
<t>ED-18 Endpoints SHOULD do location configuration themselves.</t>
<t>ED-19 Where proxies provide location on behalf of endpoints, the 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 that the service provider can detect the appropriate
local dial strings at the time of the call.</t>
<t>ED-20 Devices SHOULD be able to accept and forward location by value or by reference. An end
device that receives location by reference (and does not also get the corresponding value) MUST be
able to perform a dereference operation to obtain a value.</t>
<t>ED-21 endpoints MUST support all of: DHCP Location options <xref target="RFC4676"></xref> and
<xref target="RFC3825"></xref>, HELD<xref target="I-D.ietf-geopriv-http-location-delivery"></xref>
and LLDP-MED<xref target="LLDP-MED"></xref>. </t>
<t>ED-22 Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The
first one that succeeds in supplying location can be used. </t>
<t>ED-23 Endpoints SHOULD obtain location immediately after obtaining local network configuration
information. </t>
<t>ED-24 To minimize the effects of non-bypassable VPNs, location configuration SHOULD be attempted
before such tunnels are established. </t>
<t>ED-25 Software which 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>ED-26 For devices which are not expected to roam, refreshing on the order of once per day is
RECOMMENDED </t>
<t>ED-27 For devices which roam, refresh of location SHOULD be more frequent, with the frequency
related to the mobility of the device and the ability of the access network to support the refresh
operation. There can be instances in which a device is aware of when it moves, for example when it
changes access points. When this type of event occurs, the device SHOULD refresh its location. </t>
<t>ED-28 It is RECOMMENDED that location determination not take longer than 250 ms to obtain
routing location and systems SHOULD be designed such that the typical response is under 100ms.
However, as much as 3 seconds to obtain routing location MAY be tolerated if location accuracy can
be substantially improved over what can be obtained in 250 ms. </t>
<t>ED-29 Location sent between SIP elements MUST be conveyed using
<xref target="I-D.ietf-sip-location-conveyance"></xref>.</t>
<t>ED-30 Where the absolute location or the accuracy of location of the endpoint may change
between the time the call is received at the PSAP and the time dispatch is completed, location
update mechanisms MUST be provided.</t>
<t>ED-31 mobile devices MUST be provided with a mechanism to get repeated location updates to track
the motion of the device during the complete processing of the call.</t>
<t>ED-32 The LIS SHOULD provide a location reference which permits a subscription with appropriate
filtering.</t>
<t>ED-33 For calls sent with location-by-reference, with a SIP or SIPS scheme, the server resolving
the reference MUST support a SUBSCRIBE <xref target="RFC3118"></xref> to the presence event <xref
target="RFC3856"></xref>. For other location-by-reference schemes, a repeated location dereference
by the PSAP MUST be supported. </t>
<t>ED-34 If location was sent by value, and the endpoint gets updated location, it MUST send the
updated location to the PSAP via reINVITE or UPDATE. Such updates SHOULD be limited to no more than
one update every 10 seconds. </t>
<t>ED-35 If a UA has more than one location available to it, it MUST choose one location to use to
route the call towards the PSAP. </t>
<t>ED-36/ Location objects MUST contain information about the method by which the location was
determined, such as GPS, manually entered, or based on access network topology included in a PIDF-
LO ?method? element. In addition, the source of the location information MUST be included in a
PIDF-LO "provided-by" element. </t>
<t>ED-37 The "used-for-routing" parameter MUST be set to the location that was used to query
LoST.</t>
<t>ED-38 Endpoints SHOULD validate civic locations when they receive them from their LCP.
Validation SHOULD be performed in conjunction with the LoST route query to minimize load on the
LoST server.</t>
<t>ED-39 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>ED-40 To prevent against spoofing of the DHCP server, elements implementing DHCP for location
configuration SHOULD use <xref target="RFC3118"></xref>. </t>
<t>ED-41 S/MIME MUST NOT be used to protect the Geolocation header or bodies.</t>
<t>ED-42 TLS MUST be used to protect location (but see <xref target="TLS"></xref>).</t>
<t>ED-43 Uninitialized devices SHOULD NOT lead a user to believe an emergency call could be placed
on it unless local regulations require it.</t>
<t>ED-44 Uninitialized devices SHOULD NOT be capable of placing an emergency call unless local
regulations require it.</t>
<t>ED-45 Uninitialized devices that can place emergency calls MUST supply location the same as a
fully capable device would.</t>
<t>ED-46 Unitialized Devices MUST supply a call back URI. See <xref
target="UnitializedDevices"></xref></t>
<t>ED-47 Unitialized Devices MUST include identifiers in the signaling that can be used by the
service provider to identify the device and to allow filtering of calls from the device by the
PSAP/ESRP.</t>
<t>ED-48 Endpoints who obtain their own location SHOULD perform LoST mapping to the PSAP URI whenever
they get an initial or updated location.</t>
<t>ED-49 Mapping SHOULD be performed at boot time and whenever location changes beyond the service
boundary obtained from a prior LoST mapping operation or the time-to-live value of that response
has expired. The value MUST be cached for possible use.</t>
<t>ED-50 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>ED-51 The endpoint SHOULD attempt to update the LoST mapping at the time of an emergency call.
If it cannot obtain a new mapping quickly, it MUST use the cached value.</t>
<t>ED-52 <xref target="RFC3261"></xref> and <xref target="RFC3263"></xref> procedures MUST be used
to route an emergency call towards the PSAP's URI.</t>
<t>ED-53 Initial INVITES MUST provide an Offer <xref target="RFC3264"></xref></t>
<t>ED-54 Best Current Practice for SIP user agents <xref target="RFC4504"></xref> including handling
of audio, video and real-time text <xref target="RFC4103"></xref> SHOULD be applied. This memo can
be considered as an addition to <xref target="RFC4504"></xref> for endpoints.</t>
<t>ED-55 TLS MUST be specified when attempting to signal an emergency call with SIP per
<xref target="I-D.ietf-sip-sips"></xref>. IPSEC <xref target="RFC2401"></xref> is an acceptable
alternative.</t>
<t>ED-56 If TLS session establishment fails, the call MUST be retried with sip:</t>
<t>ED-57 <xref target="I-D.ietf-sip-outbound"></xref> is RECOMMENDED to maintain persistent TLS
connections between elements </t>
<t>ED-58 https: MUST be specified when attempting to retrieve location (configuration or
dereferencing) with HELD. The use of <xref target="RFC4507"></xref> is RECOMMENDED to minimise
the time to establish TLS sessions.</t>
<t>ED-59 If TLS session establishment fails, the location retrieveal MUST be retried with http:</t>
<t>ED-60 The initial SIP signaling Method is an INVITE:
<list style="numbers">
<t>The Request URI SHOULD be the service URN in the "sos" tree, If the device cannot do local
dialstring interpretation, the Request-URI SHOULD be a dialstring URI <xref
target="RFC4967"></xref> with the dialed digits.</t>
<t>The To: header MUST be present and SHOULD be a service URN in the "sos" tree. If the device
cannot do local dialstring interpretation, the To: SHOULD be a dialstring URI with the dialed
digits.</t>
<t>The From: header MUST be present and SHOULD be the AoR of the caller.</t>
<t>A Via: header MUST be present and SHOULD include the URI of the device.</t>
<t>A Route: header SHOULD be present with a PSAP URI obtained from LoST (see <xref
target="Routing"></xref> ) and the loose route parameter. A sips URI <xref
target="RFC3261"></xref> SHOULD be specified, unless the operation must be retried due to a
failure to establish a TLS connection. If the device does not do dial plan interpretation, no
Route: header will be present.</t>
<t>A Contact header MUST be present which MUST be globally routable, for example a GRUU <xref
target="I-D.ietf-sip-gruu"></xref>, to permit an immediate call-back to the specific device which
placed the emergency call.</t>
<t>Other headers MAY be included as per normal sip behavior.</t>
<t>A Supported: header MUST be included with the 'geolocation' option tag
<xref target="I-D.ietf-sip-location-conveyance"></xref>, unless the device does not understand the concept of SIP
Location.</t>
<t>If a device understands the SIP Location Conveyance
<xref target="I-D.ietf-sip-location-conveyance"></xref> extension and has its location available,
it MUST include location either by-
value or by-reference.</t>
<t>If a device understands the SIP Location Conveyance extension and has its location unavailable
or unknown to that device, it MUST include a Supported header with a "geolocation" option tag,
and MUST NOT include a Geolocation header, and not include a PIDF-LO message body.</t>
<t>If a device understands the SIP Location Conveyance extension and supports LoST
<xref target="I-D.ietf-ecrit-lost"></xref> then whichever location is used for routing the
message towards the PSAP or ESRP, even if there is only one, the Geolocation "used-for-routing"
header parameter SHOULD be added to the corresponding URI in the Geolocation
header.</t>
<t>A normal SDP offer SHOULD be included in the INVITE. If voice is supported the offer MUST include
the G.711 codec, see <xref target="Media"></xref>.</t>
<t>If the device includes location-by-value, the UA MUST support multipart message bodies, since
SDP will likely be also in the INVITE.</t>
<t>A UAC SHOULD include a "inserted-by=endpoint" header parameter on all Geolocation headers .
This informs downstream elements which device entered the location at this URI (either cid-URL or
location-by-reference URI).</t>
<t>SIP Caller Preferences <xref target="RFC3841"></xref> MAY be used to signal how the PSAP
should handle the call. </t>
</list></t>
<t>ED-61 During the course of an emergency call, devices and proxies MUST support REFER
transactions and the Referred-by: header <xref target="RFC3515"></xref>.</t>
<t>ED-62 User agents and proxies MUST Support Session Timer <xref target="RFC4028"></xref> to guard
against session corruption.</t>
<t>ED-63 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT generate a BYE request (or
equivalent for other non-SIP signaling). The PSAP must be the only entity that can terminate a
call. If the user "hangs up" an emergency call, the device should alert, and when answered,
reconnect the caller to the PSAP.</t>
<t>ED-64 There can be a case where the session signaling path is lost, and the user agent does not
receive the BYE. If the call is hung up, and the session timer expires the call MAY be declared
lost. If in the interval, an incoming call is received from the domain of the PSAP, the device
SHOULD drop the old call and alert for the (new) incoming call. Dropping of the old call SHOULD
only occur if the user is attempting to hang up; the domain of an incoming call can only be
determined from the From header, which is not reliable, and could be spoofed. Dropping an active
call by a new call with a spoofed From: would be a DoS attack.</t>
<t>ED-65 User Agents and proxys MUST disable outgoing call features such as:
<list style="symbols">
<t>Call Waiting</t>
<t>Call Transfer</t>
<t>Three Way Call</t>
<t>Flash hold</t>
<t>Outbound Call Blocking</t>
</list>
when an emergency call is established. Also see ED-72 in <xref target="Media"></xref>.</t>
<t>ED-66 The emergency dialstrings SHOULD NOT be permitted in Call Forward numbers or speed dial
lists. </t>
<t>ED-67 The User Agent and Proxies SHOULD disable the following incoming call features on call
backs from the PSAP:
<list style="symbols">
<t>Call Waiting</t>
<t>Do Not Disturb</t>
<t>Call Forward (all kinds)</t>
</list></t>
<t>ED-68 Call backs SHOULD be determined by retaining the domain of the PSAP which answers an
outgoing emergency call and instantiating a timer which starts when the call is terminated. If a
call is received from the same domain and within the timer period, sent to the Contact: or AoR used
in the emergency call, it should be assumed to be a call back. The suggested timer period is 5
minutes.</t>
<t>ED-69 Endpoints MUST send and receive media streams on RTP <xref target="RFC3550"></xref>.</t>
<t>ED-70 Normal SIP offer/answer <xref target="RFC3264"></xref> negotiations MUST be used to agree
on the media streams to be used. </t>
<t>ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law in North America) encoded
voice as described in <xref target="RFC3551"></xref>. It is desirable to support wideband codecs in
the offer. </t>
<t>ED-72 Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency
calls. PSAP call takers sometimes get information on what is happening in the background to
determine how to process the call. </t>
<t>ED-73 Endpoints supporting IM MUST support either <xref target="RFC3428"></xref> or <xref
target="RFC3920"></xref>. </t>
<t>ED-74 Endpoints supporting real-time text MUST use <xref target="RFC4103"></xref>. The
expectations for emergency service support for the real-time text medium, described in <xref
target="I-D.ietf-sipping-toip"></xref>, section 7.1 SHOULD be fulfilled.</t>
<t>ED-75 Endpoints supporting video MUST support H.264 per <xref target="RFC3984"></xref>. </t>
<t>ED-76 INVITE requests to a service urn with a urn parameter of "test" indicates a request for an
automated test. For example, "urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response
indicates that the address was recognized and a 404 (Not found) that it was not. A 486 (Busy Here)
MUST be returned if the test service is busy, and a 488 (Not Acceptable Here) MUST be returned if
the PSAP does not support the test mechanism. </t>
<t>ED-77 In its response to the test, the PSAP MAY include a text body (text/plain) indicating the
identity of the PSAP, the requested service, and the location reported with the call. For the
latter, the PSAP SHOULD return location-by-value even if the original location delivered with the
test was by-reference. If the location-by-reference was supplied, and the dereference requires
credentials, the PSAP SHOULD use credentials supplied by the LIS for test purposes. This alerts the
LIS that the dereference is not for an actual emergency call and location hiding techniques, if
they are being used, may be employed for this dereference. The response MAY include the connected
identity of the PSAP per <xref target="I-D.ietf-sip-connected-identity"></xref>.</t>
<t>ED-78 A PSAP accepting a test call SHOULD accept a media loopback test
<xref target="I-D.ietf-mmusic-media-loopback"></xref> 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>ED-79 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 IP address assignment test, a full test
SHOULD be repeated approximately every 30 days with a random interval.</t>
<t>ED-80 User agents MUST NOT place a test call immediately after booting. If the IP address
changes after booting, the UA should wait a random amount of time (in perhaps a 30 minute period,
sufficient for any avalanche restart to complete) and then test.</t>
<t>ED-81 PSAPs MAY refuse repeated requests for test from the same device in a short period of
time. Any refusal is signaled with a 486 or 488 response.</t>
</section><section title="Requirements of Service Providers">
<t>SP-1 If a device or application expects to be able to place a call for help, the service that
supports it SHOULD facilitate emergency calling. </t>
<t>SP-2 Proxy servers SHOULD do dial string recognition of emergency dial strings if for some
reason the endpoint does not recognize them.</t>
<t>SP-3 Emergency calls MUST be marked with a Service URN in the Request-URI of the INVITE.</t>
<t>SP-4 Local dial strings MUST be recognized.</t>
<t>SP-5 Home dial strings MAY be recognized.</t>
<t>SP-6 Local emergency dial strings SHOULD be determined from LoST LoST
<xref target="I-D.ietf-ecrit-lost"></xref>.</t>
<t>SP-7 Proxy Servers MUST recognize emergency dial strings represented by <xref
target="RFC4967"></xref> and SHOULD recognize dial strings represented by a tel URI <xref
target="RFC3966"></xref>.</t>
<t>SP-8 Service providers MAY provide home dial strings by configuration
<xref target="I-D.ietf-sipping-config-framework"></xref>.</t>
<t>SP-9 All emergency services specified in <xref target="I-D.ietf-ecrit-service-urn"></xref> MUST
be recognized. Devices/Service Providers MUST be capable of recognizing all of the associated dial
strings.</t>
<t>SP-10 Endpoints and Service Providers MUST be prepared to handle location represented in either
civic or geo form.</t>
<t>SP-11 Elements MUST NOT convert (civic to geo or geo to civic) from the form of location the
determination mechanism supplied.</t>
<t>SP-12 Proxies MAY provide location on behalf of devices it supports if: <list style="symbols">
<t>It has a relationship with all access networks the device could connect to, and the
relationship allows it to obtain location.</t>
<t>It has an identifier that can be used by the access network to determine the location of the
endpoint, particularly in the presence of NAT and VPN tunnels that may exist between the access
network and the service provider.</t>
</list></t>
<t>SP-13 Where proxies provide location on behalf of endpoints, the 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 that the service provider can detect the appropriate
local dial strings at the time of the call.</t>
<t>SP-14 Location sent between SIP elements MUST be conveyed using
<xref target="I-D.ietf-sip-location-conveyance"></xref>.</t>
<t>SP-15 If a proxy inserts location on behalf of an endpoint, and it has multiple locations
available for the endpoint it MUST choose one location to use to route the call towards the
PSAP.</t>
<t>SP-16 If a proxy is attempting to assert location but the UA conveyed a location to it, the
proxy must use the UA?s location for routing and MUST convey that location towards the PSAP. It MAY
also include what it believes the location to be.</t>
<t>SP-17 All location objects received by a proxy MUST be delivered to the PSAP. </t>
<t>SP-18 Location objects MUST contain information about the method by which the location was
determined, such as GPS, manually entered, or based on access network topology included in a PIDF-
LO ?method? element. In addition, the source of the location information MUST be included in a
PIDF-LO "provided-by" element. </t>
<t>SP-19 The "used-for-routing" parameter MUST be set to the location that was used to query
LoST.</t>
<t>SP-20 Proxies handling emergency calls MUST insert a default location if the call does not
contain a location.</t>
<t>SP-21 Default locations MUST be marked with method=Default and an appropriate provided-by in the
PIDF-LO.</t>
<t>SP-22 TLS MUST be used to protect location (but see <xref target="TLS"></xref>). IPSEC
<xref target="RFC2401"></xref> is an acceptable alternative.</t>
<t>SP-23 Uninitialized devices SHOULD NOT be capable of placing an emergency call unless local
regulations require it.</t>
<t>SP-24 Uninitialized devices that can place emergency calls MUST supply location the same as a
fully capable device would.</t>
<t>SP-25 Unitialized Devices MUST supply a call back URI. See <xref
target="UnitializedDevices"></xref></t>
<t>SP-26 Unitialized Devices MUST include identifiers in the signaling that can be used by the
service provider to identify the device and to allow filtering of calls from the device by the
PSAP/ESRP.</t>
<t>SP-27 All proxies in the outbound path SHOULD recognize emergency calls with a Request URI of
the service URN in the "sos" tree. An endpoint places a service URN in the Request URI to indicate
that the endpoint understood the call was an emergency call. A proxy that processes such a call
looks for the presence of a Route header with a URI of a PSAP. Absence of such a Route header
indicates the UAC was unable to invoke LoST and the proxy MUST perform the LoST mapping and insert
a Route header with the URI obtained.</t>
<t>SP-28 To deal with old user agents that predate this specification and with UAs that do not have
access to their own location data, proxies that recognize a call as an emergency call that is not
marked as such (see <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>SP-29 Proxy servers performing mapping SHOULD use location obtained from the access network for
the mapping. If no location is available, a default location (see <xref
target="DefaultLocation"></xref>) MUST be supplied.</t>
<t>SP-30 A proxy server which attempts mapping and fails to get a mapping MUST provide a default
mapping. A suitable default mapping would be the mapping obtained previously for the default
location appropriate for the caller. </t>
<t>SP-31 <xref target="RFC3261"></xref> and <xref target="RFC3263"></xref> procedures MUST be used
to route an emergency call towards the PSAP's URI.</t>
<t>SP-32 TLS MUST be specified when attempting to signal an emergency call with SIP per
<xref target="I-D.ietf-sip-sips"></xref>. IPSEC <xref target="RFC2401"></xref> is an acceptable
alternative.</t>
<t>SP-33 If TLS session establishment fails, the call MUST be retried with sip:</t>
<t>SP-34 <xref target="I-D.ietf-sip-outbound"></xref> is RECOMMENDED to maintain persistent TLS
connections between elements </t>
<t>SP-35 SIP Proxy servers processing emergency calls:
<list style="numbers">
<t>If the proxy does dial plan interpretation 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 as per 10-12 above. Location-by-reference MUST be used
because proxies may not insert bodies.</t>
<t>Include the Geolocation "inserted-by=server" AND "used-for-routing" 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 dialstring) with the service URN appropriate for
the emergency dialstring.</t>
<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
with a PSAP URI, it MUST run LoST routing. If a location was provided (which should be the
case), the proxy uses that location to query LoST. The proxy may have to dereference a location
by reference to get a value. If a location is not present, and the proxy can query a LIS which
has the location of the UA it MUST do so. If no location is present, and the proxy does not have
access to a LIS which could provide location, the proxy MUST supply a default location (See <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 "inserted-by=" parameter in any Geolocation header received on the call MUST NOT be
modified or deleted in transit.</t>
<t>The proxy SHOULD NOT modify any parameters in Geolocation headers received in the call. It
MAY add a Geolocation header. Such an additional location SHOULD NOT be used for routing; the
location provided by the UA should be used.</t>
<t>Either a P-Asserted-Identity <xref target="RFC3325"></xref> or an Identity header <xref
target="RFC4474"></xref>, or both, MUST be included to identify the sender.</t>
</list></t>
<t>SP-36 Unitialized devices MUST have a globally routable URI in a Contact header</t>
<t>SP-37 Unitialized devices SHOULD have a persistent URI in a P-Asserted-Identity header</t>
<t>SP-38 During the course of an emergency call, devices and proxies MUST support REFER
transactions and the Referred-by header <xref target="RFC3515"></xref>.</t>
<t>SP-39 User agents and proxies MUST Support Session Timer <xref target="RFC4028"></xref> to guard
against session corruption. </t>
<t>SP-40 User Agents and proxys MUST disable outgoing call features such as:
<list style="symbols">
<t>Call Waiting</t>
<t>Call Transfer</t>
<t>Three Way Call</t>
<t>Flash hold</t>
<t>Outbound Call Blocking</t>
</list>
when an emergency call is established. Also see ED-72 in <xref target="Media">.</xref></t>
<t>SP-41 The emergency dialstrings SHOULD NOT be permitted in Call Forward numbers or speed dial
lists. </t>
<t>SP-42 The User Agent and Proxies SHOULD disable the following incoming call features on call
backs from the PSAP:
<list style="symbols">
<t>Call Waiting</t>
<t>Do Not Disturb</t>
<t>Call Forward (all kinds)</t>
</list></t>
</section><section title="Requirements of Access Networks">
<t>AN-1 Elements MUST NOT convert (civic to geo or geo to civic) from the form of location the
determination mechanism supplied.</t>
<t>AN-2 Any suitable location determination mechanism MAY be used.</t>
<t>AN-3 Devices and/or access networks SHOULD support a manual method to "override" the location
the access network determines. Where a civic form of location is provided, all fields in the PIDF-
LO <xref target="RFC4119"></xref> and <xref target="I-D.ietf-geopriv-revised-civic-lo"></xref> MUST be able
to be specified.</t>
<t>AN-4 Access networks supporting copper, fiber or other hard wired IP packet service SHOULD
support location configuration. If the network does not support location configuration, it MUST
require every device that connects to the network to support end system measured location. </t>
<t>AN-5 Access networks providing wire database location information SHOULD provide interior
location data where possible. It is RECOMMENDED that interior location be provided when spaces
exceed approximately 650 m2</t>
<t>AN-6 Access networks (including enterprise networks) which support intermediate range wireless
connections (typically 100m or less of range) and which do not support a more accurate location
determination mechanism such as triangulation, MUST support location configuration which reports
the location of the access point as the location of the clients of that access point.</t>
<t>AN-7 Devices that support endpoint measuring of location MUST have at least a coarse location
(<1km) capability at all times for routing of calls. This mechanism MAY be a service provided by
the access network.</t>
<t>AN-8 Access networks MAY provide network measured location determination. Wireless access
network which do not support network measured location MUST require all devices connected to the
network have end-system measured location. Uncertainty of less than 100 m with 95% confidence
SHOULD be available for dispatch. </t>
<t>AN-9 Access networks that provide network measured location MUST have at least a coarse location
(<1km) capability at all times for routing of calls.</t>
<t>AN-10 Access networks with range of <10M MUST provide a location to mobile devices connected
to it. The location provided SHOULD be that of the beacon location unless a more accurate mechanism
is provided. </t>
<t>AN-11 The access network MUST support at least one of DHCP location options, HELD or LLDP-MED.
</t>
<t>AN-12 Where a router is employed between a LAN and WAN in a small (less than approximately
650m2) area, the LAN MUST reflect the location provided by the WAN to the LAN. Where the area is larger,
the LAN MUST have a location configuration mechanism meeting this BCP.</t>
<t>AN-13 Access networks that support more than one LCP MUST reply with the same location
information (within the limits of the data format for the specific LCP) for all LCPs it
supports.</t>
<t>AN-14 Network administrators MUST take care in assigning IP addresses such that VPN address
assignments can be distinguished from local devices (by subnet choice, for example), and LISs
SHOULD NOT attempt to provide location to addresses that arrive via VPN connections unless it can
accurately determine the location for such addresses. </t>
<t>AN-15 Placement of NAT devices SHOULD consider the effect of the NAT on the LCP. </t>
<t>AN-16 It is RECOMMENDED that location determination not take longer than 250 ms to obtain
routing location and systems SHOULD be designed such that the typical response is under 100ms.
However, as much as 3 seconds to obtain routing location MAY be tolerated if location accuracy can
be substantially improved over what can be obtained in 250 ms. </t>
<t>AN-17 Where the absolute location or the accuracy of location of the endpoint may change
between the time the call is received at the PSAP and the time dispatch is completed, location
update mechanisms MUST be provided.</t>
<t>AN-18 mobile devices MUST be provided with a mechanism to get repeated location updates to track
the motion of the device during the complete processing of the call.</t>
<t>AN-19 The LIS SHOULD provide a location reference which permits a subscription with appropriate
filtering.</t>
<t>AN-20 For calls sent with location-by-reference, with a SIP or SIPS scheme, the server resolving
the reference MUST support a SUBSCRIBE <xref target="RFC3118"></xref> to the presence event <xref
target="RFC3856"></xref>. For other location-by-reference schemes, a repeated location dereference
by the PSAP MUST be supported. </t>
<t>AN-21 Location validation of civic locations via LoST SHOULD be performed by the LIS before
entering a location in its database.</t>
<t>AN-22 When the access network cannot determine the actual location of the caller, it MUST supply
a default location. The default SHOULD be chosen to be as close to the probable location of the
device as the network can determine.</t>
<t>AN-23 Default locations MUST be marked with method=Default and an appropriate provided-by in the
PIDF-LO.</t>
<t>AN-24 To prevent against spoofing of the DHCP server, elements implementing DHCP for location
configuration SHOULD use <xref target="RFC3118"></xref>. </t>
<t>AN-25 Uninitialized devices SHOULD NOT be capable of placing an emergency call unless local
regulations require it.</t>
<t>AN-26 Uninitialized devices that can place emergency calls MUST supply location the same as a
fully capable device would.</t>
<t>AN-27 https: MUST be specified when attempting to retrieve location (configuration or
dereferencing) with HELD. The use of <xref target="RFC4507"></xref> is RECOMMENDED to minimise
the time to establish TLS sessions.</t>
</section></section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 20:37:37 |