draft-ietf-ecrit-phonebcp-14.txt   draft-ietf-ecrit-phonebcp-15.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: BCP J. Polk Intended status: BCP J. Polk
Expires: July 23, 2010 Cisco Systems Expires: January 14, 2011 Cisco Systems
January 19, 2010 July 13, 2010
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-14 draft-ietf-ecrit-phonebcp-15
Abstract Abstract
The IETF and other standards organization have efforts targeted at The IETF and other standards organization have efforts targeted at
standardizing various aspects of placing emergency calls on IP standardizing various aspects of placing emergency calls on IP
networks. This memo describes best current practice on how devices, networks. This memo describes best current practice on how devices,
networks and services should use such standards to make emergency networks and services should use such standards to make emergency
calls. calls.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on January 14, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of how emergency calls are placed . . . . . . . . . . 4 3. Overview of how emergency calls are placed . . . . . . . . . . 3
4. Which devices and services should support emergency calls . . 5 4. Which devices and services should support emergency calls . . 4
5. Identifying an emergency call . . . . . . . . . . . . . . . . 5 5. Identifying an emergency call . . . . . . . . . . . . . . . . 4
6. Location and its role in an emergency call . . . . . . . . . . 6 6. Location and its role in an emergency call . . . . . . . . . . 5
6.1. Types of location information . . . . . . . . . . . . . . 6 6.1. Types of location information . . . . . . . . . . . . . . 5
6.2. Location Determination . . . . . . . . . . . . . . . . . . 7 6.2. Location Determination . . . . . . . . . . . . . . . . . . 6
6.2.1. User-entered location information . . . . . . . . . . 7 6.2.1. User-entered location information . . . . . . . . . . 6
6.2.2. Access network "wire database" location information . 7 6.2.2. Access network "wire database" location information . 6
6.2.3. End-system measured location information . . . . . . . 7 6.2.3. End-system measured location information . . . . . . . 6
6.2.4. Network-measured location information . . . . . . . . 8 6.2.4. Network-measured location information . . . . . . . . 7
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 7
6.4. Location and references to location . . . . . . . . . . . 8 6.4. Location and references to location . . . . . . . . . . . 8
6.5. End system location configuration . . . . . . . . . . . . 9 6.5. End system location configuration . . . . . . . . . . . . 8
6.6. When location should be configured . . . . . . . . . . . . 10 6.6. When location should be configured . . . . . . . . . . . . 9
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 11 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 10
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 10
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11
6.10. Location validation . . . . . . . . . . . . . . . . . . . 12 6.10. Location validation . . . . . . . . . . . . . . . . . . . 11
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12
6.12. Other location considerations . . . . . . . . . . . . . . 13 6.12. Other location considerations . . . . . . . . . . . . . . 12
7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 12
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 13
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 14
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. SIP signaling requirements for User Agents . . . . . . . . 15 9.2. SIP signaling requirements for User Agents . . . . . . . . 14
9.3. SIP signaling requirements for proxy servers . . . . . . . 17 9.3. SIP signaling requirements for proxy servers . . . . . . . 16
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 17
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 17
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 17
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
16. Security Considerations . . . . . . . . . . . . . . . . . . . 21 16. Security Considerations . . . . . . . . . . . . . . . . . . . 20
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
19.1. Normative References . . . . . . . . . . . . . . . . . . . 21 19.1. Normative References . . . . . . . . . . . . . . . . . . . 20
19.2. Informative References . . . . . . . . . . . . . . . . . . 24 19.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. BCP Requirements Sorted by Responsible Party . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
A.1. Requirements of End Devices . . . . . . . . . . . . . . . 25
A.2. Requirements of Service Providers . . . . . . . . . . . . 35
A.3. Requirements of Access Network . . . . . . . . . . . . . . 39
A.4. Requirements of Intermediate Devices . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
1. Terminology 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], [RFC5012] and This document uses terms from [RFC3261], [RFC5012] and
[I-D.ietf-ecrit-framework]. [I-D.ietf-ecrit-framework].
2. Introduction 2. Introduction
This document describes how access networks, SIP user agents, proxy This document describes how access networks, Session Initiation
servers and PSAPs support emergency calling, as outlined in Protocol [RFC3261] user agents, proxy servers and PSAPs support
[I-D.ietf-ecrit-framework], which is designed to complement the emergency calling, as outlined in [I-D.ietf-ecrit-framework], which
present document in section headings, numbering and content. This is designed to complement the present document in section headings,
BCP succinctly describes the requirements of end devices and numbering and content. This BCP succinctly describes the
applications (requirements prefaced by "ED-"), access networks requirements of end devices and applications (requirements prefaced
(including enterprise access networks) (requirements prefaced by by "ED-"), access networks (including enterprise access networks)
"AN-", service providers (requirements prefaced by "SP-") and PSAPs (requirements prefaced by "AN-"), service providers (requirements
to achieve globally interoperable emergency calling on the Internet. prefaced by "SP-") and PSAPs to achieve globally interoperable
emergency calling on the Internet.
This document also defines requirements for "Intermediate" devices This document also defines requirements for "Intermediate" devices
which exist between end devices or applications and the access which exist between end devices or applications and the access
network. For example, a home router is an "Intermediate" device. network. For example, a home router is an "Intermediate" device.
Reporting location on an emergency call (see Section 6) may depend on Reporting location on an emergency call (see Section 6) may depend on
the ability of such intermediate devices to meet the requirements the ability of such intermediate devices to meet the requirements
prefaced by "INT-". prefaced by "INT-".
3. Overview of how emergency calls are placed 3. Overview of how emergency calls are placed
skipping to change at page 5, line 29 skipping to change at page 4, line 30
Internet, SHOULD support emergency calls. Some jurisdictions have Internet, SHOULD support emergency calls. Some jurisdictions have
regulations governing this. regulations governing this.
5. Identifying an emergency call 5. Identifying an emergency call
ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If
the service provider always knows the location of the device, then the service provider always knows the location of the device, then
the service provider could recognize them. the service provider could recognize them.
SP-2 Proxy servers SHOULD recognize emergency dial strings if for SP-2 Proxy servers SHOULD recognize emergency dial strings if for
some reason the endpoint does not recognize them. This cannot be some reason the endpoint does not recognize them.
relied upon by the device if the service provider cannot always
determine the location of the device.
ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the
Request-URI of the INVITE. Request-URI of the INVITE.
ED-5/SP-4 Local dial strings MUST be recognized. ED-5/SP-4 Local dial strings MUST be recognized.
ED-6/SP-5 Devices MUST be able to be configured with the home country ED-6/SP-5 Devices MUST be able to be configured with the home country
from which the home dial string(s) can be determined. from which the home dial string(s) can be determined.
ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST
skipping to change at page 6, line 13 skipping to change at page 5, line 15
[RFC4967] and SHOULD recognize emergency dial strings represented by [RFC4967] and SHOULD recognize emergency dial strings represented by
a tel URI [RFC3966]. a tel URI [RFC3966].
ED-9 Endpoints SHOULD be able to have home dial strings provisioned. ED-9 Endpoints SHOULD be able to have home dial strings provisioned.
SP-8 Service providers MAY provision home dial strings in devices. SP-8 Service providers MAY provision home dial strings in devices.
ED-10 Devices SHOULD NOT have one button emergency calling ED-10 Devices SHOULD NOT have one button emergency calling
initiation. initiation.
ED-11/SP-9 All emergency services specified in [RFC5031] MUST be ED-11/SP-9 All sub-services for the 'sos' service specified in
recognized. [RFC5031] MUST be recognized.
6. Location and its role in an emergency call 6. Location and its role in an emergency call
Handling location for emergency calling usually involves several Handling location for emergency calling usually involves several
steps to process and multiple elements are involved. In Internet steps to process and multiple elements are involved. In Internet
emergency calling, where the endpoint is located is "determined" emergency calling, where the endpoint is located is "determined"
using a variety of measurement or wiretracing methods. Endpoints may using a variety of measurement or wiretracing methods. Endpoints may
be "configured" with their own location by the access network. In be "configured" with their own location by the access network. In
some circumstances, a proxy server may insert location into the some circumstances, a proxy server may insert location into the
signaling on behalf of the endpoint. The location is "mapped" to the signaling on behalf of the endpoint. The location is "mapped" to the
skipping to change at page 7, line 7 skipping to change at page 6, line 7
ED-12/INT-1/SP-10 Endpoints, Intermediate Devices and Service ED-12/INT-1/SP-10 Endpoints, Intermediate Devices and Service
Providers MUST be prepared to handle location represented in either Providers MUST be prepared to handle location represented in either
civic or geo form. civic or geo form.
ED-13/INT-2/SP-11/AN-2 Elements MUST NOT convert (civic to geo or geo ED-13/INT-2/SP-11/AN-2 Elements MUST NOT convert (civic to geo or geo
to civic) from the form of location the determination mechanism to civic) from the form of location the determination mechanism
supplied. supplied.
6.2. Location Determination 6.2. Location Determination
ED-14/INT-3/AN-3 Any suitable location determination mechanism MAY be ED-14/INT-3/AN-3 Any location determination mechanism MAY be used,
used. provided the accuracy of the location meets local requirements.
6.2.1. User-entered location information 6.2.1. User-entered location information
ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access networks ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access networks
SHOULD support a manual method to "override" the location the access SHOULD support a manual method to override the location the access
network determines. Where a civic form of location is provided, all network determines. Where a civic form of location is provided, all
fields in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be fields in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be
specified. specified.
6.2.2. Access network "wire database" location information 6.2.2. Access network "wire database" location information
AN-5 Access networks supporting copper, fiber or other hard wired IP AN-5 Access networks supporting copper, fiber or other hard wired IP
packet service SHOULD support location configuration. If the network packet service SHOULD support location configuration. If the network
does not support location configuration, it MUST require every device does not support location configuration, it MUST require every device
that connects to the network to support end system measured location. that connects to the network to support end system measured location.
skipping to change at page 7, line 37 skipping to change at page 6, line 37
(building, floor, room, cubicle) where possible. It is RECOMMENDED (building, floor, room, cubicle) where possible. It is RECOMMENDED
that interior location be provided when spaces exceed approximately that interior location be provided when spaces exceed approximately
650 square meters. 650 square meters.
AN-7/INT-6 Access networks and intermediate devices (including AN-7/INT-6 Access networks and intermediate devices (including
enterprise networks) which support intermediate range wireless enterprise networks) which support intermediate range wireless
connections (typically 100m or less of range) and which do not connections (typically 100m or less of range) and which do not
support a more accurate location determination mechanism such as support a more accurate location determination mechanism such as
triangulation, MUST support location configuration where the location triangulation, MUST support location configuration where the location
of the access point is reflected as the location of the clients of of the access point is reflected as the location of the clients of
that access point. Where the access network provides location that access point.
configuration, intermediate devices MUST either be transparent to it,
or provide an interconnected client for the supported configuration AN-8/INT-7 Where the access network provides location configuration,
mechanism and a server for a configuration protocol supported by end intermediate devices MUST either be transparent to it, or provide an
devices downstream of the intermediate device interconnected client for the supported configuration mechanism and a
server for a configuration protocol supported by end devices
downstream of the intermediate device such that the location provided
by the access network is available to clients as if the intermediate
device was not in the path.
6.2.3. End-system measured location information 6.2.3. End-system measured location information
ED-16/INT-7 Devices MAY support end-system measured location. ED-16/INT-8 Devices MAY support end-system measured location.
Uncertainty of less than 100 m with 95% confidence SHOULD be Uncertainty of less than 100 m with 95% confidence SHOULD be
available for dispatch. available for dispatch.
ED-17/INT-8/AN-8 Devices that support endpoint measuring of location ED-17/INT-9/AN-9 Devices that support endpoint measuring of location
MUST have at least a coarse location capability (typically <1km MUST have at least a coarse location capability (typically <1km
accuracy when not location hiding) for routing of calls. The accuracy when not location hiding) for routing of calls. The
location mechanism MAY be a service provided by the access network. location mechanism MAY be a service provided by the access network.
6.2.4. Network-measured location information 6.2.4. Network-measured location information
AN-9 Access networks MAY provide network-measured location AN-10 Access networks MAY provide network-measured location
determination. Wireless access network which do not support network determination. Wireless access networks that do not supply network
measured location MUST require that all devices connected to the measured location MUST require that all devices connected to the
network have end-system measured location. Uncertainty of less than network have end-system measured location. Uncertainty and
100 m with 95% confidence SHOULD be available for dispatch. confidence may be specified by local regulation. Where not
specified, uncertainty of less than 100 m with 95% confidence is
recommended for dispatch location.
AN-10 Access networks that provide network measured location MUST AN-11 Access networks that provide network measured location MUST
have at least a coarse location (typically <1km when not location have at least a coarse location (typically <1km when not location
hiding) capability at all times for routing of calls. hiding) capability at all times for routing of calls.
AN-11 Access networks with range of <10 meters (e.g. personal area AN-12 Access networks with range of <10 meters (e.g. personal area
networks such as Bluetooth MUST provide a location to mobile devices networks such as Bluetooth MUST provide a location to mobile devices
connected to them. The location provided SHOULD be that of the connected to them. The location provided SHOULD be that of the
access point location unless a more accurate mechanism is provided. access point location unless a more accurate mechanism is provided.
6.3. Who adds location, endpoint or proxy 6.3. Who adds location, endpoint or proxy
ED-18/INT-9 Endpoints SHOULD attempt to configure their own location ED-18/INT-10 Endpoints SHOULD attempt to configure their own location
using the LCPs listed in ED-21. using the LCPs listed in ED-21.
SP-12 Proxies MAY provide location on behalf of devices if: SP-12 Proxies MAY provide location on behalf of devices if:
o The proxy has a relationship with all access networks the device o The proxy has a relationship with all access networks the device
could connect to, and the relationship allows it to obtain could connect to, and the relationship allows it to obtain
location. location.
o The proxy has an identifier, such as an IP address, that can be o The proxy has an identifier, such as an IP address, that can be
used by the access network to determine the location of the used by the access network to determine the location of the
endpoint, even in the presence of NAT and VPN tunnels that may endpoint, even in the presence of NAT and VPN tunnels that may
obscure the identifier between the access network and the service obscure the identifier between the access network and the service
provider. provider.
ED-19/INT-10/SP-13 Where proxies provide location on behalf of ED-19/INT-11/SP-13 Where proxies provide location on behalf of
endpoints, the service provider MUST ensure that either the end endpoints, the service provider MUST ensure that either the end
device is provided with the local dial strings for its current device is provided with the local dial strings for its current
location (where the end device recognizes dial strings), or the location (where the end device recognizes dial strings), or the
service provider proxy MUST detect the appropriate local dial strings service provider proxy MUST detect the appropriate local dial strings
at the time of the call. at the time of the call.
6.4. Location and references to location 6.4. Location and references to location
ED-20/INT-11 Devices SHOULD be able to accept and forward location by ED-20/INT-12 Devices SHOULD be able to accept and forward location by
value or by reference. An end device that receives location by value or by reference. An end device that receives location by
reference (and does not also get the corresponding value) MUST be reference (and does not also get the corresponding value) MUST be
able to perform a dereference operation to obtain a value. able to perform a dereference operation to obtain a value.
6.5. End system location configuration 6.5. End system location configuration
ED-21/INT-12 Devices MUST support both the DHCP location options ED-21/INT-13 Devices MUST support both the DHCP location options
[RFC4776], [RFC3825] and HELD [RFC4776], [RFC3825] and HELD
[I-D.ietf-geopriv-http-location-delivery]. When devices deploy a [I-D.ietf-geopriv-http-location-delivery]. When devices deploy a
specific access network interface in which that access network specific access network interface for which location configuration
supports location discovery such as LLDP-MED [LLDP-MED] or 802.11v, mechanisms such as LLDP-MED [LLDP-MED] or 802.11v are specified, the
the device SHOULD support the additional respective access network device SHOULD support the additional respective access network
specific location discovery mechanism. specific location configuration mechanism.
AN-12/INT-13 The access network MUST support either DHCP location AN-13/INT-14 The access network MUST support either DHCP location
options or HELD. The access network SHOULD support other location options or HELD. The access network SHOULD support other location
technologies that are specific to the type of access network. configuration technologies that are specific to the type of access
network. If the access network supports more than one location
configuration protocol, all such protocols MUST return the same
location, within the constraints of the protocols deployed.
AN-13/INT-14 Where a router is employed between a LAN and WAN in a AN-14/INT-15 Where a router is employed between a LAN and WAN in a
small (less than approximately 650 square meters) area, the router small (less than approximately 650 square meters) area, the router
MUST be transparent to the location provided by the WAN to the LAN. MUST be transparent to the location provided by the WAN to the LAN.
This may mean the router must obtain location as a client from the This may mean the router must obtain location as a client from the
WAN, and supply an LCP server to the LAN with the location it WAN, and supply an LCP server to the LAN with the location it
obtains. Where the area is larger, the LAN MUST have a location obtains. Where the area is larger, the LAN MUST have a location
configuration mechanism meeting this BCP. configuration mechanism satisfying the requirements of this document.
ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in ED-22/INT-16 Endpoints SHOULD try all LCPs supported by the device in
any order or in parallel. The first one that succeeds in supplying any order or in parallel. The first one that succeeds in supplying
location can be used. location MUST be used.
AN-14/INT-16 Access networks that support more than one LCP MUST AN-15/INT-17 Access networks that support more than one LCP MUST
reply with the same location information (within the limits of the reply with the same location information (within the limits of the
data format for the specific LCP) for all LCPs it supports. data format for the specific LCP) for all LCPs it supports.
ED-23/INT-17/SP-14 When HELD is the LCP, the request MUST specify a ED-23/INT-18/SP-14 When HELD is the LCP, the request MUST specify a
value of "emergencyRouting" for the "responseTime" parameter and use value of "emergencyRouting" for the "responseTime" parameter and use
the resulting location for routing. If a value for dispatch location the resulting location for routing. If a value for dispatch location
will be sent, another request with the "responseTime" parameter set will be sent, another request with the "responseTime" parameter set
to "emergencyDispatch" must be completed, with the result sent for to "emergencyDispatch" must be completed, with the result sent for
dispatch purposes. dispatch purposes.
ED-24 Where the operating system supporting application programs ED-24 Where the operating system supporting application programs
which need location for emergency calls does not allow access to which need location for emergency calls does not allow access to
Layer 2 and Layer 3 functions necessary for a client application to Layer 2 and Layer 3 functions necessary for a client application to
use DHCP location options and/or other location technologies that are use DHCP location options and/or other location technologies that are
specific to the type of access network, the operating system MUST specific to the type of access network, the operating system MUST
provide a published API conforming to ED-12 through ED-21 and ED-21 provide a published API conforming to ED-12 through ED-23 and ED-25
through ED-31. It is RECOMMENDED that all operating systems provide through ED-32. It is RECOMMENDED that all operating systems provide
such an API. such an API.
6.6. When location should be configured 6.6. When location should be configured
ED-25/INT-18 Endpoints SHOULD obtain location immediately after ED-25/INT-19 Endpoints SHOULD obtain location immediately after
obtaining local network configuration information. When HELD is the obtaining local network configuration information.
LCP the client MUST support a random back-off period (between 30
seconds and 300 seconds) for re-trying the HELD query, when no
response is received, and no other LCP provided location information.
ED-26/INT-19 If the device is configured to use DHCP for ED-26/INT-20 If the device is configured to use DHCP for
bootstrapping, it MUST include both options for location acquisition bootstrapping, it MUST include both options for location acquisition
(civic and geodetic), the option for LIS discovery, and the option (civic and geodetic), the option for LIS discovery, and the option
for LoST discovery as defined in [RFC4776], [RFC3825], for LoST discovery as defined in [RFC4776], [RFC3825],
[I-D.ietf-geopriv-lis-discovery] and [RFC5223]. [I-D.ietf-geopriv-lis-discovery] and [RFC5223].
ED-27/INT-20 If the device sends a DHCPINFORM message, it MUST ED-27/INT-21 If the device sends a DHCPINFORM message, it MUST
include both options for location acquisition (civic and geodetic), include both options for location acquisition (civic and geodetic),
the option for LIS discovery, and the option for LoST discovery as the option for LIS discovery, and the option for LoST discovery as
defined in [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and defined in [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and
[RFC5223]. [RFC5223].
ED-28/INT-21 To minimize the effects of VPNs that do not allow ED-28/INT-22 To minimize the effects of VPNs that do not allow
packets to be sent via the native hardware interface rather than via packets to be sent via the native hardware interface rather than via
the VPN tunnel, location configuration SHOULD be attempted before the VPN tunnel, location configuration SHOULD be attempted before
such tunnels are established. such tunnels are established.
ED-29/INT-22 Software which uses LCPs SHOULD locate and use the ED-29/INT-23 Software which uses LCPs SHOULD locate and use the
actual hardware network interface rather than a VPN tunnel interface actual hardware network interface rather than a VPN tunnel interface
to direct LCP requests to the LIS in the actual access network. to direct LCP requests to the LIS in the actual access network.
AN-15 Network administrators MUST take care in assigning IP addresses AN-16 Network administrators MUST take care in assigning IP addresses
such that VPN address assignments can be distinguished from local such that VPN address assignments can be distinguished from local
devices (by subnet choice, for example), and LISs SHOULD NOT attempt devices (by subnet choice, for example), and LISs SHOULD NOT attempt
to provide location to addresses that arrive via VPN connections to provide location to addresses that arrive via VPN connections
unless it can accurately determine the location for such addresses. unless it can accurately determine the location for such addresses.
AN-16 Placement of NAT devices where an LCP uses IP address for an AN-17 Placement of NAT devices where an LCP uses IP address for an
identifier SHOULD consider the effect of the NAT on the LCP. The identifier SHOULD consider the effect of the NAT on the LCP. The
address used to query the LIS MUST be able to correctly identify the address used to query the LIS MUST be able to correctly identify the
record in the LIS representing the location of the querying device record in the LIS representing the location of the querying device
ED-30/INT-23 For devices which are not expected to roam, refreshing ED-30/INT-24 For devices which are not expected to change location,
location on the order of once per day is RECOMMENDED. refreshing location on the order of once per day is RECOMMENDED.
ED-31/INT-24 For devices which roam, refresh of location information ED-31/INT-25 For devices which roam, refresh of location information
SHOULD be more frequent, with the frequency related to the mobility SHOULD be more frequent, with the frequency related to the mobility
of the device and the ability of the access network to support the of the device and the ability of the access network to support the
refresh operation. If the device can detect that it has moved, for refresh operation. If the device detects a state change that might
example when it changes access points, the device SHOULD refresh its indicate having moved, for example when it changes access points, the
location. device SHOULD refresh its location.
ED-32/INT-25/AN-17 It is RECOMMENDED that location determination not ED-32/INT-26/AN-18 It is RECOMMENDED that location determination not
take longer than 250 ms to obtain routing location and systems SHOULD take longer than 250 ms to obtain routing location and systems SHOULD
be designed such that the typical response is under 100 ms. However, be designed such that the typical response is under 100 ms. However,
as much as 3 seconds to obtain routing location MAY be tolerated if as much as 3 seconds to obtain routing location MAY be tolerated if
location accuracy can be substantially improved over what can be location accuracy can be substantially improved over what can be
obtained in 250 ms. obtained in 250 ms.
6.7. Conveying location in SIP 6.7. Conveying location in SIP
ED-33/SP-15 Location sent between SIP elements MUST be conveyed using ED-33/SP-15 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sip-location-conveyance]. [I-D.ietf-sip-location-conveyance].
6.8. Location updates 6.8. Location updates
ED-34/AN-18 Where the absolute location or the accuracy of location ED-34/AN-19 Where the absolute location or the accuracy of location
of the endpoint may change between the time the call is received at of the endpoint may change between the time the call is received at
the PSAP and the time dispatch is completed, location update the PSAP and the time dispatch is completed, location update
mechanisms MUST be provided. mechanisms MUST be implemented and used.
ED-35/AN-19 Mobile devices MUST be provided with a mechanism to get ED-35/AN-20 Mobile devices MUST be provided with a mechanism to get
repeated location updates to track the motion of the device during repeated location updates to track the motion of the device during
the complete processing of the call. the complete processing of the call.
ED-36/AN-20 The LIS SHOULD provide a location reference which permits ED-36/AN-21 The LIS SHOULD provide a location reference which permits
a subscription with appropriate filtering. a subscription with appropriate filtering.
ED-37/AN-21 For calls sent with location-by-reference, with a SIP or ED-37/AN-22 For calls sent with location-by-reference, with a SIP or
SIPS scheme, the server resolving the reference MUST support a SIPS scheme, the server resolving the reference MUST support a
SUBSCRIBE [RFC3265] to the presence event [RFC3856]. For other SUBSCRIBE [RFC3265] to the presence event [RFC3856]. For other
location-by-reference schemes that do not support subscription, the location-by-reference schemes that do not support subscription, the
PSAP will have to repeatedly dereference the URI to determine if the PSAP will have to repeatedly dereference the URI to determine if the
device moved. device moved.
ED-38 If location was sent by value, and the endpoint gets updated ED-38 If location was sent by value, and the endpoint gets updated
location, it MUST send the updated location to the PSAP via a SIP re- location, it MUST send the updated location to the PSAP via a SIP re-
INVITE or UPDATE request. Such updates SHOULD be limited to no more INVITE or UPDATE request. Such updates SHOULD be limited to no more
than one update every 10 seconds. than one update every 10 seconds, a value selected to keep the load
on a large PSAP manageable, and yet provide sufficient indication to
the PSAP of motion.
6.9. Multiple locations 6.9. Multiple locations
ED-39/SP-16 If the LIS has more than one location for an endpoint it ED-39/SP-16 If the LIS has more than one location for an endpoint it
MUST use the procedures in [RFC5491] MUST conform to the rules in Section 3 of [RFC5491]
ED-40 If a UA has more than one location available to it, it MUST ED-40 If a UA has more than one location available to it, it MUST
choose one location to route the call towards the PSAP. If multiple choose one location to route the call towards the PSAP. If multiple
locations are in a single PIDF, the procedures in [RFC5491] MUST be locations are in a single PIDF, the procedures in [RFC5491] MUST be
followed. If the UA has multiple PIDFs, and has no reasonable basis followed. If the UA has multiple PIDFs, and has no reasonable basis
to choose from among them, a random choice is acceptable. to choose from among them, a random choice is acceptable.
SP-17 If a proxy inserts location on behalf of an endpoint, and it SP-17 If a proxy inserts location on behalf of an endpoint, and it
has multiple locations available for the endpoint it MUST choose one has multiple locations available for the endpoint it MUST choose one
location to use to route the call towards the PSAP. location to use to route the call towards the PSAP. If multiple
locations are in a single PIDF, the procedures in [RFC5491] MUST be
followed. If the proxy has multiple PIDFs, and has no reasonable
basis to choose from among them, a random choice is acceptable.
SP-18 If a proxy is attempting to insert location but the UA conveyed SP-18 If a proxy is attempting to insert location but the UA conveyed
a location to it, the proxy MUST use the UA's location for routing 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 and MUST convey that location towards the PSAP. It MAY also include
what it believes the location to be in a separate Geolocation header. what it believes the location to be in a separate Geolocation header.
SP-19 All location objects received by a proxy MUST be delivered to SP-19 All location objects received by a proxy MUST be delivered to
the PSAP. the PSAP.
ED-41/SP-20 Location objects MUST contain information about the ED-41/SP-20 Location objects MUST be created with information about
method by which the location was determined, such as GPS, manually the method by which the location was determined, such as GPS,
entered, or based on access network topology included in a PIDF- LO manually entered, or based on access network topology included in a
"method" element. In addition, the source of the location PIDF- LO "method" element. In addition, the source of the location
information MUST be included in a PIDF-LO "provided-by" element. information MUST be included in a PIDF-LO "provided-by" element.
ED-??/SP-?? A location with a method of "derived" MUST NOT be used ED-42/SP-21 A location with a method of "derived" MUST NOT be used
unless no other location is available. unless no other location is available.
ED-42/SP-21 The "used-for-routing" parameter MUST be set to the ED-43/SP-22 When there are multiple Geolocation header field values
provided, the "used-for-routing" parameter MUST be set to the
location that was chosen for routing. location that was chosen for routing.
6.10. Location validation 6.10. Location validation
AN-22 A LIS should perform location validation of civic locations via AN-23 A LIS should perform location validation of civic locations via
LoST before entering a location in its database. LoST before entering a location in its database.
ED-43 Endpoints SHOULD validate civic locations when they receive ED-44 Endpoints SHOULD validate civic locations when they receive
them from their LCP. Validation SHOULD be performed in conjunction them from their LCP. Validation SHOULD be performed in conjunction
with the LoST route query to minimize load on the LoST server. with the LoST route query to minimize load on the LoST server.
6.11. Default location 6.11. Default location
AN-23 When the access network cannot determine the actual location of AN-24 When the access network cannot determine the actual location of
the caller, it MUST supply a default location. The default SHOULD be 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 chosen to be as close to the probable location of the device as the
network can determine. See [I-D.ietf-ecrit-framework] network can determine. See [I-D.ietf-ecrit-framework]
SP-22 Proxies handling emergency calls MUST insert a default location SP-23 Proxies handling emergency calls MUST insert a default location
if the call does not contain a location and the proxy does not have a in the INVITE if the call does not contain a location and the proxy
method for obtaining a better location. does not have a method for obtaining a better location.
AN-24/SP-23 Default locations MUST be marked with method=Default and AN-25/SP-24 Default locations MUST be marked with method=Default and
the proxy MUST be identified in provided-by element of the PIDF-LO. the proxy MUST be identified in provided-by element of the PIDF-LO.
6.12. Other location considerations 6.12. Other location considerations
ED-44 If the LCP does not return location in the form of a PIDF-LO ED-45 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.
ED-45/AN-25 To prevent against spoofing of the DHCP server, elements ED-46/AN-26 To prevent against spoofing of the DHCP server, elements
implementing DHCP for location configuration SHOULD use [RFC3118] implementing DHCP for location configuration SHOULD use [RFC3118]
although the difficulty in providing appropriate credentials is although the difficulty in providing appropriate credentials is
significant. significant.
ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header ED-47 If S/MIME is used, the INVITE message MUST provide enough
or bodies. information unencrypted for intermediate proxies to route the call
based on the location information included. This would include the
Geolocation header, and any bodies containing location information.
Use of S/MIME with emergency calls is NOT RECOMMENDED.
ED-47/SP-24 TLS MUST be used to protect location (but see ED-48/SP-25 Either TLS or IPSEC [RFC3986] MUST be used to protect
Section 9.1). IPSEC [RFC3986] is an acceptable alternative. location (but see Section 9.1).
7. LIS and LoST Discovery 7. LIS and LoST Discovery
ED-48 Endpoints MUST support one or more mechanisms that allow them ED-49 Endpoints MUST support one or more mechanisms that allow them
to determine their public IP address. Examples include STUN to determine their public IP address, for example, STUN [RFC5389].
[RFC5389] and HTTP get.
ED-49 Endpoints MUST support LIS discovery as described in ED-50 Endpoints MUST support LIS discovery as described in
[I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described [I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described
in [RFC5223]. in [RFC5223].
ED-50 The device MUST have a configurable default LoST server ED-51 The device MUST have a configurable default LoST server
parameter. If the device is provided by or managed by a service parameter. If the device is provided by or managed by a service
provider, it is expected that the service provider will configure provider, it is expected that the service provider will configure
this option. this option.
ED-51 DHCP LoST discovery MUST be used, if available, in preference ED-52 DHCP LoST discovery MUST be used, if available, in preference
to configured LoST servers. If neither DHCP nor configuration leads to configured LoST servers. That is, the endpoint MUST send queries
to an available LoST server, the device MUST query DNS using it's SIP to this LoST server first, using other LoST servers only if these
domain for an SRV record for a LoST service and use that server. queries fail.
AN-26 Access networks which support DHCP MUST implement the LoST
discovery option
SP-25 Service Providers MUST provide an SRV entry in their DNS server
which leads to a LoST server
AN-27 Access Networks that use HELD and that have a DHCP server
SHOULD support DHCP options for providing LIS and LoST servers.
ED-52 When an endpoint has obtained a LoST server via an discovery AN-27 Access networks which support DHCP MUST implement the LIS and
mechanism (e.g., via the DNS or DHCP), it MUST prefer the discovered LoST discovery options in their DHCP servers and return suitable
LoST server over LoST servers configured by other means. That is, server addresses as appropriate.
the endpoint MUST send queries to this LoST server first, using other
LoST servers only if these queries fail.
8. Routing the call to the PSAP 8. Routing the call to the PSAP
ED-53 Endpoints who obtain their own location SHOULD perform LoST ED-53 Endpoints who obtain their own location SHOULD perform LoST
mapping to the PSAP URI. mapping to the PSAP URI.
ED-54 Mapping SHOULD be performed at boot time and whenever location ED-54 Mapping SHOULD be performed at boot time and whenever location
changes beyond the service boundary obtained from a prior LoST changes beyond the service boundary obtained from a prior LoST
mapping operation or the time-to-live value of that response has mapping operation or the time-to-live value of that response has
expired. The value MUST be cached for possible later use. expired. The value MUST be cached for possible later use.
skipping to change at page 15, line 13 skipping to change at page 14, line 17
available, a default location (see Section 6.11) MUST be supplied. available, a default location (see Section 6.11) MUST be supplied.
SP-29 A proxy server which attempts mapping and fails to get a SP-29 A proxy server which attempts mapping and fails to get a
mapping MUST provide a default mapping. A suitable default mapping mapping MUST provide a default mapping. A suitable default mapping
would be the mapping obtained previously for the default location would be the mapping obtained previously for the default location
appropriate for the caller. appropriate for the caller.
ED-57/SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route ED-57/SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route
an emergency call towards the PSAP's URI. an emergency call towards the PSAP's URI.
ED-58 Initial INVITES MAY provide an Offer [RFC3264].
9. Signaling of emergency calls 9. Signaling of emergency calls
ED-59 deleted
9.1. Use of TLS 9.1. Use of TLS
ED-60/SP-31 TLS MUST be specified when attempting to signal an ED-58/SP-31 Either TLS or IPsec MUST be used when attempting to
emergency call. IPSEC [RFC3986] is an acceptable alternative. signal an emergency call.
ED-61/SP-32 If TLS session establishment is not available, or fails, ED-59/SP-32 If TLS session establishment is not available, or fails,
the call MUST be retried without TLS. the call MUST be retried without TLS.
ED-62/SP-33 [RFC5626] is RECOMMENDED to maintain persistent TLS ED-60/SP-33 [RFC5626] is RECOMMENDED to maintain persistent TLS
connections between elements. connections between elements when one of the element is an endpoint.
Persistent TLS connection between proxies is RECOMMENDED using any
suitable mechanism.
ED-63/AN-28 TLS MUST be specified when attempting to retrieve ED-61/AN-28 TLS MUST be used when attempting to retrieve location
location (configuration or dereferencing) with HELD. The use of (configuration or dereferencing) with HELD. The use of [RFC5077] is
[RFC5077] is RECOMMENDED to minimize the time to establish TLS RECOMMENDED to minimize the time to establish TLS sessions without
sessions without keeping server-side state. keeping server-side state.
ED-64/AN-29 If TLS session establishment fails, the location ED-62/AN-29 When TLS session establishment fails, the location
retrieval MUST be retried without TLS. retrieval MUST be retried without TLS.
9.2. SIP signaling requirements for User Agents 9.2. SIP signaling requirements for User Agents
ED-65 The initial SIP signaling method is an INVITE request: ED-63 The initial SIP signaling method is an INVITE request:
1. The Request URI SHOULD be the service URN in the "sos" tree, If 1. The Request URI SHOULD be the service URN in the "sos" tree, If
the device cannot interpret local dial strings, the Request-URI the device cannot interpret local dial strings, the Request-URI
SHOULD be a dial string URI [RFC4967] with the dialed digits. SHOULD be a dial string URI [RFC4967] with the dialed digits.
2. The To header SHOULD be a service URN in the "sos" tree. If the 2. The To header field SHOULD be a service URN in the "sos" tree.
device cannot interpret local dial strings, the To: SHOULD be a If the device cannot interpret local dial strings, the To:
dial string URI with the dialed digits. SHOULD be a dial string URI with the dialed digits.
3. The From header MUST be present and SHOULD be the AoR of the 3. The From header field SHOULD contain the AoR of the caller.
caller.
4. A Via header MUST be present.
5. A Route header SHOULD be present with a PSAP URI obtained from 4. A Route header field SHOULD be present with a PSAP URI obtained
LoST (see Section 8) and the loose route parameter. If the from LoST (see Section 8). If the device does not interpret
device does not interpret dial plans, or was unable to obtain a dial plans, or was unable to obtain a route from a LoST server,
route from a LoST server, no Route header will be present. no such Route header field will be present.
6. A Contact header MUST be present which MUST be globally 5. A Contact header field MUST be globally routable, for example a
routable, for example a GRUU [RFC5627], and be valid for several GRUU [RFC5627], and be valid for several minutes following the
minutes following the termination of the call, provided that the termination of the call, provided that the UAC remains
UAC remains registered with the same registrar, to permit an registered with the same registrar, to permit an immediate call-
immediate call-back to the specific device which placed the back to the specific device which placed the emergency call. It
emergency call. It is acceptable if the UAC inserts a locally is acceptable if the UAC inserts a locally routable URI and a
routable URI and a subsequent B2BUA maps that to a globally subsequent B2BUA maps that to a globally routable URI.
routable URI. 6. Other header fields MAY be included as per normal SIP behavior.
7. Other headers MAY be included as per normal SIP behavior. 7. A Supported header field MUST be included with the 'geolocation'
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 8. 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, location available, it MUST include location either by-value,
by-reference or both. by-reference or both.
10. If a device understands the SIP Location Conveyance extension 9. 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 field with a "geolocation"
and MUST NOT include a Geolocation header, and not include a option tag, and MUST NOT include a Geolocation header field, and
PIDF-LO message body. not include a PIDF-LO message body.
11. If a device understands the SIP Location Conveyance extension 10. If a device understands the SIP Location Conveyance extension
and supports LoST [RFC5222], the Geolocation "used-for-routing" and supports LoST [RFC5222], the Geolocation "used-for-routing"
header parameter MUST be added to the corresponding URI in the header parameter MUST be added to the corresponding URI in the
Geolocation header. If the device is unable to obtain a PSAP Geolocation header field. If the device is unable to obtain a
URI for any reason it MUST NOT include "used-for-routing" on a PSAP URI for any reason it MUST NOT include "used-for-routing"
Geolocation URI, so that downstream entities know that LoST on a Geolocation URI, so that downstream entities know that LoST
routing has not been completed. routing has not been completed.
12. A SDP offer SHOULD be included in the INVITE. If voice is 11. A SDP offer SHOULD be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see supported the offer MUST include the G.711 codec, see
Section 14. As PSAPs may support a wide range of media types Section 14. As PSAPs may support a wide range of media types
and codecs, sending an offerless INVITE may result in a lengthy and codecs, sending an offerless INVITE may result in a lengthy
return offer, but is permitted. Cautions in [RFC3261] on return offer, but is permitted. Cautions in [RFC3261] on
offerless INVITEs should be considered before such use. offerless INVITEs should be considered before such use.
13. If the device includes location-by-value, the UA MUST support 12. 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.
14. A UAC SHOULD include a "inserted-by" header parameter with its 13. A UAC SHOULD include a "inserted-by" header parameter with its
own hostname on all Geolocation headers. This informs own hostname on all Geolocation header fields. This informs
downstream elements which device entered the location at this downstream elements which device entered the location at this
URI (either cid-URL or location-by-reference URI). 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. SIP Caller Preferences may also be used to
indicate a need to invoke a relay service for communication with
people with disabilities in the call.
9.3. SIP signaling requirements for proxy servers 9.3. SIP signaling requirements for proxy servers
SP-34 SIP Proxy servers processing emergency calls: SP-34 SIP Proxy servers processing emergency calls:
1. If the proxy interprets dial plans on behalf of user agents, the 1. If the proxy interprets dial plans on behalf of user agents, the
proxy MUST look for the local emergency dial string at the proxy MUST look for the local emergency dial string at the
location of the end device and MAY look for the home dial string. location of the end device and MAY look for the home dial string.
If it finds it, the proxy MUST: If it finds it, the proxy MUST:
* Insert a Geolocation header as above. Location-by-reference * Insert a Geolocation header field. Location-by-reference MUST
MUST be used because proxies must not insert bodies. be used because proxies must not insert bodies.
* Include the Geolocation "inserted-by" and "used-for-routing" * Include the Geolocation "inserted-by" and "used-for-routing"
parameters with its own hostname (which should match the Via parameters with its own hostname (which should match the Via
it inserts) on the inserted-by. it inserts) on the inserted-by.
* Map the location to a PSAP URI using LoST. * Map the location to a PSAP URI using LoST.
* Add a Route header with the PSAP URI. * Add a Route header with the PSAP URI.
* Replace the Request-URI (which was the dial string) with the * Replace the Request-URI (which was the dial string) with the
service URN appropriate for the emergency dial string. service URN appropriate for the emergency dial string.
* Route the call using normal SIP routing mechanisms. * Route the call using normal SIP routing mechanisms.
2. If the proxy recognizes the service URN in the Request URI, and 2. If the proxy recognizes the service URN in the Request URI, and
does not find a a Route header, it MUST query a LoST server. If does not find a a Route header, it MUST query a LoST server. If
skipping to change at page 17, line 42 skipping to change at page 16, line 38
reference to get a value. If a location is not present, and the 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 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 so. If no location is present, and the proxy does not have
access to a LIS which could provide location, the proxy MUST access to a LIS which could provide location, the proxy MUST
supply a default location (See Section 6.11). The location (in supply a default location (See Section 6.11). The location (in
the signaling, obtained from a LIS, or default) MUST be used in a 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 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. resulting URI MUST be placed in a Route header added to the call.
3. The "inserted-by" parameter in any Geolocation: header received 3. The "inserted-by" parameter in any Geolocation: header received
on the call MUST NOT be modified or deleted in transit. on the call MUST NOT be modified or deleted in transit.
4. The proxy SHOULD NOT modify any parameters in Geolocation headers 4. The proxy SHOULD NOT modify any parameters in Geolocation header
received in the call. It MAY add a Geolocation header. Such an fields received in the call. It MAY add a Geolocation header
additional location SHOULD NOT be used for routing; the location field. Such an additional location SHOULD NOT be used for
provided by the UA should be used. routing; the location provided by the UA should be used.
5. Either a P-Asserted-Identity [RFC3325] or an Identity header 5. Either a P-Asserted-Identity [RFC3325] or an Identity header
[RFC4474], or both, SHOULD be included to identify the sender. field [RFC4474], or both, SHOULD be included to identify the
For services which must support emergency calls from sender. For services which must support emergency calls from
unauthenticated devices, valid identity may not be available. unauthenticated devices, valid identity may not be available.
10. Call backs 10. Call backs
ED-66/SP-35 Devices device SHOULD have a globally routable URI in a ED-64/SP-35 Devices device SHOULD have a globally routable URI in a
Contact: header which remains valid for 30 minutes past the time the Contact: header field which remains valid for several minutes past
original call containing the URI completes unless the device the time the original call containing the URI completes unless the
registration expires and is not renewed. device registration expires and is not renewed.
SP-36 Call backs to the Contact: header URI recieved within 30 SP-36 Call backs to the Contact: header URI received within 30
minutes of an emergency call must reach the device regardless of call minutes of an emergency call must reach the device regardless of call
features or services that would normally cause the call to be routed features or services that would normally cause the call to be routed
to some other entity. to some other entity.
SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted-
Identity: header or From: protected by an Identity header suitable Identity header field or From protected by an Identity header field
for returning a call some time after the original call. Such a call suitable for returning a call some time after the original call.
back would not necessarily reach the device that originally placed Such a call back would not necessarily reach the device that
the call. originally placed the call.
11. Mid-call behavior 11. Mid-call behavior
ED-67/SP-38 During the course of an emergency call, devices and ED-65/SP-38 During the course of an emergency call, devices and
proxies MUST support REFER transactions with method=INVITE and the proxies MUST complete a call transfer upon receipt of REFER request
Referred-by: header [RFC3515] in that transaction. within the dialog with method=INVITE and the Referred-by: header
field [RFC3515] in that request.
12. Call termination 12. Call termination
ED-68 deleted ED-66 There can be a case where the session signaling path is lost,
ED-69 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 user agent does not receive the BYE. If the call is hung up,
and the session timer (if implemented) expires, the call MAY be and the session timer (if implemented) expires, the call MAY be
declared lost. If in the interval, an incoming call is received from declared lost. If in the interval, an incoming call is received from
the domain of the PSAP, the device MUST drop the old call and alert the domain of the PSAP, the device MUST drop the old call and alert
for the (new) incoming call. Dropping of the old call MUST only for the (new) incoming call. Dropping of the old call MUST only
occur if the user is attempting to hang up; the domain of an incoming 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 call can only be determined from the From header, which is not
reliable, and could be spoofed. Dropping an active call by a new reliable, and could be spoofed. Dropping an active call by a new
call with a spoofed From: would be a DoS attack. call with a spoofed From header field would be a DoS attack.
13. Disabling of features 13. Disabling of features
ED-70/SP-39 User Agents and proxies MUST disable features that will ED-67/SP-39 User Agents and proxies MUST disable features that will
interrupt an ongoing emergency call, such as: interrupt an ongoing emergency call, such as:
o Call Waiting o Call Waiting
o Call Transfer o Call Transfer
o Three Way Call o Three Way Call
o Hold o Hold
o Outbound Call Blocking o Outbound Call Blocking
when an emergency call is established. Also see ED-77 in Section 14. when an emergency call is established. Also see ED-74 in Section 14.
ED-71/SP-40 The emergency dial strings SHOULD NOT be permitted in ED-68/SP-40 The emergency dial strings SHOULD NOT be permitted in
Call Forward numbers or speed dial lists. Call Forward numbers or speed dial lists.
ED-72/SP-41 The User Agent and Proxies MUST disable call features ED-69/SP-41 The User Agent and Proxies MUST disable call features
which would interfere with the ability of call backs from the PSAP to which would interfere with the ability of call backs from the PSAP to
be completed such as: be completed such as:
o Do Not Disturb o Do Not Disturb
o Call Forward (all kinds) o Call Forward (all kinds)
ED-73 Call backs SHOULD be determined by retaining the domain of the ED-70 Call backs SHOULD be determined by retaining the domain of the
PSAP which answers an outgoing emergency call and instantiating a PSAP which answers an outgoing emergency call and instantiating a
timer which starts when the call is terminated. If a call is timer which starts when the call is terminated. If a call is
received from the same domain and within the timer period, sent to 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 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. to be a call back. The suggested timer period is 5 minutes.
[RFC4916] may be used by the PSAP to inform the UA of the domain of [RFC4916] may be used by the PSAP to inform the UA of the domain of
the PSAP. Recognizing a call back from the domain of the PSAP will the PSAP. Recognizing a call back from the domain of the PSAP will
not always work, and further standardization will be required to give not always work, and further standardization will be required to give
the UA the ability to recognize a call back. the UA the ability to recognize a call back.
14. Media 14. Media
ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550]. ED-71 Endpoints MUST send and receive media streams on RTP [RFC3550].
ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to ED-72 Normal SIP offer/answer [RFC3264] negotiations MUST be used to
agree on the media streams to be used. agree on the media streams to be used.
ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law ED-73 Endpoints supporting voice MUST support G.711 A law (and mu Law
if they are intended be used in North America) encoded voice as if they are intended be used in North America) encoded voice as
described in [RFC3551]. It is desirable to include wideband codecs described in [RFC3551]. It is desirable to include wideband codecs
such as AMR-WB in the offer. such as AMR-WB in the offer.
ED-77 Silence suppression (Voice Activity Detection methods) MUST NOT ED-74 Silence suppression (Voice Activity Detection methods) MUST NOT
be used on emergency calls. PSAP call takers sometimes get be used on emergency calls. PSAP call takers sometimes get
information on what is happening in the background to determine how information on what is happening in the background to determine how
to process the call. to process the call.
ED-78 Endpoints supporting Instant Messaging (IM) MUST support both ED-75 Endpoints supporting Instant Messaging (IM) MUST support both
[RFC3428] and [RFC4975]. [RFC3428] and [RFC4975].
ED-79 Endpoints supporting real-time text MUST use [RFC4103]. The ED-76 Endpoints supporting real-time text MUST use [RFC4103]. The
expectations for emergency service support for the real-time text expectations for emergency service support for the real-time text
medium, described in [RFC5194], Section 7.1 SHOULD be fulfilled. medium are described in [RFC5194], Section 7.1.
ED-80 Endpoints supporting video MUST support H.264 per [RFC3984]. ED-77 Endpoints supporting video MUST support H.264 per
[I-D.ietf-avt-rtp-rfc3984bis].
15. Testing 15. Testing
ED-81 INVITE requests to a service URN ending in ".test" indicates a ED-78 INVITE requests to a service URN ending in ".test" indicates a
request for an automated test. For example, 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 404 (Not found) MUST be returned if the PSAP does not is busy, and a 404 (Not found) MUST be returned if the PSAP does not
support the test mechanism. support the test mechanism.
ED-82 In its response to the test, the PSAP MAY include a text body ED-79 In its response to the test, the PSAP MAY include a text body
(text/plain) indicating the identity of the PSAP, the requested (text/plain) indicating the identity of the PSAP, the requested
service, and the location reported with the call. For the latter, service, and the location reported with the call. For the latter,
the PSAP SHOULD return location-by-value even if the original the PSAP SHOULD return location-by-value even if the original
location delivered with the test was by-reference. If the location- location delivered with the test was by-reference. If the location-
by-reference was supplied, and the dereference requires credentials, by-reference was supplied, and the dereference requires credentials,
the PSAP SHOULD use credentials supplied by the LIS for test the PSAP SHOULD use credentials supplied by the LIS for test
purposes. This alerts the LIS that the dereference is not for an purposes. This alerts the LIS that the dereference is not for an
actual emergency call and location hiding techniques, if they are actual emergency call and location hiding techniques, if they are
being used, may be employed for this dereference. Use of SIPS for being used, may be employed for this dereference. Use of SIPS for
the request would assure the response containing the location is kept the request would assure the response containing the location is kept
private private
ED-83 A PSAP accepting a test call SHOULD accept a media loopback ED-80 A PSAP accepting a test call SHOULD accept a media loopback
test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-
pkt-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 (which limits the duration of 3 packets of each media type accepted (which limits the duration of
the test), after which the PSAP would normally send BYE. the test), after which the PSAP would normally send BYE.
ED-84 User agents SHOULD perform a full call test, including media ED-81 User agents SHOULD perform a full call test, including media
loopback, after a disconnect and subsequent change in IP address not loopback, after a disconnect and subsequent change in IP address not
due to a reboot. After an initial test, a full test SHOULD be due to a reboot. After an initial test, a full test SHOULD be
repeated approximately every 30 days with a random interval. repeated approximately every 30 days with a random interval.
ED-85 User agents MUST NOT place a test call immediately after ED-82 User agents MUST NOT place a test call immediately after
booting. If the IP address changes after booting, the UA should wait booting. If the IP address changes after booting, the UA should wait
a random amount of time (in perhaps a 30 minute period, sufficient a random amount of time (in perhaps a 30 minute period, sufficient
for any avalanche restart to complete) and then test. for any avalanche restart to complete) and then test.
ED-86 PSAPs MAY refuse repeated requests for test from the same ED-83 PSAPs MAY refuse repeated requests for test from the same
device in a short period of time. Any refusal is signaled with a 486 device in a short period of time. Any refusal is signaled with a 486
or 488 response. or 488 response.
16. Security Considerations 16. Security Considerations
Security considerations for emergency calling have been documented in Security considerations for emergency calling have been documented in
[RFC5069], and [I-D.ietf-geopriv-arch]. [RFC5069], and [I-D.ietf-geopriv-arch].
17. IANA Considerations 17. IANA Considerations
skipping to change at page 21, line 29 skipping to change at page 20, line 25
Work group members participating in the creation and review of this Work group members participating in the creation and review of this
document include include Hannes Tschofenig, Ted Hardie, Marc Linsner, document include include Hannes Tschofenig, Ted Hardie, Marc Linsner,
Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom,
Barbara Stark, Richard Barnes and Peter Blatherwick. Barbara Stark, Richard Barnes and Peter Blatherwick.
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-avt-rtp-rfc3984bis]
Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video",
draft-ietf-avt-rtp-rfc3984bis-11 (work in progress),
June 2010.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009. progress), August 2009.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-13 (work in progress), draft-ietf-geopriv-lis-discovery-15 (work in progress),
December 2009. March 2010.
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Sivachelvan, C., Venna, N., Jones, P., Stratton, N., Sivachelvan, C., Venna, N., Jones, P., Stratton, N.,
Roychowdhury, A., and K. Hedayat, "An Extension to the Roychowdhury, A., and K. Hedayat, "An Extension to the
Session Description Protocol (SDP) for Media Loopback", Session Description Protocol (SDP) for Media Loopback",
draft-ietf-mmusic-media-loopback-11 (work in progress), draft-ietf-mmusic-media-loopback-13 (work in progress),
October 2009. April 2010.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009. March 2009.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
skipping to change at page 23, line 16 skipping to change at page 22, line 17
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. 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.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
M., and D. Singer, "RTP Payload Format for H.264 Video",
RFC 3984, February 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 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.
skipping to change at page 24, line 47 skipping to change at page 23, line 43
[I-D.ietf-ecrit-framework] [I-D.ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-10 (work in Multimedia", draft-ietf-ecrit-framework-10 (work in
progress), July 2009. progress), July 2009.
[I-D.ietf-geopriv-arch] [I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-01 (work in progress), draft-ietf-geopriv-arch-02 (work in progress), May 2010.
October 2009.
[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.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008. RFC 5012, January 2008.
skipping to change at page 25, line 23 skipping to change at page 24, line 18
January 2008. January 2008.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text
over IP Using the Session Initiation Protocol (SIP)", over IP Using the Session Initiation Protocol (SIP)",
RFC 5194, June 2008. RFC 5194, June 2008.
Appendix A. BCP Requirements Sorted by Responsible Party
A.1. Requirements of End Devices
ED-1 A device or application SHOULD support emergency calling if a
user could reasonably expect to be able to place a call for help with
the device. Some jurisdictions have regulations governing this.
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. Some jurisdictions have
regulations governing this.
ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If
the service provider always knows the location of the device, then
the service provider could recognize them.
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 Devices MUST be able to be configured with the home country from
which the home dial string(s) can be determined.
ED-7 Emergency dial strings SHOULD be determined from LoST [RFC5222].
Dial Strings MAY be configured directly in the device.
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 [RFC5031] MUST be
recognized.
ED-12 Endpoints, Intermediate Devices 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, intermediate Devices and/or access networks SHOULD
support a manual method to "override" the location the access network
determines. Where a civic form of location is provided, all fields
in the PIDF-LO [RFC4119] and [RFC5139] 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 capability (typically <1km accuracy when
not location hiding) for routing of calls. The location mechanism
MAY be a service provided by the access network.
ED-18 Endpoints SHOULD attempt to configure their own location using
the LCPs listed in ED-21.
ED-19 Where proxies provide location on behalf of endpoints, the
service provider MUST ensure that either the end device is provided
with the local dial strings for its current location (where the end
device recognizes dial strings), or the service provider proxy MUST
detect the appropriate local dial strings at the time of the call.
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 Devices MUST support both the DHCP location options [RFC4776],
[RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When
devices deploy a specific access network interface in which that
access network supports location discovery such as LLDP-MED or
802.11v, the device SHOULD support the additional respective access
network specific location discovery mechanism.
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 When HELD is the LCP, the request MUST specify a value of
"emergencyRouting" for the "responseTime" parameter and use the
resulting location for routing. If a value for dispatch location
will be sent, another request with the "responseTime" parameter set
to "emergencyDispatch" must be completed, with the result sent for
dispatch purposes.
ED-24 Where the operating system supporting application programs
which need location for emergency calls does not allow access to
Layer 2 and Layer 3 functions necessary for a client application to
use DHCP location options and/or other location technologies that are
specific to the type of access network, the operating system MUST
provide a published API conforming to ED-12 through ED-21 and ED-21
through ED-31. It is RECOMMENDED that all operating systems provide
such an API.
ED-25 Endpoints SHOULD obtain location immediately after obtaining
local network configuration information. When HELD is the LCP the
client MUST support a random back-off period (between 30 seconds and
300 seconds) for re-trying the HELD query, when no response is
received, and no other LCP provided location information.
ED-26 If the device is configured to use DHCP for bootstrapping, it
MUST include both options for location acquisition (civic and
geodetic), the option for LIS discovery, and the option for LoST
discovery as defined in [RFC4776], [RFC3825],
[I-D.ietf-geopriv-lis-discovery] and [RFC5223].
ED-27 If the device sends a DHCPINFORM message, it MUST include both
options for location acquisition (civic and geodetic), the option for
LIS discovery, and the option for LoST discovery as defined in
[RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and [RFC5223].
ED-28 To minimize the effects of VPNs that do not allow packets to be
sent via the native hardware interface rather than via the VPN
tunnel, location configuration SHOULD be attempted before such
tunnels are established.
ED-29 Software which uses LCPs SHOULD locate and use the actual
hardware network interface rather than a VPN tunnel interface to
direct LCP requests to the LIS in the actual access network.
ED-30 For devices which are not expected to roam, refreshing location
on the order of once per day is RECOMMENDED.
ED-31 For devices which roam, refresh of location information SHOULD
be more frequent, with the frequency related to the mobility of the
device and the ability of the access network to support the refresh
operation. If the device can detect that it has moved, for example
when it changes access points, the device SHOULD refresh its
location.
ED-32 It is RECOMMENDED that location determination not take longer
than 250 ms to obtain routing location and systems SHOULD be designed
such that the typical response is under 100 ms. However, as much as
3 seconds to obtain routing location MAY be tolerated if location
accuracy can be substantially improved over what can be obtained in
250 ms.
ED-33 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sip-location-conveyance].
ED-34 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-35 Mobile devices MUST be provided with a mechanism to get
repeated location updates to track the motion of the device during
the complete processing of the call.
ED-36 The LIS SHOULD provide a location reference which permits a
subscription with appropriate filtering.
ED-37 For calls sent with location-by-reference, with a SIP or SIPS
scheme, the server resolving the reference MUST support a SUBSCRIBE
[RFC3265] to the presence event [RFC3856]. For other location-by-
reference schemes that do not support subscription, the PSAP will
have to repeatedly dereference the URI to determine if the device
moved.
ED-38 If location was sent by value, and the endpoint gets updated
location, it MUST send the updated location to the PSAP via a SIP re-
INVITE or UPDATE request. Such updates SHOULD be limited to no more
than one update every 10 seconds.
ED-39 If the LIS has more than one location for an endpoint it MUST
use the procedures in [RFC5491]
ED-40 If a UA has more than one location available to it, it MUST
choose one location to route the call towards the PSAP. If multiple
locations are in a single PIDF, the procedures in [RFC5491] MUST be
followed. If the UA has multiple PIDFs, and has no reasonable basis
to choose from among them, a random choice is acceptable.
ED-41 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-42 The "used-for-routing" parameter MUST be set to the location
that was chosen for routing.
ED-43 Endpoints SHOULD validate civic locations when they receive
them from their LCP. Validation SHOULD be performed in conjunction
with the LoST route query to minimize load on the LoST server.
ED-44 If the LCP does not return location in the form of a PIDF-LO
[RFC4119], the endpoint MUST map the location information it receives
from the configuration protocol to a PIDF-LO.
ED-45 To prevent against spoofing of the DHCP server, elements
implementing DHCP for location configuration SHOULD use [RFC3118]
although the difficulty in providing appropriate credentials is
significant.
ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header
or bodies.
ED-47 TLS MUST be used to protect location (but see Section 9.1).
IPSEC [RFC3986] is an acceptable alternative.
ED-48 Endpoints MUST support one or more mechanisms that allow them
to determine their public IP address. Examples include STUN
[RFC5389] and HTTP get.
ED-49 Endpoints MUST support LIS discovery as described in
[I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described
in [RFC5223].
ED-50 The device MUST have a configurable default LoST server
parameter. If the device is provided by or managed by a service
provider, it is expected that the service provider will configure
this option.
ED-51 DHCP LoST discovery MUST be used, if available, in preference
to configured LoST servers. If neither DHCP nor configuration leads
to an available LoST server, the device MUST query DNS using it's SIP
domain for an SRV record for a LoST service and use that server.
ED-52 When an endpoint has obtained a LoST server via an discovery
mechanism (e.g., via the DNS or DHCP), it MUST prefer the discovered
LoST server over LoST servers configured by other means. That is,
the endpoint MUST send queries to this LoST server first, using other
LoST servers only if these queries fail.
ED-53 Endpoints who obtain their own location SHOULD perform LoST
mapping to the PSAP URI.
ED-54 Mapping SHOULD be performed at boot time and whenever location
changes beyond the service boundary obtained from a prior LoST
mapping operation or the time-to-live value of that response has
expired. The value MUST be cached for possible later use.
ED-55 The endpoint MUST attempt to update its location at the time of
an emergency call. If it cannot obtain a new location quickly (see
Section 6), it MUST use the cached value.
ED-56 The endpoint SHOULD attempt to update the LoST mapping at the
time of an emergency call. If it cannot obtain a new mapping
quickly, it MUST use the cached value. If the device cannot update
the LoST mapping and does not have a cached value, it MUST signal an
emergency call without a Route header containing a PSAP URI.
ED-57 [RFC3261] and [RFC3263] procedures MUST be used to route an
emergency call towards the PSAP's URI.
ED-58 Initial INVITES MAY provide an Offer [RFC3264].
ED-59 deleted
ED-60 TLS MUST be specified when attempting to signal an emergency
call with SIP. IPSEC [RFC3986] is an acceptable alternative.
ED-61 If TLS session establishment is not available, or fails, the
call MUST be retried without TLS.
ED-62 [RFC5626] is RECOMMENDED to maintain persistent TLS connections
between elements.
ED-63 TLS MUST be specified when attempting to retrieve location
(configuration or dereferencing) with HELD. The use of [RFC5077] is
RECOMMENDED to minimize the time to establish TLS sessions without
keeping server-side state.
ED-64 If TLS session establishment fails, the location retrieval MUST
be retried without TLS.
ED-65 The initial SIP signaling method is an INVITE request:
1. The Request URI SHOULD be the service URN in the "sos" tree, If
the device cannot interpret local dial strings, the Request-URI
SHOULD be a dial string URI [RFC4967] with the dialed digits.
2. The To header SHOULD be a service URN in the "sos" tree. If the
device cannot interpret local dial strings, the To: SHOULD be a
dial string 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.
5. A Route header SHOULD be present with a PSAP URI obtained from
LoST (see Section 8) and the loose route parameter. If the
device does not interpret dial plans, or was unable to obtain a
route from a LoST server, no Route header will be present.
6. A Contact header MUST be present which MUST be globally
routable, for example a GRUU [RFC5627], and be valid for several
minutes following the termination of the call, provided that the
UAC remains registered with the same registrar, to permit an
immediate call-back to the specific device which placed the
emergency call. It is acceptable if the UAC inserts a locally
routable URI and a subsequent B2BUA maps that to a globally
routable URI.
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,
by-reference or both.
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 [RFC5222], the Geolocation "used-for-routing"
header parameter MUST be added to the corresponding URI in the
Geolocation header. If the device is unable to obtain a PSAP
URI for any reason it MUST NOT include "used-for-routing" on a
Geolocation URI, so that downstream entities know that LoST
routing has not been completed.
12. A SDP offer SHOULD be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see
Section 14. As PSAPs may support a wide range of media types
and codecs, sending an offerless INVITE may result in a lengthy
return offer, but is permitted. Cautions in [RFC3261] on
offerless INVITEs should be considered before such use.
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" header parameter with its
own hostname 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. SIP Caller Preferences may also be used to
indicate a need to invoke a relay service for communication with
people with disabilities in the call.
ED-66 Devices device SHOULD have a globally routable URI in a
Contact: header which remains valid for 30 minutes past the time the
original call containing the URI completes unless the device
registration expires and is not renewed.
ED-67 During the course of an emergency call, devices and proxies
MUST support REFER transactions with method=INVITE and the
Referred-by: header [RFC3515] in that transaction.
ED-68 deleted
ED-69 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 (if implemented) expires, the call MAY be
declared lost. If in the interval, an incoming call is received from
the domain of the PSAP, the device MUST drop the old call and alert
for the (new) incoming call. Dropping of the old call MUST 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-70 User Agents and proxies MUST disable features that will
interrupt an ongoing emergency call, such as:
o Call Waiting
o Call Transfer
o Three Way Call
o Hold
o Outbound Call Blocking
when an emergency call is established. Also see ED-77 in Section 14.
ED-71 The emergency dial strings SHOULD NOT be permitted in Call
Forward numbers or speed dial lists.
ED-72 The User Agent and Proxies MUST disable call features which
would interfere with the ability of call backs from the PSAP to be
completed such as:
o Do Not Disturb
o Call Forward (all kinds)
ED-73 Call backs SHOULD be determined by retaining the domain of the
PSAP which answers an outgoing emergency call and instantiating a
timer which starts when the call is terminated. If a call is
received from the same domain and within the timer period, sent to
the Contact: or AoR used in the emergency call, it should be assumed
to be a call back. The suggested timer period is 5 minutes.
[RFC4916] may be used by the PSAP to inform the UA of the domain of
the PSAP. Recognizing a call back from the domain of the PSAP will
not always work, and further standardization will be required to give
the UA the ability to recognize a call back.
ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550].
ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to
agree on the media streams to be used.
ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law
if they are intended be used in North America) encoded voice as
described in [RFC3551]. It is desirable to include wideband codecs
such as AMR-WB in the offer.
ED-77 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-78 Endpoints supporting Instant Messaging (IM) MUST support both
[RFC3428] and [RFC4975].
ED-79 Endpoints supporting real-time text MUST use [RFC4103]. The
expectations for emergency service support for the real-time text
medium, described in [RFC5194], Section 7.1 SHOULD be fulfilled.
ED-80 Endpoints supporting video MUST support H.264 per [RFC3984].
ED-81 INVITE requests to a service URN ending in ".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 404 (Not Found) MUST be returned if the PSAP does not
support the test mechanism.
ED-82 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. Use of SIPS for
the request would assure the response containing the location is kept
private.
ED-83 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-84 User agents SHOULD perform a full call test, including media
loopback, after a disconnect and subsequent change in IP address not
due to a reboot. After an initial test, a full test SHOULD be
repeated approximately every 30 days with a random interval.
ED-85 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-86 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 provider that supports it MUST facilitate
emergency calling. Some jurisdictions have regulations governing
this.
SP-2 Proxy servers SHOULD recognize emergency dial strings if for
some reason the endpoint does not recognize them. This cannot be
relied upon by the device if the service provider cannot always
determine the location of the device.
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 Devices MUST be able to be configured with the home country from
which the home dial string(s) can be determined.
SP-6 Emergency dial strings SHOULD be determined from LoST [RFC5222].
Dial Strings MAY be configured directly in the device.
SP-7 If a proxy server recognizes dial strings on behalf of its
clients it MUST recognize emergency dial strings represented by
[RFC4967] and SHOULD recognize emergency dial strings represented by
a tel URI [RFC3966].
SP-8 Service providers MAY provide home dial strings by
configuration.
SP-9 All emergency services specified in [RFC5031] MUST be
recognized.
SP-10 Endpoints, Intermediate Devices 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 if:
o The proxy has a relationship with all access networks the device
could connect to, and the relationship allows it to obtain
location.
o The proxy has an identifier, such as an IP address, that can be
used by the access network to determine the location of the
endpoint, even in the presence of NAT and VPN tunnels that may
obscure the identifier between the access network and the service
provider.
SP-13 Where proxies provide location on behalf of endpoints, the
service provider MUST ensure that either the end device is provided
with the local dial strings for its current location (where the end
device recognizes dial strings), or the service provider proxy MUST
detect the appropriate local dial strings at the time of the call.
SP-14 When HELD is the LCP, the request MUST specify a value of
"emergencyRouting" for the "responseTime" parameter and use the
resulting location for routing. If a value for dispatch location
will be sent, another request with the "responseTime" parameter set
to "emergencyDispatch" must be completed, with the result sent for
dispatch purposes.
SP-15 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sip-location-conveyance].
SP-16 If the LIS has more than one location for an endpoint it MUST
use the procedures in [RFC5491]
SP-17 If a proxy inserts location on behalf of an endpoint, and it
has multiple locations available for the endpoint it MUST choose one
location to use to route the call towards the PSAP.
SP-18 If a proxy is attempting to insert location but the UA conveyed
a location to it, the proxy MUST use the UA's location for routing
and MUST convey that location towards the PSAP. It MAY also include
what it believes the location to be in a separate Geolocation header.
SP-19 All location objects received by a proxy MUST be delivered to
the PSAP.
SP-20 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-21 The "used-for-routing" parameter MUST be set to the location
that was chosen for routing.
SP-22 Proxies handling emergency calls MUST insert a default location
if the call does not contain a location and the proxy does not have a
method for obtaining a better location.
SP-23 Default locations MUST be marked with method=Default and the
proxy MUST be identified in provided-by element of the PIDF-LO.
SP-24 TLS MUST be used to protect location (but see Section 9.1).
IPSEC [RFC3986] is an acceptable alternative.
SP-25 Service Providers MUST provide an SRV entry in their DNS server
which leads to a LoST server
SP-26 Networks MUST be designed so that at least one proxy in the
outbound path will recognize emergency calls with a Request URI of
the service URN in the "sos" tree. An endpoint places a service URN
in the Request URI to indicate that the endpoint understood the call
was an emergency call. A proxy that processes such a call looks for
the presence of a SIP Route header field with a URI of a PSAP.
Absence of such a Route header indicates the UAC was unable to invoke
LoST and the proxy MUST perform the LoST mapping and insert a Route
header field with the URI obtained.
SP-27 To deal with old user agents that predate this specification
and with UAs that do not have access to their own location data, a
proxy that recognizes a call as an emergency call that is not marked
as such (see Section 5) MUST also perform this mapping, with the best
location it has available for the endpoint. The resulting PSAP URI
would be placed in a Route header with the service URN in the Request
URI.
SP-28 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-29 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-30 [RFC3261] and [RFC3263] procedures MUST be used to route an
emergency call towards the PSAP's URI.
SP-31 TLS MUST be specified when attempting to signal an emergency
call with SIP. IPSEC [RFC3986] is an acceptable alternative.
SP-32 If TLS session establishment is not available, or fails, the
call MUST be retried without TLS.
SP-33 [RFC5626] is RECOMMENDED to maintain persistent TLS connections
between elements.
SP-34 SIP Proxy servers processing emergency calls:
1. If the proxy interprets dial plans on behalf of user agents, the
proxy MUST look for the local emergency dial string at the
location of the end device and MAY look for the home dial string.
If it finds it, the proxy MUST:
* Insert a Geolocation header as above. Location-by-reference
MUST be used because proxies must not insert bodies.
* Include the Geolocation "inserted-by" and "used-for-routing"
parameters with its own hostname (which should match the Via
it inserts) on the inserted-by.
* Map the location to a PSAP URI using LoST.
* Add a Route header with the PSAP URI.
* Replace the Request-URI (which was the dial string) with the
service URN appropriate for the emergency dial string.
* Route the call using normal SIP routing mechanisms.
2. If the proxy recognizes the service URN in the Request URI, and
does not find a a Route header, it MUST query a LoST server. If
multiple locations were provided, the proxy uses the location
that has the "used-for-routing" marker set. 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, SHOULD be included to identify the sender.
For services which must support emergency calls from
unauthenticated devices, valid identity may not be available.
SP-35 Devices device SHOULD have a globally routable URI in a
Contact: header which remains valid for 30 minutes past the time the
original call containing the URI completes unless the device
registration expires and is not renewed.
SP-36 Call backs to the Contact: header URI recieved within 30
minutes of an emergency call must reach the device regardless of call
features or services that would normally cause the call to be routed
to some other entity.
SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted-
Identity: header or From: protected by an Identity header suitable
for returning a call some time after the original call. Such a call
back would not necessarily reach the device that originally placed
the call.
SP-38 During the course of an emergency call, devices and proxies
MUST support REFER transactions with method=INVITE and the
Referred-by: header [RFC3515] in that transaction.
SP-39 User Agents and proxies MUST disable features that will
interrupt an ongoing emergency call, such as:
o Call Waiting
o Call Transfer
o Three Way Call
o Hold
o Outbound Call Blocking
when an emergency call is established. Also see ED-77 in Section 14.
SP-40 The emergency dial strings SHOULD NOT be permitted in Call
Forward numbers or speed dial lists.
SP-41 The User Agent and Proxies MUST disable call features which
would interfere with the ability of call backs from the PSAP to be
completed such as:
o Do Not Disturb
o Call Forward (all kinds)
A.3. Requirements of Access Network
AN-1 LoST servers MUST return dial strings for emergency services
AN-2 Elements MUST NOT convert (civic to geo or geo to civic) from
the form of location the determination mechanism supplied.
AN-3 Any suitable location determination mechanism MAY be used.
AN-4 Devices, intermediate Devices and/or access networks SHOULD
support a manual method to "override" the location the access network
determines. Where a civic form of location is provided, all fields
in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified.
AN-5 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-6 Access networks and intermediate devices providing wire database
location information SHOULD provide interior location data (building,
floor, room, cubicle) where possible. It is RECOMMENDED that
interior location be provided when spaces exceed approximately 650
square meters.
AN-7 Access networks and intermediate devices (including enterprise
networks) which support intermediate range wireless connections
(typically 100m or less of range) and which do not support a more
accurate location determination mechanism such as triangulation, MUST
support location configuration where the location of the access point
is reflected as the location of the clients of that access point.
Where the access network provides location configuration,
intermediate devices MUST either be transparent to it, or provide an
interconnected client for the supported configuration mechanism and a
server for a configuration protocol supported by end devices
downstream of the intermediate device
AN-8 Devices that support endpoint measuring of location MUST have at
least a coarse location capability (typically <1km accuracy when not
location hiding) for routing of calls. The location mechanism MAY be
a service provided by the access network.
AN-9 Access networks MAY provide network-measured location
determination. Wireless access network which do not support network
measured location MUST require that all devices connected to the
network have end-system measured location. Uncertainty of less than
100 m with 95% confidence SHOULD be available for dispatch.
AN-10 Access networks that provide network measured location MUST
have at least a coarse location (typically <1km when not location
hiding) capability at all times for routing of calls.
AN-11 Access networks with range of <10 meters (e.g. personnal area
networks such as Bluetooth MUST provide a location to mobile devices
connected to them. The location provided SHOULD be that of the
access point location unless a more accurate mechanism is provided.
AN-12 The access network MUST support either DHCP location options or
HELD. The access network SHOULD support other location technologies
that are specific to the type of access network.
AN-13 Where a router is employed between a LAN and WAN in a small
(less than approximately 650 square meters) area, the router MUST be
transparent to the location provided by the WAN to the LAN. This may
mean the router must obtain location as a client from the WAN, and
supply an LCP server to the LAN with the location it obtains. Where
the area is larger, the LAN MUST have a location configuration
mechanism meeting this BCP.
AN-14 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-15 Network administrators MUST take care in assigning IP addresses
such that VPN address assignments can be distinguished from local
devices (by subnet choice, for example), and LISs SHOULD NOT attempt
to provide location to addresses that arrive via VPN connections
unless it can accurately determine the location for such addresses.
AN-16 Placement of NAT devices where an LCP uses IP address for an
identifier SHOULD consider the effect of the NAT on the LCP. The
address used to query the LIS MUST be able to correctly identify the
record in the LIS representing the location of the querying device
AN-17 It is RECOMMENDED that location determination not take longer
than 250 ms to obtain routing location and systems SHOULD be designed
such that the typical response is under 100 ms. However, as much as
3 seconds to obtain routing location MAY be tolerated if location
accuracy can be substantially improved over what can be obtained in
250 ms.
AN-18 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-19 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-20 The LIS SHOULD provide a location reference which permits a
subscription with appropriate filtering.
AN-21 For calls sent with location-by-reference, with a SIP or SIPS
scheme, the server resolving the reference MUST support a SUBSCRIBE
[RFC3265] to the presence event [RFC3856]. For other location-by-
reference schemes that do not support subscription, the PSAP will
have to repeatedly dereference the URI to determine if the device
moved.
AN-22 A LIS should perform location validation of civic locations via
LoST before entering a location in its database.
AN-23 When the access network cannot determine the actual location of
the caller, it MUST supply a default location. The default SHOULD be
chosen to be as close to the probable location of the device as the
network can determine. See [I-D.ietf-ecrit-framework]
AN-24 Default locations MUST be marked with method=Default and the
proxy MUST be identified in provided-by element of the PIDF-LO.
AN-25 To prevent against spoofing of the DHCP server, elements
implementing DHCP for location configuration SHOULD use [RFC3118]
although the difficulty in providing appropriate credentials is
significant.
AN-26 Access networks which support DHCP MUST implement the LoST
discovery option
AN-27 Access Networks that use HELD and that have a DHCP server
SHOULD support DHCP options for providing LIS and LoST servers.
AN-28 TLS MUST be specified when attempting to retrieve location
(configuration or dereferencing) with HELD. The use of [RFC5077] is
RECOMMENDED to minimize the time to establish TLS sessions without
keeping server-side state.
AN-29 If TLS session establishment fails, the location retrieval MUST
be retried without TLS.
A.4. Requirements of Intermediate Devices
INT-1 Endpoints, Intermediate Devices and Service Providers MUST be
prepared to handle location represented in either civic or geo form.
INT-2 Elements MUST NOT convert (civic to geo or geo to civic) from
the form of location the determination mechanism supplied.
INT-3 Any suitable location determination mechanism MAY be used.
INT-4 Devices, intermediate Devices and/or access networks SHOULD
support a manual method to "override" the location the access network
determines. Where a civic form of location is provided, all fields
in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified.
INT-5 Access networks and intermediate devices providing wire
database location information SHOULD provide interior location data
(building, floor, room, cubicle) where possible. It is RECOMMENDED
that interior location be provided when spaces exceed approximately
650 square meters.
INT-6 Access networks and intermediate devices (including enterprise
networks) which support intermediate range wireless connections
(typically 100m or less of range) and which do not support a more
accurate location determination mechanism such as triangulation, MUST
support location configuration where the location of the access point
is reflected as the location of the clients of that access point.
Where the access network provides location configuration,
intermediate devices MUST either be transparent to it, or provide an
interconnected client for the supported configuration mechanism and a
server for a configuration protocol supported by end devices
downstream of the intermediate device
INT-7 Devices MAY support end-system measured location. Uncertainty
of less than 100 m with 95% confidence SHOULD be available for
dispatch.
INT-8 Devices that support endpoint measuring of location MUST have
at least a coarse location capability (typically <1km accuracy when
not location hiding) for routing of calls. The location mechanism
MAY be a service provided by the access network.
INT-9 Endpoints SHOULD attempt to configure their own location using
the LCPs listed in ED-21.
INT-10 Where proxies provide location on behalf of endpoints, the
service provider MUST ensure that either the end device is provided
with the local dial strings for its current location (where the end
device recognizes dial strings), or the service provider proxy MUST
detect the appropriate local dial strings at the time of the call.
INT-11 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.
INT-12 Devices MUST support both the DHCP location options [RFC4776],
[RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When
devices deploy a specific access network interface in which that
access network supports location discovery such as LLDP-MED or
802.11v, the device SHOULD support the additional respective access
network specific location discovery mechanism.
INT-13 The access network MUST support either DHCP location options
or HELD. The access network SHOULD support other location
technologies that are specific to the type of access network.
INT-14 Where a router is employed between a LAN and WAN in a small
(less than approximately 650 square meters) area, the router MUST be
transparent to the location provided by the WAN to the LAN. This may
mean the router must obtain location as a client from the WAN, and
supply an LCP server to the LAN with the location it obtains. Where
the area is larger, the LAN MUST have a location configuration
mechanism meeting this BCP.
INT-15 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.
INT-16 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.
INT-17 When HELD is the LCP, the request MUST specify a value of
"emergencyRouting" for the "responseTime" parameter and use the
resulting location for routing. If a value for dispatch location
will be sent, another request with the "responseTime" parameter set
to "emergencyDispatch" must be completed, with the result sent for
dispatch purposes.
INT-18 Endpoints SHOULD obtain location immediately after obtaining
local network configuration information. When HELD is the LCP the
client MUST support a random back-off period (between 30 seconds and
300 seconds) for re-trying the HELD query, when no response is
received, and no other LCP provided location information.
INT-19 If the device is configured to use DHCP for bootstrapping, it
MUST include both options for location acquisition (civic and
geodetic), the option for LIS discovery, and the option for LoST
discovery as defined in [RFC4776], [RFC3825],
[I-D.ietf-geopriv-lis-discovery] and [RFC5223].
INT-20 If the device sends a DHCPINFORM message, it MUST include both
options for location acquisition (civic and geodetic), the option for
LIS discovery, and the option for LoST discovery as defined in
[RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and [RFC5223].
INT-21 To minimize the effects of VPNs that do not allow packets to
be sent via the native hardware interface rather than via the VPN
tunnel, location configuration SHOULD be attempted before such
tunnels are established.
INT-22 Software which uses LCPs SHOULD locate and use the actual
hardware network interface rather than a VPN tunnel interface to
direct LCP requests to the LIS in the actual access network.
INT-23 For devices which are not expected to roam, refreshing
location on the order of once per day is RECOMMENDED.
INT-24 For devices which roam, refresh of location information SHOULD
be more frequent, with the frequency related to the mobility of the
device and the ability of the access network to support the refresh
operation. If the device can detect that it has moved, for example
when it changes access points, the device SHOULD refresh its
location.
INT-25 It is RECOMMENDED that location determination not take longer
than 250 ms to obtain routing location and systems SHOULD be designed
such that the typical response is under 100 ms. However, as much as
3 seconds to obtain routing location MAY be tolerated if location
accuracy can be substantially improved over what can be obtained in
250 ms.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar NeuStar
470 Conrad Dr. 470 Conrad Dr.
Mars, PA 16046 Mars, PA 16046
US USA
Phone: +1 724 382 1051 Phone: +1 724 382 1051
Email: br@brianrosen.net Email: br@brianrosen.net
James Polk James Polk
Cisco Systems Cisco Systems
3913 Treemont Circle 3913 Treemont Circle
Colleyville, TX 76034 Colleyville, TX 76034
US USA
Phone: +1-817-271-3552 Phone: +1-817-271-3552
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
 End of changes. 127 change blocks. 
1237 lines changed or deleted 264 lines changed or added

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