draft-ietf-ecrit-phonebcp-01.txt   draft-ietf-ecrit-phonebcp-02.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track J. Polk Intended status: Standards Track J. Polk
Expires: September 6, 2007 Cisco Systems Expires: March 21, 2008 Cisco Systems
March 05, 2007 September 18, 2007
Best Current Practice for Communications Services in support of Best Current Practice for Communications Services in support of
Emergency Calling Emergency Calling
draft-ietf-ecrit-phonebcp-01.txt draft-ietf-ecrit-phonebcp-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2007. This Internet-Draft will expire on March 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Requesting help in an emergency using a communications device such as The IETF has several efforts targeted at standardizing various
a telephone or mobile is an accepted practice in most of the world. aspects of placing emergency calls. This memo describes best current
As communications devices increasingly utilize the Internet to practice on how devices, networks and services should use such
interconnect and communicate, users will continue to expect to use standards to make emergency calls.
such devices to request help, regardless of whether or not they
communicate using IP. The emergency response community will have to
upgrade their facilities to support the wider range of communications
services, but cannot be expected to handle wide variation in device
and service capability. The IETF has several efforts targeted at
standardizing various aspects of placing emergency calls. This memo
describes best current practice on how devices and services should
use such standards to reliably make emergency calls
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Which devices and services should support emergency calls . . 4 3. Overview of how emergency calls are placed . . . . . . . . . . 3
4. Location . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Which devices and sevices should support emergency calls . . 3
4.1. Endpoints learn their own location . . . . . . . . . . . . 5 5. Identifying an emergency call . . . . . . . . . . . . . . . . 4
4.2. Location Configuration Protocols . . . . . . . . . . . . . 5 6. Location and its role in an emergency call . . . . . . . . . . 5
4.3. Self reported Location . . . . . . . . . . . . . . . . . . 6 6.1. Types of location information . . . . . . . . . . . . . . 5
4.4. When Location should be Configured . . . . . . . . . . . . 6 6.2. Location Determination . . . . . . . . . . . . . . . . . . 5
4.5. Other location considerations . . . . . . . . . . . . . . 7 6.2.1. User-entered location information . . . . . . . . . . 5
5. Determining an emergency call . . . . . . . . . . . . . . . . 7 6.2.2. Access network "wire database" location
6. Session Signaling . . . . . . . . . . . . . . . . . . . . . . 9 information . . . . . . . . . . . . . . . . . . . . . 5
6.1. SIP signaling requirements for User Agents . . . . . . . . 9 6.2.3. End-system measured location information . . . . . . 6
6.2. SIP signaling requirements for proxy servers and B2BUAs . 10 6.2.4. Network measured location information . . . . . . . . 6
6.3. Mapping from Location to a PSAP URI . . . . . . . . . . . 11 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 6
6.4. Routing the call . . . . . . . . . . . . . . . . . . . . . 12 6.4. Location and references to location . . . . . . . . . . . 7
6.5. Responding to PSAP signaling . . . . . . . . . . . . . . . 12 6.5. End system location configuration . . . . . . . . . . . . 7
6.6. Disabling of features . . . . . . . . . . . . . . . . . . 13 6.6. When location should be configured . . . . . . . . . . . . 7
7. Location Update . . . . . . . . . . . . . . . . . . . . . . . 13 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 8
8. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 8
9. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 9
9.1. Testing Mechanism . . . . . . . . . . . . . . . . . . . . 14 6.10. Location validation . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 10
10.1. Threats against endpoints . . . . . . . . . . . . . . . . 15 6.12. Other location considerations . . . . . . . . . . . . . . 10
10.2. Threats against the Emergency Service . . . . . . . . . . 16 7. Uninitialized devices . . . . . . . . . . . . . . . . . . . . 10
11. Normative References . . . . . . . . . . . . . . . . . . . . . 16 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 21 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. SIP signaling requirements for User Agents . . . . . . . . 12
9.3. SIP signaling requirements for proxy servers . . . . . . . 13
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 14
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 15
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 15
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
16. Security Considerations . . . . . . . . . . . . . . . . . . . 17
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
18. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. BCP Requirements Sorted by Responsible Party . . . . 22
A.1. Requirements of End Devices . . . . . . . . . . . . . . . 22
A.2. Requirements of Service Providers . . . . . . . . . . . . 30
A.3. Requirements of Access Networks . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Requirements notation 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses terms from [RFC3261],
[I-D.ietf-ecrit-requirements] and [I-D.ietf-ecrit-framework].
2. Introduction 2. Introduction
This document describes how SIP User Agents and proxy servers support This document describes how SIP User Agents and proxy servers support
emergency calling, as outlined in [I-D.ietf-ecrit-framework]. Here, emergency calling, as outlined in [I-D.ietf-ecrit-framework], which
an emergency call refers to a communications session established by a is designed to complement the present document in section headings,
user to a "Public Safety Answering Point" (PSAP) which is a call numbering and content. This BCP succinctly describes the
center established by response agencies to accept emergency calls. requirements of end devices and applications, access networks,
We differentiate such calls from other sessions which are created by service providers and PSAPs to achieve globally interoperable
responders using public communications infrastructure often involving emergency calling on the Internet.
some kind of priority access as defined in Emergency
Telecommunications Service (ETS) in IP Telephony [RFC4190]. By
implication, this document describes the interface between the
emergency services network and the Internet. This memo also
describes how location may be obtained from the local access
infrastructure (broadband network), and thus specifies requirements
to support location in such infrastructure.
Making an emergency call involves the use of location information, 3. Overview of how emergency calls are placed
referring to the physical location of the caller. Location is used
within the emergency calling system to route a call to the correct
PSAP, as well as by the PSAP to choose the correct responder, and
direct them to the person in need of assistance.
The steps involved in an emergency call from an IP based device are An emergency call can be distinguished (Section 5) from any other
(with a rough ordering of operation) call by a unique Service URN[I-D.ietf-ecrit-service-urn], which is
1. Device connects to access network, and obtains initial location placed in the call set-up signaling when a home or visited emergency
2. User dials visited location's emergency number dial string is detected. Because emergency services are local to
3. User device identifies call as emergency call specific geographic regions, a caller must obtain his location
4. User device includes location indication (by value or by (Section 6) prior to making emergency calls.. To get this location,
reference) in the call set-up messaging either a form of measuring (e.g. GPS) (Section Section 6.2.3) device
5. emergency call set-up is routed to appropriate PSAP based on location in the endpoint is deployed, or the endpoint is configured
location of the caller (Section 6.5) with its location from the access network's Location
6. call is established with PSAP Information Server (LIS). The location is conveyed ( Section 6.7) in
7. caller's location is presented to PSAP operator for dispatch the SIP signaling with the call. The call is routed (Section 8)
based on location using the LoST protocol [I-D.ietf-ecrit-lost])
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 INVITE request.
As a quick overview for a typical Ethernet connected telephone using 4. Which devices and sevices should support emergency calls
SIP signaling:
o the phone "boots" and connects to its access network
o the phone would get location from the DHCP server [an L7 server]
or the first level switch's LLDP server.
o the phone obtains the local emergency dialstring(s) from the ED-1 if a user could reasonably expect to be able to place a call for
[I-D.ietf-ecrit-lost] server. help with the device, then the device or application SHOULD support
o It recognizes an emergency call from the dialstrings and uses emergency calling.
"urn:service:sos" to mark an emergency call.
o It would determine the PSAP's URI by using the
[I-D.ietf-ecrit-lost] mapping server from the location provided
o It would put its location in the SIP INVITE as a PIDF-LO in the
body of the INVITE (or a reference to location in a Location
header) [I-D.ietf-sip-location-conveyance] and forward the call to
its first hop proxy.
o The proxy recognizes the call as an emergency call and routes the
call using normal SIP routing mechanisms.
o The call is established and common media streams opened.
Best Current Practice for SIP user agents including handling of audio SP-1 If a device or application expects to be able to place a call
and real-time text [RFC4103]media detailed in [RFC4504] SHOULD be for help, the service that supports it SHOULD facilitate emergency
applied. This memo can be considered an addition to it for calling.
endpoints.
3. Which devices and services should support emergency calls 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.
Support for voice calls and real-time text calls placed through PSTN 5. Identifying an emergency call
facilities or systems connected to the PSTN is found in present
PSAPs. Future PSAPs will however support Internet connectivity and a
wider range of media types and provide higher functionality.. In
general, if a user could reasonably expect to be able to call for
help with the device, then the device or service should support
emergency calling. Certainly, any device or service that looks like
and works like a telephone (wired or mobile) should support emergency
calling, but increasingly, users have expectations that other devices
and services should work.
Using current (evolving) standards, devices that create media ED-3 Endpoints SHOULD do dial string recognition of emergency dial
sessions and exchange audio, video and/or text, and have the strings.
capability to establish sessions to a wide variety of addresses, and
communicate over private IP networks or the Internet, should support
emergency calls.
4. Location SP-2 Proxy servers SHOULD do dial string recognition of emergency
dial strings if for some reason the endpoint does not recognize them.
Location is central to the operation of emergency services. Location ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the
is used to route a call to the PSAP that serves the location, and it Request-URI of the INVITE.
is used to dispatch responders to the person in need of help. It is
frequently the case that the user in an emergency is unable to
provide a unique, valid location themselves. For this reason,
automatic location is the norm.
In Internet emergency calling, we "Determine" where the endpoint is ED-5/SP-4 Local dial strings MUST be recognized.
located using a variety of measurement or wiretracing methods. We
"Configure" endpoints with their own location. We "Map" the location
to the URI to send the call to, and we "Convey" the location to the
PSAP (and other elements) in the signaling. These topics are
detailed in [I-D.ietf-ecrit-framework].
4.1. Endpoints learn their own location ED-6/SP-5 Home dial strings MAY be recognized.
With Internet based communications services, determining where the ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST
caller is located is more problematic than in PSTN and mobile [I-D.ietf-ecrit-lost].
systems. Existing wired phones are tethered with a wire that is
connected directly to a call control device, a circuit switch.
Cellular phones are tethered via a radio channel to a cell tower,
which connects that cell phone to a circuit switch. The primary
difficulty with IP based phones is that the connectivity, whether
wired or radio channel, is decoupled from the call control device.
The communications service may not have any relationship with the
access network carrier, and, with NAT and VPN tunnels, may have no
way to even find out who the access carrier is.
For this reason, standards have been created for endpoints (devices) ED-8 Endpoints which do not recognize emergency dial strings SHOULD
to obtain location information where it is the access network that send dial strings as per [RFC4967].
knows the location of the endpoint. To obtain location information,
the endpoint can use a Location Configuration Protocol. The endpoint
is a subscriber to both the access network and the communications
service, and thus is in a position to obtain its location from the
access network, and supply it to the communications service. These
issues, and the necessity for endpoints and access networks to
support LCPs is detailed in [I-D.ietf-ecrit-framework].
4.2. Location Configuration Protocols SP-7 Proxy Servers MUST recognize emergency dial strings represented
by [RFC4967] and SHOULD recognize dial strings represented by a tel
URI [RFC3966].
For devices that operate on a network where the network operator SP-8 Service providers MAY provide home dial strings by configuration
controls the specification of every device connected to that network [I-D.ietf-sipping-config-framework].
that could be used for emergency calls, the method by which location
is determined need not be an IETF standard, but can be any method
that achieves the desired result. Such a method MUST be specified,
and every device MUST support it. It is recommended that, in
addition, the network SHOULD support one or more of DHCP,
[Placeholder for L7 LCP} or LLDP-MED.
For all other devices, the device MUST support DHCP, [Placeholder for ED-9 Endpoints SHOULD be able to have home dial strings provisioned
L7 LCP] and LLDP-MED. The access network MUST support at least one by configuration.
of these.
DHCP [RFC2131] has been enhanced to provide the location of a device. ED-10 Devices SHOULD NOT have one button emergency calling
[RFC3825] describes how a geo-location (lat/lon/alt) may be obtained initiation.
and [RFC4676] describes how a civic (street address) location can be
obtained via DHCP.
[Placeholder for HELD, RELO or other L7 location determination ED-11/SP-9 All emergency services specified in
methods] [I-D.ietf-ecrit-service-urn] MUST be recognized. Devices/Service
Providers MUST be capable of recognizing all of the associated dial
strings.
[LLDP] with [LLDP-MED] extensions provides location configuration 6. Location and its role in an emergency call
applicable in many enterprise environments.
For devices that operate in a network where the network operator Location usually involves several steps to process and multiple
controls the specification of every device connected to that network, elements are involved. In Internet emergency calling, where the
but the network attachment supports upstream networks to which endpoint is located is "Determined" using a variety of measurement or
communications devices are connected (such as any network that wiretracing methods. Endpoints may be "Configured" with their own
supports Ethernet connected telephones and terminal adapters), the location by the access network. In some circumstances, a proxy
method by which location is determined need not be an IETF standard, server may insert location into the signaling on behalf of the
but can be any method which achieves the desired result. However, endpoint. The location is "Mapped" to the URI to send the call to,
the network attachment MUST support at least one of DHCP [L7 LCP] or and the location is "Conveyed" to the PSAP (and other elements) in
LLDP-MED for upstream communications devices to obtain location. For the signaling. Likewise, we employ Location Configuration Protocols,
smaller interior (e.g, LAN) networks, the DHCP, [L7 LCP] or LLDP-MED Location Mapping Protocols, and Location Conveyance Protocols for
server should simply repeat the location obtained from the access these functions. The Location-to-Service Translation protocol
network. For larger networks, other mechanisms, such as a DHCP Relay [I-D.ietf-ecrit-lost] is the Location Mapping Protocol defined by the
Agent [RFC3046] SHOULD be used to provide more accurate location of IETF.
endpoints.
4.3. Self reported Location 6.1. Types of location information
Self reported location, where a user enters location himself, is There are several ways location can be specified. In IETF protocols,
generally unacceptable in emergency calls, although it is being used civic and geospatial (geo) forms are both supported. The civic forms
prior to automatic location determination schemes being fielded. include both postal and jurisdictional fields. A cell tower/sector
Local laws may govern what is acceptable in any country or area. can be represented as a point (geo or civic) or polygon. Other forms
Devices and/or access networks SHOULD support a manual method to of location representation must be mapped into either a geo or civic
"override" the location the access network determines. The access for use in emergency calls.
network generally only knows the location of its demarcation point
between the access network and the subscriber. The subscriber could
have an extended network behind the demarc unknown to the access
network. A method to account for this condition SHOULD be provided.
4.4. When Location should be Configured ED-12/SP-10 Endpoints and Service Providers MUST be prepared to
handle location represented in either civic or geo form.
Devices SHOULD get location immediately after obtaining local network ED-13/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo to
configuration information. It is essential for the location to be civic) from the form of location the determination mechanism
determined BEFORE any VPN tunnels are established. It is equally supplied.
essential that this location information is *not* overwritten by any
process engaged from establishing a VPN connection. In other words,
the established VPN to Chicago from the device in Dallas MUST NOT
overwrite the Dallas location for any reason especially an emergency
call.
It is desirable that location information be periodically refreshed. 6.2. Location Determination
For devices which are not expected to roam, refreshing on the order
of once per day is RECOMMENDED. 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.
It is desirable for location information to be requested immediately ED-14/AN-2 Any suitable location determination mechanism MAY be used.
before placing an emergency call. However, if there is any delay in
getting more recent location, the call SHOULD be placed with the most
recent location information the device has. It is RECOMMENDED that
the device not wait longer than 1 sec to obtain updated location, and
systems should ideally be designed such that the typical response is
under 100ms. These numbers are empirically derived, but are intended
to keep total call signaling time below 2 seconds. There are
conflicts between the time it takes to generate location when
measuring techniques are used and the desire to route the call
quickly. If an accurate location cannot be determined quickly, a
rough location SHOULD be returned within 100ms which can be used to
route the call. The location of the nearest base station in a
wireless network is an example of a rough location.
4.5. Other location considerations 6.2.1. User-entered location information
If the LCP does not return location in the form of a PIDF-LO ED-15/AN-3 Devices and/or access networks SHOULD support a manual
method to "override" the location the access network determines.
Where a civic form of location is provided, all fields in the PIDF-LO
[RFC4119] and [I-D.ietf-geopriv-revised-civic-lo] MUST be able to be
specified.
6.2.2. Access network "wire database" location information
AN-4 Access networks supporting copper, fiber or other hard wired IP
packet service SHOULD support location configuration. If the network
does not support location configuration, it MUST require every device
that connects to the network to support end system measured location.
AN-5 Access networks providing wire database location information
SHOULD provide interior location data where possible. It is
RECOMMENDED that interior location be provided when spaces exceed
approximately 650 m2.
AN-6 Access networks (including enterprise networks) which support
intermediate range wireless connections (typically 100m or less of
range) and which do not support a more accurate location
determination mechanism such as triangulation, MUST support location
configuration which reports the location of the access point as the
location of the clients of that access point.
6.2.3. End-system measured location information
ED-16 devices MAY support end-system measured location. Uncertainty
of less than 100 m with 95% confidence SHOULD be available for
dispatch.
ED-17/AN-7 Devices that support endpoint measuring of location MUST
have at least a coarse location (<1km) capability at all times for
routing of calls. This mechanism MAY be a service provided by the
access network.
6.2.4. Network measured location information
AN-8 Access networks MAY provide network measured location
determination. Wireless access network which do not support network
measured location MUST require all devices connected to the network
have end-system measured location. Uncertainty of less than 100 m
with 95% confidence SHOULD be available for dispatch.
AN-9 Access networks that provide network measured location MUST have
at least a coarse location (<1km) capability at all times for routing
of calls.
AN-10 Access networks with range of <10M MUST provide a location to
mobile devices connected to it. The location provided SHOULD be that
of the beacon location unless a more accurate mechanism is provided.
6.3. Who adds location, endpoint or proxy
ED-18 Endpoints SHOULD do location configuration themselves.
SP-12 Proxies MAY provide location on behalf of devices it supports
if:
o It has a relationship with all access networks the device could
connect to, and the relationship allows it to obtain location.
o It has an identifier that can be used by the access network to
determine the location of the endpoint, particularly in the
presence of NAT and VPN tunnels that may exist between the access
network and the service provider.
ED-19/SP-13 Where proxies provide location on behalf of endpoints,
the proxy MUST provide a mechanism to supply emergency dial strings
to the device if the device recognizes them, or the proxy MUST track
the location of the device with sufficient accuracy and timeliness to
be able to recognize the local dial string at the time of an
emergency call.
6.4. Location and references to location
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.
6.5. End system location configuration
ED-21 endpoints MUST support all of: DHCP Location options [RFC4676]
and [RFC3825], HELD[I-D.ietf-geopriv-http-location-delivery] and
LLDP-MED[LLDP-MED].
AN-11 The access network MUST support at least one of DHCP location
options, HELD or LLDP-MED.
AN-12 Where a router is employed between a LAN and WAN in a small
(less than approximately 650m2), the LAN MUST reflect the location
provided by the WAN to the LAN.
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.
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.
6.6. When location should be configured
ED-23 Endpoints SHOULD obtain location immediately after obtaining
local network configuration information.
ED-24 To minimize the effects of non-bypassable VPNs, location
configuration SHOULD be attempted before such tunnels are
established.
ED-25 Software which uses LCPs SHOULD locate and use the actual
hardware network interface.
AN-14 Network administrators MUST take care in assigning IP addresses
such that VPN address assignments can be distinguished from local
devices (by subnet choice, for example), and LISs should not attempt
to provide location to addresses that arrive via VPN connections.
AN-15 Placement of NAT devices should consider the effect of the NAT
on the LCP.
ED-26 For devices which are not expected to roam, refreshing on the
order of once per day is RECOMMENDED.
ED-27 For devices which roam, refresh of location SHOULD be more
frequent, with the frequency related to the mobility of the device
and the ability of the access network to support the refresh
operation. There can be instances in which a device is aware of when
it moves, for example when it changes access points. When this type
of event occurs, the device SHOULD refresh its location.
ED-28/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.
6.7. Conveying location in SIP
ED-29/SP-14 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sip-location-conveyance].
6.8. Location updates
ED-30/AN-17 Where the absolute location, or the accuracy of location
of the endpoint may change between the time the call is received at
the PSAP and the time dispatch is completed, location update
mechanisms MUST be provided.
ED-31/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.
ED-32/AN-19 The LIS SHOULD provide a location reference which permits
a subscription with appropriate filtering.
ED-33/AN-20 For calls sent with location-by-reference, with a SIP or
SIPS scheme, the server resolving the reference MUST support a
SUBSCRIBE [RFC3118] to the presence event [RFC3856]. For other
location-by-reference schemes, a repeated location dereference by the
PSAP MUST be supported.
ED-34 If location was sent by value, and the endpoint gets updated
location, it MUST send the updated location to the PSAP via reINVITE
or UPDATE. Such updates SHOULD be limited to no more than one update
every 10 seconds.
6.9. Multiple locations
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.
SP-15 If a proxy inserts location on behalf of an endpoint, and it
has multiple locations available for the endpoint it MUST choose one
location to use to route the call towards the PSAP.
SP-16 If a proxy is attempting to assert location but the UA conveyed
a location to it, the proxy must use the UA?s location for routing
and MUST convey that location towards the PSAP. It MAY also include
what it believes the location to be.
SP-17 All location objects received by a proxy MUST be delivered to
the PSAP.
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.
ED-37/SP-19 The "used-for-routing" parameter MUST be set to the
location that was used to query LoST.
6.10. Location validation
AN-21 Location validation of civic locations via LoST SHOULD be
performed by the LIS before entering a location in its database.
ED-38 Endpoints SHOULD validate civic locations when they receive
them from their LCP. Validation SHOULD be performed in conjunction
with the LoST route query to minimize load on the LoST server.
6.11. Default location
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.
SP-20 Proxies handling emergency calls MUST insert a default location
if the call does not contain a location.
AN-23/SP-21 Default locations MUST be marked with method=Default and
an appropriate provided-by in the PIDF-LO.
6.12. Other location considerations
ED-39 If the LCP does not return location in the form of a PIDF-LO
[RFC4119], the endpoint MUST map the location information it receives [RFC4119], the endpoint MUST map the location information it receives
from the configuration protocol to a PIDF-LO. from the configuration protocol to a PIDF-LO.
To prevent against spoofing of the DHCP server, devices implementing ED-40/AN-24 To prevent against spoofing of the DHCP server, elements
DHCP for location configuration SHOULD use [RFC3118]. implementing DHCP for location configuration SHOULD use [RFC3118].
5. Determining an emergency call ED-41 S/MIME MUST NOT be used to protect the Geolocation header or
bodies.
An emergency call is distinguished by the device (or a downstream ED-42/SP-22 TLS MUST be used to protect location (but see Section 9).
element) by an "address", which in most cases for Internet connected
devices is still a dialstring, although other user interfaces may be
used.
Note: It is undesirable to have a single "button" emergency call user 7. Uninitialized devices
interface element. These mechanisms have a very high false call
rate. PSAPs prefer devices to use their local emergency call
dialstring.
While in some countries there is a single 3 digit dialstring that is ED-43 Uninitialized devices SHOULD NOT lead a user to believe an
used for all emergency calls (i.e. 911 in North America), in some emergency call could be placed on it unless local regulations require
countries there are several 3 digit numbers used for different types it.
of calls. For example, in Switzerland, 117 is used to call police,
118 is used to call the fire brigade, and 144 is used for emergency
medical assistance. In other countries, there are no "short codes"
or "service codes" for 3 digit dialing of emergency services and
local (PSTN) numbers are used.
[I-D.ietf-ecrit-service-urn] introduces a universal emergency service ED-44/AN-25/SP-23 Uninitialized devices SHOULD NOT be capable of
URN scheme. On the wire, emergency calls SHOULD include this type of placing an emergency call unless local regulations require it.
URI as a Route header [RFC3261]. The scheme includes a single
emergency URN (urn:service:sos) and responder specific ones
(urn:service:sos.police). Using the service:sos URN scheme,
emergency calls can be recognized as such throughout the Internet.
Devices MUST use the service:sos URN scheme to mark emergency calls. ED-45/AN-26/SP-24 Uninitialized devices that can place emergency
calls MUST supply location the same as a fully capable device would.
To determine which calls are emergency calls, some entity needs to ED-46/SP-25 Unitialized Devices MUST supply a call back URI. See
map a user entered dialstring into this URN scheme. A user may Section 7.
"dial" 1-1-2, but the call would be sent to urn:service:sos. This
mapping is SHOULD performed at the endpoint device, but MAY be
performed at an intermediate entity (such as a SIP proxy server).
Note: It is strongly RECOMMENDED that devices recognize the emergency ED-47/SP-26 Unitialized Devices MUST include identifiers in the
dialstring(s) and map to the universal emergency URN. If devices signaling that can be used by the service provider to identify the
cannot do "dial plan interpretation", then the first signaling aware device and to allow filtering of calls from the device by the PSAP/
element (first hop proxy in SIP signaled devices) SHOULD do the ESRP.
mapping. It is important to not require a large number of active
elements handle a call before it is recognized as an emergency call
In systems that support roaming, there may be a concept of "visited" 8. Routing the call to the PSAP
and "home" networks. Even when there is not a "visited network", the
user may be roaming (or nomadic) in a different country from their
home. This gives rise to the problem of which dialstring(s) to
recognize, the "home" or "visited"? While the "home" dialstrings
SHOULD be recognized, it is required (by law in some countries) that
the "visited" dialstrings MUST be recognized. "Visited" dialstrings
would be essential if a guest used a roaming phone. Dial plan
interpretation may need to take "visited" emergency dialstrings into
account.
To give an example of this difference in dialstrings: If the device ED-48 Endpoints who obtain their own location SHOULD perform LoST
is from North America, the home and visited emergency dialstring is mapping to the PSAP URI.
"9-1-1". If that devices roams to the UK, the home emergency
dialstring is still "9-1-1", but the visited emergency dialstring
would become "9-9-9". If the device roams to Paris, the home
dialstring remains the same, "9-1-1", but the visited dialstring
changes from 999 to "1-1-2".
The home emergency dialstrings MAY be provisioned into the device (or ED-49 Mapping SHOULD be performed at boot time and whenever location
other element doing dialstring to universal emergency call URN changes beyond the service boundary obtained from a prior LoST
mapping). [I-D.ietf-ecrit-lost]) provides dialstrings for a given mapping operation or the time-to-live value of that response has
location and SHOULD be used by devices to learn the local (i.e. expired. The value MUST be cached for possible use.
"visited" dialstrings. "Home" dialstrings MAY be learned by
configuration.
6. Session Signaling ED-50 The endpoint SHOULD attempt to update its location at the time
of an emergency call. If it cannot obtain a new location quickly
(See Section 6), it MUST use the cached value.
SIP signaling [RFC3261] is expected be supported by upgraded PSAPs. ED-51 The endpoint SHOULD attempt to update the LoST mapping at the
Gateways MAY be used between Internet connected devices and older time of an emergency call. If it cannot obtain a new mapping
PSAPs. Some countries may support other signaling protocols into quickly, it MUST use the cached value.
PSAPs.
6.1. SIP signaling requirements for User Agents 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.
The initial SIP signaling Method is an INVITE. SP-28 To deal with old user agents that predate this specification
1. The Request URI SHOULD be a PSAP URI obtained from LoST (see and with UAs that do not have access to their own location data,
Section 6.3). If the device cannot access a LoST server, the proxies that recognize a call as an emergency call that is not marked
To: SHOULD be a service URN in the "sos" tree. If the device as such (see Section 5) MUST also perform this mapping, with the best
cannot do local dialstring interpretation, the Request-URI location it has available for the endpoint. The resulting PSAP URI
SHOULD be a dialstring URI [I-D.rosen-iptel-dialstring]with the would become the Request URI.
dialed digits. A sips URI [RFC3261] MUST be specified, unless
the operation must be retried due to a failure to establish a SP-29 Proxy servers performing mapping SHOULD use location obtained
TLS connection. from the access network for the mapping. If no location is
available, a default location (see Section 6.11) MUST be supplied.
SP-30 A proxy server which attempts mapping and fails to get a
mapping MUST provide a default mapping. A suitable default mapping
would be the mapping obtained previously for the default location
appropriate for the caller.
ED-52/SP-31 [RFC3261] and [RFC3263] procedures MUST be used to route
an emergency call towards the PSAP's URI.
ED-53 Initial INVITES MUST provide an Offer [RFC3264].
9. Signaling of emergency calls
ED-54 Best Current Practice for SIP user agents including handling of
audio, video and real-time text [RFC4103] SHOULD be applied. This
memo can be considered as an addition to it for endpoints.
9.1. Use of TLS
ED-55/SP-32 sips: MUST be specified when attempting to signal an
emergency call with SIP.
ED-56/SP-33 If TLS session establishment fails, the call MUST be
retried with sip:.
ED-57/SP-34 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain
persistent TLS connections between elements.
ED-58/AN-27 https: MUST be specified when attempting to retrieve
location (configuration or dereferencing) with HELD.
ED-59/AN33 If TLS session establishment fails, the location
retrieveal MUST be retried with http:.
9.2. SIP signaling requirements for User Agents
ED-60 The initial SIP signaling Method is an INVITE:
1. The Request URI SHOULD be the service URN in the "sos" tree, If
the device cannot do local dial string interpretation, the
Request-URI SHOULD be a dialstring URI [RFC4967] with the dialed
digits.
2. The To: header MUST be present and SHOULD be a service URN in 2. The To: header MUST be present and SHOULD be a service URN in
the "sos" tree. If the device cannot do local dialstring the "sos" tree. If the device cannot do local dialstring
interpretation, the To: SHOULD be a dialstring URI with the interpretation, the To: SHOULD be a dialstring URI with the
dialed digits. sips MUST be specified, unless the operation must dialed digits.
be retried due to a failure to establish a TLS connection.
3. The From: header MUST be present and SHOULD be the AoR of the 3. The From: header MUST be present and SHOULD be the AoR of the
caller. caller.
NOTE: unintialized devices may not have an AoR available
4. A Via: header MUST be present and SHOULD include the URI of the 4. A Via: header MUST be present and SHOULD include the URI of the
device device.
5. A Route header SHOULD be present with the service URN in the 5. A Route: header SHOULD be present with a PSAP URI obtained from
"sos" tree, and the loose route parameter. LoST (see Section 8) and the loose route parameter. A sips URI
6. Either a P-Asserted-Identity [RFC3325] or an Identity header [RFC3261] SHOULD be specified, unless the operation must be
[RFC4474], or both, SHOULD be included to identify the sender. retried due to a failure to establish a TLS connection. If the
7. A Contact header MUST be present (which might contain a GRUU device does not do dial plan interpretation, no Route: header
[I-D.ietf-sip-gruu]) to permit an immediate call-back to the will be present.
specific device which placed the emergency call. 6. A Contact header MUST be present which MUST be globally
8. Other headers MAY be included as per normal sip behavior routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an
9. A Supported: header MUST be included with the 'geolocation' immediate call-back to the specific device which placed the
emergency call.
7. Other headers MAY be included as per normal sip behavior.
8. A Supported: header MUST be included with the 'geolocation'
option tag [I-D.ietf-sip-location-conveyance], unless the device option tag [I-D.ietf-sip-location-conveyance], unless the device
does not understand the concept of SIP Location. does not understand the concept of SIP Location.
9. If a device understands the SIP Location Conveyance
10. If the device's location is by-reference, a Geolocation: header
[I-D.ietf-sip-location-conveyance] MUST be present containing
the URI of the PIDF-LO reference for that device. Whichever
location is used for routing the message towards the PSAP or
ESRP, even if there is only one, the Geolocation "message-
routed-on-this-uri" header parameter SHOULD be added to the
corresponding URI in the Geolocation header.
11. if a device understands the SIP Location Conveyance
[I-D.ietf-sip-location-conveyance] extension and has its [I-D.ietf-sip-location-conveyance] extension and has its
location available, it MUST include location either by-value or location available, it MUST include location either by-value or
by-reference. If it is by-value, the INVITE contains a by-reference.
Supported header with a "geolocation" option tag, and a "cid- 10. If a device understands the SIP Location Conveyance extension
URL" [RFC2396] as the value in the Geolocation header,
indicating which message body part contains the PIDF-LO. If the
INVITE contains a location by-reference, it includes the same
Supported header with the "geolocation" option tag, and includes
the URI of the PIDF-LO on a remote node in a Geolocation header.
[I-D.ietf-geopriv-pdif-lo-profile] MUST be used
12. If a device understands the SIP Location Conveyance extension
and has its location unavailable or unknown to that device, it and has its location unavailable or unknown to that device, it
MUST include a Supported header with a "geolocation" option tag, MUST include a Supported header with a "geolocation" option tag,
and not include a Geolocation header, and not include a PIDF-LO and MUST NOT include a Geolocation header, and not include a
message body. PIDF-LO message body.
13. A normal SDP offer SHOULD be included in the INVITE. The offer 11. If a device understands the SIP Location Conveyance extension
MUST include the G.711 codec, see Section 8. and supports LoST [I-D.ietf-ecrit-lost] then whichever location
14. If the device includes location-by-value, the UA MUST support is used for routing the message towards the PSAP or ESRP, even
if there is only one, the Geolocation "message-routed-on- this-
uri" header parameter SHOULD be added to the corresponding URI
in the Geolocation header.
12. A normal SDP offer SHOULD be included in the INVITE. The offer
MUST include the G.711 codec, see Section 14.
13. If the device includes location-by-value, the UA MUST support
multipart message bodies, since SDP will likely be also in the multipart message bodies, since SDP will likely be also in the
INVITE. INVITE.
15. A UAC SHOULD include the Geolocation "inserted-by=endpoint" 14. A UAC SHOULD include a "inserted-by=endpoint" header parameter
header parameter. This informs downstream elements which device on all Geolocation headers . This informs downstream elements
entered the location at this URI (either cid-URL or location-by- which device entered the location at this URI (either cid-URL or
reference URI). location-by-reference URI).
15. SIP Caller Preferences [RFC3841] MAY be used to signal how the
PSAP should handle the call. For example, a language preference
expressed in an Accept-Language header may be used as a hint to
cause the PSAP to route the call to a call taker who speaks the
requested language.
6.2. SIP signaling requirements for proxy servers and B2BUAs 9.3. SIP signaling requirements for proxy servers
SIP Proxy servers processing emergency calls: SP-35 SIP Proxy servers processing emergency calls:
1. If the proxy does dial plan interpretation on behalf of user 1. If the proxy does dial plan interpretation on behalf of user
agents, the proxy MUST look for the local emergency dialstring at agents, the proxy MUST look for the local emergency dialstring at
the location of the end device. If it finds it it MUST: the location of the end device and MAY look for the home
* Obtain the location (or a reference to it) for the endpoint dialstring. If it finds it, the proxy MUST:
* Insert a Geolocation header as per 10-12 above * Insert a Geolocation header as per 10-12 above. Location-by-
reference MUST be used because proxies may not insert bodies.
* Include the Geolocation "inserted-by=server" AND "routed-by- * Include the Geolocation "inserted-by=server" AND "routed-by-
this-uri" parameters. this-uri" parameters.
* Map the location to a PSAP uri using LoST. * Map the location to a PSAP uri using LoST.
* Add a Route header with the service URN appropriate for the * Add a Route header with the service URN appropriate for the
emergency dialstring. emergency dialstring.
* Replace the Request-URI (which was the dialstring) with the * Replace the Request-URI (which was the dialstring) with the
PSAP URI obtained from LoST. PSAP URI obtained from LoST.
* Route the call using normal SIP routing mechanisms. * Route the call using normal SIP routing mechanisms.
2. The "inserted-by=" header parameter MUST NOT be modified or 2. If the proxy recognizes the service URN in the Request URI, and
deleted in transit. does not find a Route header with a PSAP URI, it MUST run LoST
3. If a Geolocation "message-routed-on-this-uri" header parameter routing. If a location was provided (which should be the case),
exists when a new SIP server processes a message, and the message the proxy uses that location to query LoST. The proxy may have
is routing is now to be done based on another Geolocation URI to dereference a location by reference to get a value. If a
(by-value or by-reference), the "message-routed-on-this-uri" location is not present, and the proxy can query a LIS which has
header parameter MUST be removed from the old Geolocation URI and the location of the UA it MUST do so. If no location is present,
inserted with the now applicable location URI in the Geolocation and the proxy does not have access to a LIS which could provide
header. location, the proxy MUST supply a default location (See
Section 6.11). The location (in the signaling, obtained from a
6.3. Mapping from Location to a PSAP URI 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
To route an emergency call, we make use of the [I-D.ietf-ecrit-lost] a Route: header added to the call.
mapping service which takes a location expressed by a PIDF-LO and 3. The "inserted-by=" parameter in any Geolocation: header received
returns one or more PSAP URIs. The request includes the service URN on the call MUST NOT be modified or deleted in transit.
which is used to determine which entity should receive the call. 4. The proxy SHOULD NOT modify any parameters in Geolocation:
Ideally, mapping from location to the PSAP URI would be accomplished headers received in the call. It MAY add a Geolocation: header.
at the time the emergency call is placed. However, it could be that Such an additional location SHOULD NOT be used for routing; the
when the emergency occurs, the LoST server is unavailable to the location provided by the UA should be used.
caller, or busy. To guard against that, devices MUST cache a 5. Either a P-Asserted-Identity [RFC3325] or an Identity header
mapping. The mapping MUST be performed at boot time, and whenever [RFC4474], or both, MUST be included to identify the sender.
the location changes such that the previous mapping may no longer
valid. To facilitate this operation, LoST provides a mechanism that
a device can use to determine when it should refresh the mapping.
Devices where location changes SHOULD use this mechanism to maintain
a desired mapping.
User agents that can obtain location information MUST perform the
mapping from location information to PSAP URI using
[I-D.ietf-ecrit-lost]. The mapping is performed whenever the UA
acquires new location information that is outside the bounds of the
current PSAP coverage region specified in the LoST response or the
time-to-live value of that response has expired.
Determining when the device leaves the area provided by the LoST
service can tax small mobile devices. For this reason, the LoST
server SHOULD return a simple (small number of points) polygon for
geo reported location. This can be an enclosing subset of the area
when the reported point is not near an edge, or a smaller edge
section when the reported location is near an edge. Civic location
is uncommon for mobile devices, but reporting that the same mapping
is good within a community name, or even a street, may be very
helpful for WiFi connected devices that roam and obtain civic
location from the AP they are connected to.
All proxies in the outbound path SHOULD recognize emergency calls
with a Request URI of the service URN in the "sos" tree. A proxy
recognizing such a call (which indicates that the endpoint understood
the call was an emergency call, but was unable to map its location to
a PSAP URI) MUST perform the LoST mapping and retarget the call to
the PSAP URI (the service URN SHOULD remain as a Route header).
To deal with old user agents that predate this specification and with 10. Call backs
UAs that do not have access to their own location data, proxies that
recognize a call as an emergency call that is not marked as such (see
Section 5) or where the Request-URI is a service:sos URN MUST also
perform this mapping, with the best location it has available for the
endpoint. The resulting PSAP URI would become the Request URI.
6.4. Routing the call SP-36 Unitialized devices MUST have a globally routable URI in a
Contact: header.
Normal routing mechanisms for the specified URI should be used. For SP-37 Unitialized devices SHOULD have a persistent URI in a
SIP signaled devices, the domain of the URI should be extracted, and P-Asserted-Identity: header.
the DNS consulted for a sip (or sips) SRV. The resulting NAPTR, if
present, should be used for the FQDN of the server.
6.5. Responding to PSAP signaling 11. Mid-call behavior
The PSAP is expected to use normal signaling (e.g. SIP) as per IETF ED-61/SP-38 During the course of an emergency call, devices and
standards. Devices and proxies should expect to: proxies MUST support REFER transactions and the Referred-by: header
[RFC3515] to:
1. Be REFERed to a conference bridge; PSAPs often include 1. Be REFERed to a conference bridge; PSAPs often include
dispatchers, responders or specialists on a call. dispatchers, responders or specialists on a call.
2. Be REFERed to a secondary PSAP. Some responder's dispatchers are 2. Be REFERed to a secondary PSAP. Some responder's dispatchers are
not located in the primary PSAP. The call may have to be not located in the primary PSAP. The call may have to be
transferred to another PSAP. Most often this will be an attended transferred to another PSAP. Most often this will be an attended
transfer, or a bridged transfer. transfer, or a bridged transfer.(For devices that are Mobile).
3. (For devices that are Mobile) SUBSCRIBE to the Presence of the
AoR (or equivalent for other signaling schemes) to get location
updates.
4. Support Session Timer (or equivalent) to guard against session
corruption
Devices with an active emergency call (i.e. SIP Dialog) MUST NOT ED-62/SP-39User agents and proxies MUST Support Session
Timer[RFC4028] to guard against session corruption.
12. Call termination
ED-63 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT
generate a BYE request (or equivalent for other non-SIP signaling). 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 The PSAP must be the only entity that can terminate a call. If the
user "hangs up" an emergency call, the device should ring, and when user "hangs up" an emergency call, the device should alert, and when
answered, reconnect the caller to the PSAP. answered, reconnect the caller to the PSAP.
There can be a case where the session signaling path is lost, and the ED-64 There can be a case where the session signaling path is lost,
user agent does not receive the BYE. If the call is hung up, the and the user agent does not receive the BYE. If the call is hung up,
session timer expires, and 5 minutes elapses from the last message and the session timer expires the call MAY be declared lost. If in
received by the device from the PSAP, the call may be declared lost. the interval, an incoming call is received from the domain of the
If in the 5 minute interval an incoming call is received from the PSAP, the device SHOULD drop the old call and alert for the (new)
domain of the PSAP, the device should drop the old call and alert for incoming call. Dropping of the old call SHOULD only occur if the
the (new) incoming call. 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.
6.6. Disabling of features 13. Disabling of features
The calling device and/or service SHOULD disable outgoing call ED-65/SP-40 User Agents and proxys MUST disable outgoing call
features such as: features such as:
o Call Waiting o Call Waiting
o Call Transfer o Call Transfer
o Three Way Call o Three Way Call
o Flash hold o Flash hold
o Outbound Call Blocking o Outbound Call Blocking
when an emergency call is established.
The emergency dialstrings SHOULD NOT be permitted in Call Forward ED-66/SP-41 The emergency dialstrings SHOULD NOT be permitted in Call
numbers or speed dial lists. Forward numbers or speed dial lists.
The device and/or service SHOULD disable the following incoming call ED-67/SP-42 The User Agent and Proxies SHOULD disable the following
features on calls from the PSAP: incoming call features on call backs from the PSAP:
o Call Waiting (all kinds) o Call Waiting
o Do Not Disturb o Do Not Disturb
o Call Forward (all kinds) (if the PSAP calls back within some o Call Forward (all kinds)
(30min) interval)
7. Location Update 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.
Devices which are mobile may not be able to report an accurate 14. Media
location when an emergency call is placed. Some deployments of
location measurement are not always on, and when an emergency call is
initiated, the time to get an accurate "first fix" may be several
seconds. That is too long to wait to begin processing of the call.
In such cases, a fast fix, or the location of a tower serving a
wireless mobile device may be used to route the call, with accurate
location coming later on, after the call is answered. It is possible
that the PSAP that should handle the call once the accurate location
is available is different from the PSAP serving the tower or the
first fix location.
Mobile devices may be moving while an emergency call is in progress. ED-69 Endpoints MUST send and receive media streams on RTP [RFC3550].
The PSAPs, and/or the responders may change as the location changes.
For these reasons, and others, update of location is needed. ED-70 Normal SIP offer/answer [RFC3264] negotiations MUST be used to
Generally, updates should occur after the call is completed. The agree on the media streams to be used.
PSAP controls location update. For calls sent with location-by-
value, the PSAP MAY reINVITE the endpoint and the 200 OK from the
endpoint MUST include the location. For calls send with location-by-
reference, with a SIP or SIPS scheme, the server resolving the
reference MUST support a SUBSCRIBE [RFC3118] to the presence event
[RFC3856]. For other location-by-reference schemes, a repeated
location dereference by the PSAP MUST be supported.
8. Media ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law
in North America) encoded voice as described in [RFC3551]. It is
desirable to support wideband codecs in the offer.
Endpoints MUST send and receive media streams on RTP [RFC3550]. ED-72 Silence suppression (Voice Activity Detection methods) MUST NOT
Traditionally, voice has been the only media stream accepted by be used on emergency calls. PSAP call takers sometimes get
PSAPs. In some countries, text, in the form of BAUDOT codes or information on what is happening in the background to determine how
similar tone encoded signaling within a voiceband is accepted ("TTY") to process the call.
for persons who have hearing disabilities. With the Internet comes a
wider array of potential media which a PSAP should accept. Using SIP
signaling includes the capability to negotiate media. Normal SIP
offer/answer [RFC3264] negotiations MUST be used to agree on the
media streams to be used.
Endpoints supporting voice MUST support G.711 A law (and mu Law in ED-73 Endpoints supporting IM MUST support either [RFC3428] or
North America) encoded voice as described in [RFC3551]. It is [RFC3920].
desirable to support wideband codecs in the offer 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.
Newer text forms are rapidly appearing, with Instant Messaging now ED-74 Endpoints supporting real-time text MUST use [RFC4103]. The
very common, endpoints supporting IM MUST support either [RFC3428] or expectations for emergency service support for the real-time text
[RFC3920]. Endpoints supporting real-time text MUST use [RFC4103].
The expectations for emergency service support for the real-time text
medium, described in [I-D.ietf-sipping-toip], section 7.1 SHOULD be medium, described in [I-D.ietf-sipping-toip], section 7.1 SHOULD be
fulfilled. fulfilled.
Video may be important to support Video Relay Service (Sign language ED-75 Endpoints supporting video MUST support H.264 per [RFC3984].
interpretation) as well as modern video phones. Endpoints supporting
video MUST support H.264 per [RFC3984].
9. Testing
9.1. Testing Mechanism 15. Testing
INVITE requests to a service urn with a urn parameter of "test" ED-76 INVITE requests to a service urn with a urn parameter of "test"
indicates a request for an automated test. For example, indicates a request for an automated test. For example,
"urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response "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 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 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 is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP
does not support the test mechanism. does not support the test mechanism.
In its response to the test, the PSAP MAY include a text body ED-77 In its response to the test, the PSAP MAY include a text body
indicating the identity of the PSAP, the requested service, and the (text/plain) indicating the identity of the PSAP, the requested
location reported with the call. For the latter, the PSAP SHOULD service, and the location reported with the call. For the latter,
return location-by-value even if the original location delivered with the PSAP SHOULD return location-by-value even if the original
the test was by-reference. location delivered with the test was by-reference. If the location-
by-reference was supplied, and the dereference requires credentials,
the PSAP SHOULD use credentials supplied by the LIS for test
purposes. This alerts the LIS that the dereference is not for an
actual emergency call and location hiding techniques, if they are
being used, may be employed for this dereference. The response MAY
include the connected identity of the PSAP per
[I-D.ietf-sip-connected-identity].
A PSAP accepting a test call SHOULD accept a media loopback ED-78 A PSAP accepting a test call SHOULD accept a media loopback
test[I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-pkt- test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-
loopback" and "rtp-start-loopback" options. The user agent would pkt-loopback" and "rtp-start-loopback" options. The user agent would
specify a loopback attribute of "loopback-source", the PSAP being the specify a loopback attribute of "loopback-source", the PSAP being the
mirror. User Agents should expect the PSAP to loop back no more than mirror. User Agents should expect the PSAP to loop back no more than
3 packets of each media type accepted, after which the PSAP would 3 packets of each media type accepted (which limits the duration of
normally send BYE. the test), after which the PSAP would normally send BYE.
User agents SHOULD perform a full call test, including media ED-79 User agents SHOULD perform a full call test, including media
loopback, after a disconnect and subsequent change in IP address. loopback, after a disconnect and subsequent change in IP address.
After an initial IP address assignment test, a full test SHOULD be After an initial IP address assignment test, a full test SHOULD be
repeated approximately every 30 days with a random interval. repeated approximately every 30 days with a random interval.
User agents MUST NOT place a test call immediately after booting, as ED-80 User agents MUST NOT place a test call immediately after
a widespread power outage and subsequent restoration would impose an booting. If the IP address changes after booting, the UA should wait
inordinate load on the emergency call routing system. a random amount of time (in perhaps a 30 minute period, sufficient
for any avalanche restart to complete) and then test.
PSAPs MAY refuse repeated requests for test from the same device in a
short period of time.
10. Security Considerations
There are no new security considerations beyond those in the
normative references. This memo does not introduce any new
protocols; it specifies use of several of them.
10.1. Threats against endpoints
The largest threat against the endpoint is inadvertent disclosure of
its location. The endpoint acquires location from a Location
Configuration Protocol. Some of the protocols are very limited as to
the scope which messages within the protocol are distributed. DHCP
for example is limited to the local subnet. LLDP is limited to the
link. The [L7 LCP] is not limited and TLS SHOULD be used to protect
location privacy.
The location configuration server could be spoofed, thus providing
wrong location, and misdirecting help when an emergency call is
placed. When DHCP is the LCP [RFC3118] SHOULD be used to prevent
spoofing if possible. LLDP server spoofing would be limited to
devices connected to the link and is not seen as a credible threat.
Deployments should limit hubs and downstream switches to IP connected
devices that could be used to place emergency calls. [L7 LCP] SHOULD
use DIGEST authentication (or better) to identify the LIS.
The LoST server, which is the source of Location to PSAP URI mapping, ED-81 PSAPs MAY refuse repeated requests for test from the same
and local dialstrings, could be spoofed. Use of DHCP to obtain the device in a short period of time. Any refusal is signaled with a 486
location of the server limits the ability to misdirect the user. or 488 response.
LoST protocol use SHOULD include TLS with server certs to prevent
spoofing.
The PSAP could be spoofed. Client SHOULD use TLS with server certs 16. Security Considerations
to prevent spoofing.
10.2. Threats against the Emergency Service Security considerations for emergency calling have been documented in
draft-ietf-ecrit-security- threats, and the forthcoming GEOPRIV
security document(s).
The largest threats to the Emergency Service are forgery of location Ed. Note: go through that doc and make sure any actions needed are
and denial of service attacks on the PSAP and/or ESRP. captured in the BCP text.
To mitigate forgery of location, location object SHOULD be signed. 17. Acknowledgements
Since access networks and PSAPs are usually local to each other,
providing a PKI should not be onerous for many residential
deployments. However, enterprises may deploy access networks with
location, which is to be encouraged. PKI covering all enterprises
within a PSAP service area may be much more problematic.
To mitigate denial of service attacks, endpoint SHOULD use TLS (which Work group members participating in the creation and review of this
implies TCP) in the signaling towards the LoST server and the PSAP/ document include include Hannes Tschofenig, Ted Hardie, Marc Linsner,
ESRP. Return routability of signaling would help significantly. Use Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom,
of P-Asserted-Identity or SIP Identity is also REQUIRED of calling Roger Marshall, Barbara Stark, Richard Barnes and Peter Blatherwick.
networks.
11. Normative References 18. Normative References
[I-D.ietf-ecrit-framework] [I-D.ietf-ecrit-framework]
Rosen, B., "Framework for Emergency Calling in Internet Rosen, B., "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-00 (work in Multimedia", draft-ietf-ecrit-framework-02 (work in
progress), October 2006. progress), July 2007.
[I-D.ietf-ecrit-lost] [I-D.ietf-ecrit-lost]
Hardie, T., "LoST: A Location-to-Service Translation Hardie, T., "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-04 (work in progress), Protocol", draft-ietf-ecrit-lost-06 (work in progress),
February 2007. August 2007.
[I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress),
March 2007.
[I-D.ietf-ecrit-security-threats]
Taylor, T., "Security Threats and Requirements for
Emergency Call Marking and Mapping",
draft-ietf-ecrit-security-threats-05 (work in progress),
August 2007.
[I-D.ietf-ecrit-service-urn] [I-D.ietf-ecrit-service-urn]
Schulzrinne, H., "A Uniform Resource Name (URN) for Schulzrinne, H., "A Uniform Resource Name (URN) for
Services", draft-ietf-ecrit-service-urn-05 (work in Emergency and Other Well-Known Services",
progress), August 2006. draft-ietf-ecrit-service-urn-07 (work in progress),
August 2007.
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-01 (work in
progress), July 2007.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations", Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-05 (work in progress), draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),
October 2006. July 2007.
[I-D.ietf-geopriv-revised-civic-lo]
Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for PIDF-LO",
draft-ietf-geopriv-revised-civic-lo-05 (work in progress),
February 2007.
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Hedayat, K., "An Extension to the Session Description Hedayat, K., "An Extension to the Session Description
Protocol (SDP) for Media Loopback", Protocol (SDP) for Media Loopback",
draft-ietf-mmusic-media-loopback-05 (work in progress), draft-ietf-mmusic-media-loopback-06 (work in progress),
September 2006. April 2007.
[I-D.ietf-sip-connected-identity]
Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", draft-ietf-sip-connected-identity-05
(work in progress), February 2007.
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-11 (work in progress), (SIP)", draft-ietf-sip-gruu-14 (work in progress),
October 2006. June 2007.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Session Initiation Protocol Polk, J. and B. Rosen, "Location Conveyance for the
Location Conveyance", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-07 (work in progress), draft-ietf-sip-location-conveyance-08 (work in progress),
February 2007. July 2007.
[I-D.ietf-sipping-service-examples] [I-D.ietf-sip-outbound]
Johnston, A., "Session Initiation Protocol Service Jennings, C. and R. Mahy, "Managing Client Initiated
Examples", draft-ietf-sipping-service-examples-12 (work in Connections in the Session Initiation Protocol (SIP)",
progress), January 2007. draft-ietf-sip-outbound-10 (work in progress), July 2007.
[I-D.ietf-sipping-config-framework]
Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-12 (work in progress),
June 2007.
[I-D.ietf-sipping-toip] [I-D.ietf-sipping-toip]
Wijk, A. and G. Gybels, "Framework for real-time text over Wijk, A. and G. Gybels, "Framework for real-time text over
IP using the Session Initiation Protocol (SIP)", IP using the Session Initiation Protocol (SIP)",
draft-ietf-sipping-toip-07 (work in progress), draft-ietf-sipping-toip-07 (work in progress),
August 2006. August 2006.
[I-D.rosen-iptel-dialstring] [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Rosen, B., "Dialstring parameter for the Session Dec 2004.
Initiation Protocol Uniform Resource Identifier",
draft-rosen-iptel-dialstring-05 (work in progress),
March 2007.
[LLDP] IEEE, "IEEE 802.1AB-2005, Station and Media Access Control
Connectivity Discovery (aka Link Layer Discovery Protocol
- LLDP)", May 2004.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057, Link Layer Discovery Protocol for TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Media Endpoint Devices (aka LLDP-MED)", Apr 2006. Endpoint Discovery".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
skipping to change at page 18, line 26 skipping to change at page 20, line 23
RFC 3046, January 2001. RFC 3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004. Location Configuration Information", RFC 3825, July 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
M., and D. Singer, "RTP Payload Format for H.264 Video", M., and D. Singer, "RTP Payload Format for H.264 Video",
RFC 3984, February 2005. RFC 3984, February 2005.
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the
Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS) in Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005. IP Telephony", RFC 4190, November 2005.
skipping to change at page 19, line 34 skipping to change at page 21, line 48
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
Device Requirements and Configuration", RFC 4504, Device Requirements and Configuration", RFC 4504,
May 2006. May 2006.
[RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4676, October 2006. Configuration Information", RFC 4676, October 2006.
[RFC4967] Rosen, B., "Dial String Parameter for the Session
Initiation Protocol Uniform Resource Identifier",
RFC 4967, July 2007.
Appendix A. BCP Requirements Sorted by Responsible Party
A.1. Requirements of End Devices
ED-1 if a user could reasonably expect to be able to place a call for
help with the device, then the device or application SHOULD support
emergency calling.
ED-2 Devices that create media sessions and exchange audio, video
and/or text, and have the capability to establish sessions to a wide
variety of addresses, and communicate over private IP networks or the
Internet, SHOULD support emergency calls
ED-3 Endpoints SHOULD do dial string recognition of emergency dial
strings
ED-4 Emergency calls MUST be marked with a Service URN in the
Request-URI of the INVITE.
ED-5 Local dial strings MUST be recognized.
ED-6 Home dial strings MAY be recognized.
ED-7 Local emergency dial strings SHOULD be determined from LoST LoST
[I-D.ietf-ecrit-lost].
ED-8 Endpoints which do not recognize emergency dial strings SHOULD
send dial strings as per [RFC4967].
ED-9 Endpoints SHOULD be able to have home dial strings provisioned
by configuration.
ED-10 Devices SHOULD NOT have one button emergency calling
initiation.
ED-11 All emergency services specified in
[I-D.ietf-ecrit-service-urn] MUST be recognized. Devices/Service
Providers MUST be capable of recognizing all of the associated dial
strings.
ED-12 Endpoints and Service Providers MUST be prepared to handle
location represented in either civic or geo form.
ED-13 Elements MUST NOT convert (civic to geo or geo to civic) from
the form of location the determination mechanism supplied.
ED-14 Any suitable location determination mechanism MAY be used.
ED-15 Devices and/or access networks SHOULD support a manual method
to "override" the location the access network determines. Where a
civic form of location is provided, all fields in the PIDF- LO
[RFC4119] and [I-D.ietf-geopriv-revised-civic-lo] MUST be able to be
specified.
ED-16 devices MAY support end-system measured location. Uncertainty
of less than 100 m with 95% confidence SHOULD be available for
dispatch.
ED-17 Devices that support endpoint measuring of location MUST have
at least a coarse location (<1km) capability at all times for routing
of calls. This mechanism MAY be a service provided by the access
network.
ED-18 Endpoints SHOULD do location configuration themselves.
ED-20 Devices SHOULD be able to accept and forward location by value
or by reference. An end device that receives location by reference
(and does not also get the corresponding value) MUST be able to
perform a dereference operation to obtain a value.
ED-21 endpoints MUST support all of: DHCP Location options [RFC4676]
and [RFC3825], HELD[I-D.ietf-geopriv-http-location-delivery] and
LLDP-MED[LLDP-MED].
ED-22 Endpoints SHOULD try all LCPs supported by the device in any
order or in parallel. The first one that succeeds in supplying
location can be used.
ED-23 Endpoints SHOULD obtain location immediately after obtaining
local network configuration information.
ED-24 To minimize the effects of non-bypassable VPNs, location
configuration SHOULD be attempted before such tunnels are
established.
ED-25 Software which uses LCPs SHOULD locate and use the actual
hardware network interface.
ED-26 For devices which are not expected to roam, refreshing on the
order of once per day is RECOMMENDED
ED-27 For devices which roam, refresh of location SHOULD be more
frequent, with the frequency related to the mobility of the device
and the ability of the access network to support the refresh
operation. There can be instances in which a device is aware of when
it moves, for example when it changes access points. When this type
of event occurs, the device SHOULD refresh its location.
ED-28 It is RECOMMENDED that location determination not take longer
than 250 ms to obtain routing location and systems SHOULD be designed
such that the typical response is under 100ms. However, as much as 3
seconds to obtain routing location MAY be tolerated if location
accuracy can be substantially improved over what can be obtained in
250 ms.
ED-29 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sip-location-conveyance].
ED-30 Where the absolute location, or the accuracy of location of the
endpoint may change between the time the call is received at the PSAP
and the time dispatch is completed, location update mechanisms MUST
be provided.
ED-31 mobile devices MUST be provided with a mechanism to get
repeated location updates to track the motion of the device during
the complete processing of the call.
ED-32 The LIS SHOULD provide a location reference which permits a
subscription with appropriate filtering.
ED-33 For calls sent with location-by-reference, with a SIP or SIPS
scheme, the server resolving the reference MUST support a SUBSCRIBE
[RFC3118] to the presence event [RFC3856]. For other location-by-
reference schemes, a repeated location dereference by the PSAP MUST
be supported.
ED-34 If location was sent by value, and the endpoint gets updated
location, it MUST send the updated location to the PSAP via reINVITE
or UPDATE. Such updates SHOULD be limited to no more than one update
every 10 seconds.
ED-35 If a UA has more than one location available to it, it MUST
choose one location to use to route the call towards the PSAP.
ED-36/ Location objects MUST contain information about the method by
which the location was determined, such as GPS, manually entered, or
based on access network topology included in a PIDF- LO ?method?
element. In addition, the source of the location information MUST be
included in a PIDF-LO "provided-by" element.
ED-37 The "used-for-routing" parameter MUST be set to the location
that was used to query LoST.
ED-38 Endpoints SHOULD validate civic locations when they receive
them from their LCP. Validation SHOULD be performed in conjunction
with the LoST route query to minimize load on the LoST server.
ED-39 If the LCP does not return location in the form of a PIDF-LO
[RFC4119], the endpoint MUST map the location information it receives
from the configuration protocol to a PIDF-LO.
ED-40 To prevent against spoofing of the DHCP server, elements
implementing DHCP for location configuration SHOULD use [RFC3118].
ED-41 S/MIME MUST NOT be used to protect the Geolocation header or
bodies.
ED-42 TLS MUST be used to protect location (but see Section 9).
ED-43 Uninitialized devices SHOULD NOT lead a user to believe an
emergency call could be placed on it unless local regulations require
it.
ED-44 Uninitialized devices SHOULD NOT be capable of placing an
emergency call unless local regulations require it.
ED-45 Uninitialized devices that can place emergency calls MUST
supply location the same as a fully capable device would.
ED-46 Unitialized Devices MUST supply a call back URI. See Section 7
ED-47 Unitialized Devices MUST include identifiers in the signaling
that can be used by the service provider to identify the device and
to allow filtering of calls from the device by the PSAP/ESRP.
ED-48 Endpoints who obtain their own location SHOULD perform LoST
mapping to the PSAP URI.
ED-49 Mapping SHOULD be performed at boot time and whenever location
changes beyond the service boundary obtained from a prior LoST
mapping operation or the time-to-live value of that response has
expired. The value MUST be cached for possible use.
ED-50 The endpoint SHOULD attempt to update its location at the time
of an emergency call. If it cannot obtain a new location quickly
(See Section 6), it MUST use the cached value.
ED-51 The endpoint SHOULD attempt to update the LoST mapping at the
time of an emergency call. If it cannot obtain a new mapping
quickly, it MUST use the cached value.
ED-52 [RFC3261] and [RFC3263] procedures MUST be used to route an
emergency call towards the PSAP's URI.
ED-53 Initial INVITES MUST provide an Offer [RFC3264]
ED-54 Best Current Practice for SIP user agents including handling of
audio, video and real-time text [RFC4103] SHOULD be applied. This
memo can be considered as an addition to it for endpoints.
ED-55 sips: MUST be specified when attempting to signal an emergency
call with SIP
ED-56 If TLS session establishment fails, the call MUST be retried
with sip:
ED-57 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent
TLS connections between elements
ED-58 https: MUST be specified when attempting to retrieve location
(configuration or dereferencing) with HELD
ED-59 If TLS session establishment fails, the location retrieveal
MUST be retried with http:
ED-60 The initial SIP signaling Method is an INVITE:
1. The Request URI SHOULD be the service URN in the "sos" tree, If
the device cannot do local dialstring interpretation, the
Request-URI SHOULD be a dialstring URI [RFC4967] with the dialed
digits.
2. The To: header MUST be present and SHOULD be a service URN in
the "sos" tree. If the device cannot do local dialstring
interpretation, the To: SHOULD be a dialstring URI with the
dialed digits.
3. The From: header MUST be present and SHOULD be the AoR of the
caller.
4. A Via: header MUST be present and SHOULD include the URI of the
device.
5. A Route: header SHOULD be present with a PSAP URI obtained from
LoST (see Section 8 ) and the loose route parameter. A sips URI
[RFC3261] SHOULD be specified, unless the operation must be
retried due to a failure to establish a TLS connection. If the
device does not do dial plan interpretation, no Route: header
will be present.
6. A Contact header MUST be present which MUST be globally
routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an
immediate call-back to the specific device which placed the
emergency call.
7. Other headers MAY be included as per normal sip behavior.
8. A Supported: header MUST be included with the 'geolocation'
option tag [I-D.ietf-sip-location-conveyance], unless the device
does not understand the concept of SIP Location.
9. If a device understands the SIP Location Conveyance
[I-D.ietf-sip-location-conveyance] extension and has its
location available, it MUST include location either by- value or
by-reference.
10. If a device understands the SIP Location Conveyance extension
and has its location unavailable or unknown to that device, it
MUST include a Supported header with a "geolocation" option tag,
and MUST NOT include a Geolocation header, and not include a
PIDF-LO message body.
11. If a device understands the SIP Location Conveyance extension
and supports LoST [I-D.ietf-ecrit-lost] then whichever location
is used for routing the message towards the PSAP or ESRP, even
if there is only one, the Geolocation "message-routed-on- this-
uri" header parameter SHOULD be added to the corresponding URI
in the Geolocation header.
12. A normal SDP offer SHOULD be included in the INVITE. The offer
MUST include the G.711 codec, see Section 14.
13. If the device includes location-by-value, the UA MUST support
multipart message bodies, since SDP will likely be also in the
INVITE.
14. A UAC SHOULD include a "inserted-by=endpoint" header parameter
on all Geolocation headers . This informs downstream elements
which device entered the location at this URI (either cid-URL or
location-by-reference URI).
15. SIP Caller Preferences [RFC3841] MAY be used to signal how the
PSAP should handle the call. For example, a language preference
expressed in an Accept-Language header may be used as a hint to
cause the PSAP to route the call to a call taker who speaks the
requested language.
ED-61 During the course of an emergency call, devices and proxies
MUST support REFER transactions and the Referred-by: header [RFC3515]
to:
1. Be REFERed to a conference bridge; PSAPs often include
dispatchers, responders or specialists on a call.
2. Be REFERed to a secondary PSAP. Some responder's dispatchers are
not located in the primary PSAP. The call may have to be
transferred to another PSAP. Most often this will be an attended
transfer, or a bridged transfer.(For devices that are Mobile).
ED-62 User agents and proxies MUST Support Session Timer [RFC4028] to
guard against session corruption.
ED-63 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT
generate a BYE request (or equivalent for other non-SIP signaling).
The PSAP must be the only entity that can terminate a call. If the
user "hangs up" an emergency call, the device should alert, and when
answered, reconnect the caller to the PSAP.
ED-64 There can be a case where the session signaling path is lost,
and the user agent does not receive the BYE. If the call is hung up,
and the session timer expires the call MAY be declared lost. If in
the interval, an incoming call is received from the domain of the
PSAP, the device SHOULD drop the old call and alert for the (new)
incoming call. Dropping of the old call SHOULD only occur if the
user is attempting to hang up; the domain of an incoming call can
only be determined from the From header, which is not reliable, and
could be spoofed. Dropping an active call by a new call with a
spoofed From: would be a DoS attack.
ED-65 User Agents and proxys MUST disable outgoing call features such
as:
o Call Waiting
o Call Transfer
o Three Way Call
o Flash hold
o Outbound Call Blocking
when an emergency call is established.
ED-66 The emergency dialstrings SHOULD NOT be permitted in Call
Forward numbers or speed dial lists.
ED-67 The User Agent and Proxies SHOULD disable the following
incoming call features on call backs from the PSAP:
o Call Waiting
o Do Not Disturb
o Call Forward (all kinds)
ED-68 Call backs SHOULD be determined by retaining the domain of the
PSAP which answers an outgoing emergency call and instantiating a
timer which starts when the call is terminated. If a call is
received from the same domain and within the timer period, sent to
the Contact: or AoR used in the emergency call, it should be assumed
to be a call back. The suggested timer period is 5 minutes.
ED-69 Endpoints MUST send and receive media streams on RTP [RFC3550].
ED-70 Normal SIP offer/answer [RFC3264] negotiations MUST be used to
agree on the media streams to be used.
ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law
in North America) encoded voice as described in [RFC3551]. It is
desirable to support wideband codecs in the offer.
ED-72 Silence suppression (Voice Activity Detection methods) MUST NOT
be used on emergency calls. PSAP call takers sometimes get
information on what is happening in the background to determine how
to process the call.
ED-73 Endpoints supporting IM MUST support either [RFC3428] or
[RFC3920].
ED-74 Endpoints supporting real-time text MUST use [RFC4103]. The
expectations for emergency service support for the real-time text
medium, described in [I-D.ietf-sipping-toip], section 7.1 SHOULD be
fulfilled.
ED-75 Endpoints supporting video MUST support H.264 per [RFC3984].
ED-76 INVITE requests to a service urn with a urn parameter of "test"
indicates a request for an automated test. For example,
"urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response
indicates that the address was recognized and a 404 (Not found) that
it was not. A 486 (Busy Here) MUST be returned if the test service
is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP
does not support the test mechanism.
ED-77 In its response to the test, the PSAP MAY include a text body
(text/plain) indicating the identity of the PSAP, the requested
service, and the location reported with the call. For the latter,
the PSAP SHOULD return location-by-value even if the original
location delivered with the test was by-reference. If the location-
by-reference was supplied, and the dereference requires credentials,
the PSAP SHOULD use credentials supplied by the LIS for test
purposes. This alerts the LIS that the dereference is not for an
actual emergency call and location hiding techniques, if they are
being used, may be employed for this dereference. The response MAY
include the connected identity of the PSAP per
[I-D.ietf-sip-connected-identity].
ED-78 A PSAP accepting a test call SHOULD accept a media loopback
test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-
pkt-loopback" and "rtp-start-loopback" options. The user agent would
specify a loopback attribute of "loopback-source", the PSAP being the
mirror. User Agents should expect the PSAP to loop back no more than
3 packets of each media type accepted (which limits the duration of
the test), after which the PSAP would normally send BYE.
ED-79 User agents SHOULD perform a full call test, including media
loopback, after a disconnect and subsequent change in IP address.
After an initial IP address assignment test, a full test SHOULD be
repeated approximately every 30 days with a random interval.
ED-80 User agents MUST NOT place a test call immediately after
booting. If the IP address changes after booting, the UA should wait
a random amount of time (in perhaps a 30 minute period, sufficient
for any avalanche restart to complete) and then test.
ED-81 PSAPs MAY refuse repeated requests for test from the same
device in a short period of time. Any refusal is signaled with a 486
or 488 response.
A.2. Requirements of Service Providers
SP-1 If a device or application expects to be able to place a call
for help, the service that supports it SHOULD facilitate emergency
calling.
SP-2 Proxy servers SHOULD do dial string recognition of emergency
dial strings if for some reason the endpoint does not recognize them.
SP-3 Emergency calls MUST be marked with a Service URN in the
Request-URI of the INVITE.
SP-4 Local dial strings MUST be recognized.
SP-5 Home dial strings MAY be recognized.
SP-6 Local emergency dial strings SHOULD be determined from LoST LoST
[I-D.ietf-ecrit-lost].
SP-7 Proxy Servers MUST recognize emergency dial strings represented
by [RFC4967] and SHOULD recognize dial strings represented by a tel
URI [RFC3966].
SP-8 Service providers MAY provide home dial strings by configuration
[I-D.ietf-sipping-config-framework].
SP-9 All emergency services specified in [I-D.ietf-ecrit-service-urn]
MUST be recognized. Devices/Service Providers MUST be capable of
recognizing all of the associated dial strings.
SP-10 Endpoints and Service Providers MUST be prepared to handle
location represented in either civic or geo form.
SP-11 Elements MUST NOT convert (civic to geo or geo to civic) from
the form of location the determination mechanism supplied.
SP-12 Proxies MAY provide location on behalf of devices it supports
if:
o It has a relationship with all access networks the device could
connect to, and the relationship allows it to obtain location.
o It has an identifier that can be used by the access network to
determine the location of the endpoint, particularly in the
presence of NAT and VPN tunnels that may exist between the access
network and the service provider.
SP-13 Where proxies provide location on behalf of endpoints, the
proxy MUST provide a mechanism to supply emergency dia lstrings to
the device if the device recognizes them, or the proxy MUST track the
location of the device with sufficient accuracy and timeliness to be
able to recognize the local dial string at the time of an emergency
call.
SP-14 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sip-location-conveyance].
SP-15 If a proxy inserts location on behalf of an endpoint, and it
has multiple locations available for the endpoint it MUST choose one
location to use to route the call towards the PSAP.
SP-16 If a proxy is attempting to assert location but the UA conveyed
a location to it, the proxy must use the UA?s location for routing
and MUST convey that location towards the PSAP. It MAY also include
what it believes the location to be.
SP-17 All location objects received by a proxy MUST be delivered to
the PSAP.
SP-18 Location objects MUST contain information about the method by
which the location was determined, such as GPS, manually entered, or
based on access network topology included in a PIDF- LO ?method?
element. In addition, the source of the location information MUST be
included in a PIDF-LO "provided-by" element.
SP-19 The "used-for-routing" parameter MUST be set to the location
that was used to query LoST.
SP-20 Proxies handling emergency calls MUST insert a default location
if the call does not contain a location.
SP-21 Default locations MUST be marked with method=Default and an
appropriate provided-by in the PIDF-LO.
SP-22 TLS MUST be used to protect location (but see Section 9).
SP-23 Uninitialized devices SHOULD NOT be capable of placing an
emergency call unless local regulations require it.
SP-24 Uninitialized devices that can place emergency calls MUST
supply location the same as a fully capable device would.
SP-25 Unitialized Devices MUST supply a call back URI. See Section 7
SP-26 Unitialized Devices MUST include identifiers in the signaling
that can be used by the service provider to identify the device and
to allow filtering of calls from the device by the PSAP/ESRP.
SP-27 All proxies in the outbound path SHOULD recognize emergency
calls with a Request URI of the service URN in the "sos" tree. An
endpoint places a service URN in the Request URI to indicate that the
endpoint understood the call was an emergency call. A proxy that
processes such a call looks for the presence of a Route header with a
URI of a PSAP. Absence of such a Route header indicates the UAC was
unable to invoke LoST and the proxy MUST perform the LoST mapping and
insert a Route header with the URI obtained.
SP-28 To deal with old user agents that predate this specification
and with UAs that do not have access to their own location data,
proxies that recognize a call as an emergency call that is not marked
as such (see Section 5) MUST also perform this mapping, with the best
location it has available for the endpoint. The resulting PSAP URI
would become the Request URI.
SP-29 Proxy servers performing mapping SHOULD use location obtained
from the access network for the mapping. If no location is
available, a default location (see Section 6.11) MUST be supplied.
SP-30 A proxy server which attempts mapping and fails to get a
mapping MUST provide a default mapping. A suitable default mapping
would be the mapping obtained previously for the default location
appropriate for the caller.
SP-31 [RFC3261] and [RFC3263] procedures MUST be used to route an
emergency call towards the PSAP's URI.
SP-32 sips: MUST be specified when attempting to signal an emergency
call with SIP
SP-33 If TLS session establishment fails, the call MUST be retried
with sip:
SP-34 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent
TLS connections between elements
SP-35 SIP Proxy servers processing emergency calls:
1. If the proxy does dial plan interpretation on behalf of user
agents, the proxy MUST look for the local emergency dialstring at
the location of the end device and MAY look for the home
dialstring. If it finds it it MUST:
* Insert a Geolocation header as per 10-12 above. Location-by-
reference MUST be used because proxies may not insert bodies.
* Include the Geolocation "inserted-by=server" AND "routed-by-
this-uri" parameters.
* Map the location to a PSAP uri using LoST.
* Add a Route header with the service URN appropriate for the
emergency dialstring.
* Replace the Request-URI (which was the dialstring) with the
PSAP URI obtained from LoST.
* Route the call using normal SIP routing mechanisms.
2. If the proxy recognizes the service URN in the Request URI, and
does not find a Route header with a PSAP URI, it MUST run LoST
routing. If a location was provided (which should be the case),
the proxy uses that location to query LoST. The proxy may have
to dereference a location by reference to get a value. If a
location is not present, and the proxy can query a LIS which has
the location of the UA it MUST do so. If no location is present,
and the proxy does not have access to a LIS which could provide
location, the proxy MUST supply a default location (See
Section 6.11). The location (in the signaling, obtained from a
LIS, or default) MUST be used in a query to LoST with the service
URN received with the call. The resulting URI MUST be placed in
a Route: header added to the call.
3. The "inserted-by=" parameter in any Geolocation: header received
on the call MUST NOT be modified or deleted in transit.
4. The proxy SHOULD NOT modify any parameters in Geolocation:
headers received in the call. It MAY add a Geolocation: header.
Such an additional location SHOULD NOT be used for routing; the
location provided by the UA should be used.
5. Either a P-Asserted-Identity [RFC3325] or an Identity header
[RFC4474], or both, MUST be included to identify the sender.
SP-36 Unitialized devices MUST have a globally routable URI in a
Contact: header
SP-37 Unitialized devices SHOULD have a persistent URI in a
P-Asserted-Identity: header
SP-38 During the course of an emergency call, devices and proxies
MUST support REFER transactions and the Referred-by: header [RFC3515]
to:
1. Be REFERed to a conference bridge; PSAPs often include
dispatchers, responders or specialists on a call.
2. Be REFERed to a secondary PSAP. Some responder's dispatchers are
not located in the primary PSAP. The call may have to be
transferred to another PSAP. Most often this will be an attended
transfer, or a bridged transfer.(For devices that are Mobile)
SP-39User agents and proxies MUST Support Session Timer [RFC4028] to
guard against session corruption.
SP-40 User Agents and proxys MUST disable outgoing call features such
as:
o Call Waiting
o Call Transfer
o Three Way Call
o Flash hold
o Outbound Call Blocking
when an emergency call is established.
SP-41 The emergency dialstrings SHOULD NOT be permitted in Call
Forward numbers or speed dial lists.
SP-42 The User Agent and Proxies SHOULD disable the following
incoming call features on call backs from the PSAP:
o Call Waiting
o Do Not Disturb
o Call Forward (all kinds)
A.3. Requirements of Access Networks
AN-1 Elements MUST NOT convert (civic to geo or geo to civic) from
the form of location the determination mechanism supplied.
AN-2 Any suitable location determination mechanism MAY be used.
AN-3 Devices and/or access networks SHOULD support a manual method to
"override" the location the access network determines. Where a civic
form of location is provided, all fields in the PIDF- LO [RFC4119]
and [I-D.ietf-geopriv-revised-civic-lo] MUST be able to be specified.
AN-4 Access networks supporting copper, fiber or other hard wired IP
packet service SHOULD support location configuration. If the network
does not support location configuration, it MUST require every device
that connects to the network to support end system measured location.
AN-5 Access networks providing wire database location information
SHOULD provide interior location data where possible. It is
RECOMMENDED that interior location be provided when spaces exceed
approximately 650 m2
AN-6 Access networks (including enterprise networks) which support
intermediate range wireless connections (typically 100m or less of
range) and which do not support a more accurate location
determination mechanism such as triangulation, MUST support location
configuration which reports the location of the access point as the
location of the clients of that access point.
AN-7 Devices that support endpoint measuring of location MUST have at
least a coarse location (<1km) capability at all times for routing of
calls. This mechanism MAY be a service provided by the access
network.
AN-8 Access networks MAY provide network measured location
determination. Wireless access network which do not support network
measured location MUST require all devices connected to the network
have end-system measured location. Uncertainty of less than 100 m
with 95% confidence SHOULD be available for dispatch.
AN-9 Access networks that provide network measured location MUST have
at least a coarse location (<1km) capability at all times for routing
of calls.
AN-10 Access networks with range of <10M MUST provide a location to
mobile devices connected to it. The location provided SHOULD be that
of the beacon location unless a more accurate mechanism is provided.
AN-11 The access network MUST support at least one of DHCP location
options, HELD or LLDP-MED.
AN-12 Where a router is employed between a LAN and WAN in a small
(less than approximately 650m2), the LAN MUST reflect the location
provided by the WAN to the LAN.
AN-13 Access networks that support more than one LCP MUST reply with
the same location information (within the limits of the data format
for the specific LCP) for all LCPs it supports.
AN-14 Network administrators MUST take care in assigning IP addresses
such that VPN address assignments can be distinguished from local
devices (by subnet choice, for example), and LISs should not attempt
to provide location to addresses that arrive via VPN connections.
AN-15 Placement of NAT devices should consider the effect of the NAT
on the LCP.
AN-16 It is RECOMMENDED that location determination not take longer
than 250 ms to obtain routing location and systems SHOULD be designed
such that the typical response is under 100ms. However, as much as 3
seconds to obtain routing location MAY be tolerated if location
accuracy can be substantially improved over what can be obtained in
250 ms.
AN-17 Where the absolute location, or the accuracy of location of the
endpoint may change between the time the call is received at the PSAP
and the time dispatch is completed, location update mechanisms MUST
be provided.
AN-18 mobile devices MUST be provided with a mechanism to get
repeated location updates to track the motion of the device during
the complete processing of the call.
AN-19 The LIS SHOULD provide a location reference which permits a
subscription with appropriate filtering.
AN-20 For calls sent with location-by-reference, with a SIP or SIPS
scheme, the server resolving the reference MUST support a SUBSCRIBE
[RFC3118] to the presence event [RFC3856]. For other location-by-
reference schemes, a repeated location dereference by the PSAP MUST
be supported.
AN-21 Location validation of civic locations via LoST SHOULD be
performed by the LIS before entering a location in its database.
AN-22 When the access network cannot determine the actual location of
the caller, it MUST supply a default location. The default SHOULD be
chosen to be as close to the probable location of the device as the
network can determine.
AN-23 Default locations MUST be marked with method=Default and an
appropriate provided-by in the PIDF-LO.
AN-24 To prevent against spoofing of the DHCP server, elements
implementing DHCP for location configuration SHOULD use [RFC3118].
AN-25 Uninitialized devices SHOULD NOT be capable of placing an
emergency call unless local regulations require it.
AN-26 Uninitialized devices that can place emergency calls MUST
supply location the same as a fully capable device would.
AN-27 https: MUST be specified when attempting to retrieve location
(configuration or dereferencing) with HELD
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar NeuStar
470 Conrad Dr. 470 Conrad Dr.
Mars, PA 16046 Mars, PA 16046
US US
Phone: +1 724 382 1051 Phone: +1 724 382 1051
Email: br@brianrosen.net Email: br@brianrosen.net
 End of changes. 121 change blocks. 
580 lines changed or deleted 1416 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/