draft-ietf-ecrit-phonebcp-02.txt   draft-ietf-ecrit-phonebcp-03.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track J. Polk Intended status: Standards Track J. Polk
Expires: March 21, 2008 Cisco Systems Expires: May 22, 2008 Cisco Systems
September 18, 2007 November 19, 2007
Best Current Practice for Communications Services in support of Best Current Practice for Communications Services in support of
Emergency Calling Emergency Calling
draft-ietf-ecrit-phonebcp-02 draft-ietf-ecrit-phonebcp-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 21, 2008. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The IETF has several efforts targeted at standardizing various The IETF and other standards organization have efforts targeted at
aspects of placing emergency calls. This memo describes best current standardizing various aspects of placing emergency calls on IP
practice on how devices, networks and services should use such networks. This memo describes best current practice on how devices,
standards to make emergency calls. networks and services should use such standards to make emergency
calls.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of how emergency calls are placed . . . . . . . . . . 3 3. Overview of how emergency calls are placed . . . . . . . . . . 3
4. Which devices and sevices should support emergency calls . . 3 4. Which devices and services should support emergency calls . . 4
5. Identifying an emergency call . . . . . . . . . . . . . . . . 4 5. Identifying an emergency call . . . . . . . . . . . . . . . . 4
6. Location and its role in an emergency call . . . . . . . . . . 5 6. Location and its role in an emergency call . . . . . . . . . . 5
6.1. Types of location information . . . . . . . . . . . . . . 5 6.1. Types of location information . . . . . . . . . . . . . . 5
6.2. Location Determination . . . . . . . . . . . . . . . . . . 5 6.2. Location Determination . . . . . . . . . . . . . . . . . . 5
6.2.1. User-entered location information . . . . . . . . . . 5 6.2.1. User-entered location information . . . . . . . . . . 6
6.2.2. Access network "wire database" location 6.2.2. Access network "wire database" location
information . . . . . . . . . . . . . . . . . . . . . 5 information . . . . . . . . . . . . . . . . . . . . . 6
6.2.3. End-system measured location information . . . . . . 6 6.2.3. End-system measured location information . . . . . . . 6
6.2.4. Network measured location information . . . . . . . . 6 6.2.4. Network-measured location information . . . . . . . . 6
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 6 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 7
6.4. Location and references to location . . . . . . . . . . . 7 6.4. Location and references to location . . . . . . . . . . . 7
6.5. End system location configuration . . . . . . . . . . . . 7 6.5. End system location configuration . . . . . . . . . . . . 7
6.6. When location should be configured . . . . . . . . . . . . 7 6.6. When location should be configured . . . . . . . . . . . . 8
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 8 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 9
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 8 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 10
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 9 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 10
6.10. Location validation . . . . . . . . . . . . . . . . . . . 9 6.10. Location validation . . . . . . . . . . . . . . . . . . . 11
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 10 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 11
6.12. Other location considerations . . . . . . . . . . . . . . 10 6.12. Other location considerations . . . . . . . . . . . . . . 11
7. Uninitialized devices . . . . . . . . . . . . . . . . . . . . 10 6.13. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . 11
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 11 7. Uninitialized devices . . . . . . . . . . . . . . . . . . . . 12
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 12 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 12
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 13
9.2. SIP signaling requirements for User Agents . . . . . . . . 12 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 13
9.3. SIP signaling requirements for proxy servers . . . . . . . 13 9.2. SIP signaling requirements for User Agents . . . . . . . . 14
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.3. SIP signaling requirements for proxy servers . . . . . . . 15
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 14 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 15 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 16
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 15 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 16
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 17
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
16. Security Considerations . . . . . . . . . . . . . . . . . . . 17 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 16. Security Considerations . . . . . . . . . . . . . . . . . . . 19
18. Normative References . . . . . . . . . . . . . . . . . . . . . 18 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. BCP Requirements Sorted by Responsible Party . . . . 22 18. Normative References . . . . . . . . . . . . . . . . . . . . . 19
A.1. Requirements of End Devices . . . . . . . . . . . . . . . 22 Appendix A. BCP Requirements Sorted by Responsible Party . . . . 24
A.2. Requirements of Service Providers . . . . . . . . . . . . 30 A.1. Requirements of End Devices . . . . . . . . . . . . . . . 24
A.3. Requirements of Access Networks . . . . . . . . . . . . . 34 A.2. Requirements of Service Providers . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 A.3. Requirements of Access Networks . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 40
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], This document uses terms from [RFC3261],
[I-D.ietf-ecrit-requirements] and [I-D.ietf-ecrit-framework]. [I-D.ietf-ecrit-requirements] and [I-D.ietf-ecrit-framework].
2. Introduction 2. Introduction
This document describes how SIP User Agents and proxy servers support This document describes how access networks, SIP user agents, proxy
emergency calling, as outlined in [I-D.ietf-ecrit-framework], which servers and PSAPs support emergency calling, as outlined in
is designed to complement the present document in section headings, [I-D.ietf-ecrit-framework], which is designed to complement the
numbering and content. This BCP succinctly describes the present document in section headings, numbering and content. This
requirements of end devices and applications, access networks, BCP succinctly describes the requirements of end devicesand
service providers and PSAPs to achieve globally interoperable applications (requirements prefaced by "ED-"), access networks
(requirements prefaced by "AN-", service providers (requirements
prefaced by "SP-") and PSAPs to achieve globally interoperable
emergency calling on the Internet. emergency calling on the Internet.
This document also defines requirements for "Intermediate" devices
which exist between end devices or applications and the access
network. For example, a home router is an "Intermediate" device.
Reporting location on an emergency call (see Section 6 may depend on
the ability of such intermediate devices to meet these requirements.
3. Overview of how emergency calls are placed 3. Overview of how emergency calls are placed
An emergency call can be distinguished (Section 5) from any other An emergency call can be distinguished (Section 5) from any other
call by a unique Service URN[I-D.ietf-ecrit-service-urn], which is call by a unique Service URN[I-D.ietf-ecrit-service-urn], which is
placed in the call set-up signaling when a home or visited emergency placed in the call set-up signaling when a home or visited emergency
dial string is detected. Because emergency services are local to dial string is detected. Because emergency services are local to
specific geographic regions, a caller must obtain his location specific geographic regions, a caller must obtain his location
(Section 6) prior to making emergency calls.. To get this location, (Section 6) prior to making emergency calls. To get this location,
either a form of measuring (e.g. GPS) (Section Section 6.2.3) device either a form of measuring (e.g., GPS) (Section 6.2.3) device
location in the endpoint is deployed, or the endpoint is configured location in the endpoint is deployed, or the endpoint is configured
(Section 6.5) with its location from the access network's Location (Section 6.5) with its location from the access network's Location
Information Server (LIS). The location is conveyed ( Section 6.7) in Information Server (LIS). The location is conveyed ( Section 6.7) in
the SIP signaling with the call. The call is routed (Section 8) the SIP signaling with the call. The call is routed (Section 8)
based on location using the LoST protocol [I-D.ietf-ecrit-lost]) based on location using the LoST protocol [I-D.ietf-ecrit-lost],
which maps a location to a set of PSAP URIs. Each URI resolves to a which maps a location to a set of PSAP URIs. Each URI resolves to a
PSAP or an Emergency Services Routing Proxy (ESRP) which serves a PSAP or an Emergency Services Routing Proxy (ESRP), which serves a
group of PSAPs. The call arrives at the PSAP with the location group of PSAPs. The call arrives at the PSAP with the location
included in the INVITE request. included in the SIP INVITE request.
4. Which devices and sevices should support emergency calls 4. Which devices and services should support emergency calls
ED-1 if a user could reasonably expect to be able to place a call for ED-1 A device or application SHOULD support emergency calling if a
help with the device, then the device or application SHOULD support user could reasonably expect to be able to place a call for help with
emergency calling. the device.
SP-1 If a device or application expects to be able to place a call SP-1 If a device or application expects to be able to place a call
for help, the service that supports it SHOULD facilitate emergency for help, the service provider that supports it MUST facilitate
calling. emergency calling.
ED-2 Devices that create media sessions and exchange audio, video ED-2 Devices that create media sessions and exchange audio, video
and/or text, and have the capability to establish sessions to a wide and/or text, and have the capability to establish sessions to a wide
variety of addresses, and communicate over private IP networks or the variety of addresses, and communicate over private IP networks or the
Internet, SHOULD support emergency calls. Internet, SHOULD support emergency calls.
5. Identifying an emergency call 5. Identifying an emergency call
ED-3 Endpoints SHOULD do dial string recognition of emergency dial ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If
strings. the service provider always knows the location of the device, then
the service provider could recognize them.
SP-2 Proxy servers SHOULD do dial string recognition of emergency SP-2 Proxy servers SHOULD recognize emergency dial string if for some
dial strings if for some reason the endpoint does not recognize them. 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.
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 Home dial strings MAY be recognized. ED-6/SP-5 Home dial strings MAY be recognized.
ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST
[I-D.ietf-ecrit-lost]. [I-D.ietf-ecrit-lost].
ED-8 Endpoints which do not recognize emergency dial strings SHOULD ED-8 Endpoints which do not recognize emergency dial strings SHOULD
send dial strings as per [RFC4967]. send dial strings as per [RFC4967].
SP-7 Proxy Servers MUST recognize emergency dial strings represented SP-7 Proxy Servers MUST recognize emergency dial strings represented
by [RFC4967] and SHOULD recognize dial strings represented by a tel by [RFC4967] and SHOULD recognize emergency dial strings represented
URI [RFC3966]. by a tel URI [RFC3966].
SP-8 Service providers MAY provide home dial strings by configuration SP-8 Service providers MAY provide home dial strings by configuration
[I-D.ietf-sipping-config-framework]. [I-D.ietf-sipping-config-framework].
ED-9 Endpoints SHOULD be able to have home dial strings provisioned ED-9 Endpoints SHOULD be able to have home dial strings provisioned
by configuration. by configuration.
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 ED-11/SP-9 All emergency services specified in
[I-D.ietf-ecrit-service-urn] MUST be recognized. Devices/Service [I-D.ietf-ecrit-service-urn] MUST be recognized.
Providers MUST be capable of recognizing all of the associated dial
strings.
6. Location and its role in an emergency call 6. Location and its role in an emergency call
Location usually involves several steps to process and multiple Handling location for emergency calling usually involves several
elements are involved. In Internet emergency calling, where the steps to process and multiple elements are involved. In Internet
endpoint is located is "Determined" using a variety of measurement or emergency calling, where the endpoint is located is "determined"
wiretracing methods. Endpoints may be "Configured" with their own using a variety of measurement or wiretracing methods. Endpoints may
location by the access network. In some circumstances, a proxy be "configured" with their own location by the access network. In
server may insert location into the signaling on behalf of the some circumstances, a proxy server may insert location into the
endpoint. The location is "Mapped" to the URI to send the call to, signaling on behalf of the endpoint. The location is "mapped" to the
and the location is "Conveyed" to the PSAP (and other elements) in URI to send the call to, and the location is "conveyed" to the PSAP
the signaling. Likewise, we employ Location Configuration Protocols, (and other elements) in the signaling. Likewise, we employ Location
Location Mapping Protocols, and Location Conveyance Protocols for Configuration Protocols, the Location-to-Service Mapping Protocol,
these functions. The Location-to-Service Translation protocol and Location Conveyance Protocols for these functions. The Location-
[I-D.ietf-ecrit-lost] is the Location Mapping Protocol defined by the to-Service Translation protocol [I-D.ietf-ecrit-lost] is the Location
IETF. Mapping Protocol defined by the IETF.
6.1. Types of location information 6.1. Types of location information
There are several ways location can be specified. In IETF protocols, There are several forms of location. In IETF protocols, civic and
civic and geospatial (geo) forms are both supported. The civic forms geospatial (geo) forms are both supported. The civic forms include
include both postal and jurisdictional fields. A cell tower/sector both postal and jurisdictional fields. A cell tower/sector can be
can be represented as a point (geo or civic) or polygon. Other forms represented as a point (geo or civic) or polygon. Other forms of
of location representation must be mapped into either a geo or civic location representation must be mapped into either a geo or civic for
for use in emergency calls. use in emergency calls.
ED-12/SP-10 Endpoints and Service Providers MUST be prepared to ED-12/INT-1/SP-10 Endpoints, Intermediate Devices and Service
handle location represented in either civic or geo form. Providers MUST be prepared to handle location represented in either
civic or geo form.
ED-13/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo to ED-13/INT-2/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo
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/AN-2 Any suitable location determination mechanism MAY be used. ED-14/INT-3/AN-2 Any suitable location determination mechanism MAY be
used.
6.2.1. User-entered location information 6.2.1. User-entered location information
ED-15/AN-3 Devices and/or access networks SHOULD support a manual ED-15/INT-3/AN-3 Devices, intermediate Devices and/or access networks
method to "override" the location the access network determines. SHOULD support a manual method to "override" the location the access
Where a civic form of location is provided, all fields in the PIDF-LO network determines. Where a civic form of location is provided, all
[RFC4119] and [I-D.ietf-geopriv-revised-civic-lo] MUST be able to be fields in the PIDF-LO [RFC4119] and
specified. [I-D.ietf-geopriv-revised-civic-lo] MUST be able to be specified.
6.2.2. Access network "wire database" location information 6.2.2. Access network "wire database" location information
AN-4 Access networks supporting copper, fiber or other hard wired IP AN-4 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.
AN-5 Access networks providing wire database location information AN-5/INT-4 Access networks and intermediate devices providing wire
SHOULD provide interior location data where possible. It is database location information SHOULD provide interior location data
RECOMMENDED that interior location be provided when spaces exceed (building, floor, room, cubicle) where possible. It is RECOMMENDED
approximately 650 m2. that interior location be provided when spaces exceed approximately
650 square meters.
AN-6 Access networks (including enterprise networks) which support AN-6/INT-5 Access networks and intermediate devices (including
intermediate range wireless connections (typically 100m or less of enterprise networks) which support intermediate range wireless
range) and which do not support a more accurate location connections (typically 100m or less of range) and which do not
determination mechanism such as triangulation, MUST support location support a more accurate location determination mechanism such as
configuration which reports the location of the access point as the triangulation, MUST support location configuration where the location
location of the clients of that access point. of the access point is reflected as the location of the clients of
that access point. Where the access network provides location
configuration, intermediate devices MUST either be transparent to it,
or provide an interconnected client for the supported configuration
mechanism and a server for a configuration protocol supported by end
devices upstream of the intermediate device
6.2.3. End-system measured location information 6.2.3. End-system measured location information
ED-16 devices MAY support end-system measured location. Uncertainty ED-16/INT-6 Devices MAY support end-system measured location.
of less than 100 m with 95% confidence SHOULD be available for Uncertainty of less than 100 m with 95% confidence SHOULD be
dispatch. available for dispatch.
ED-17/AN-7 Devices that support endpoint measuring of location MUST ED-17/INT-7/AN-7 Devices that support endpoint measuring of location
have at least a coarse location (<1km) capability at all times for MUST have at least a coarse location capability (typically <1km
routing of calls. This mechanism MAY be a service provided by the accuracy when not location hiding) at all times for routing of calls.
access network. This 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-8 Access networks MAY provide network measured location AN-8 Access networks MAY provide network-measured location
determination. Wireless access network which do not support network determination. Wireless access network which do not support network
measured location MUST require all devices connected to the network measured location MUST require that all devices connected to the
have end-system measured location. Uncertainty of less than 100 m network have end-system measured location. Uncertainty of less than
with 95% confidence SHOULD be available for dispatch. 100 m with 95% confidence SHOULD be available for dispatch.
AN-9 Access networks that provide network measured location MUST have AN-9 Access networks that provide network measured location MUST have
at least a coarse location (<1km) capability at all times for routing at least a coarse location (typically <1km when not location hiding)
of calls. capability at all times for routing of calls.
AN-10 Access networks with range of <10M MUST provide a location to AN-10 Access networks with range of <10 meters MUST provide a
mobile devices connected to it. The location provided SHOULD be that location to mobile devices connected to it. The location provided
of the beacon location unless a more accurate mechanism is provided. SHOULD be that of the 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 Endpoints SHOULD do location configuration themselves. ED-18/INT-8 Endpoints SHOULD do configure their own location.
SP-12 Proxies MAY provide location on behalf of devices it supports
if:
o It has a relationship with all access networks the device could SP-12 Proxies MAY provide location on behalf of devices if:
connect to, and the relationship allows it to obtain location. o The proxy has a relationship with all access networks the device
o It has an identifier that can be used by the access network to could connect to, and the relationship allows it to obtain
determine the location of the endpoint, particularly in the location.
presence of NAT and VPN tunnels that may exist between the access o The proxy has an identifier, such as an IP address, that can be
network and the service provider. used by the access network to determine the location of the
endpoint, even in the presence of NAT and VPN tunnels that may
obscure the identifier between the access network and the service
provider.
ED-19/SP-13 Where proxies provide location on behalf of endpoints, ED-19/INT-9/SP-13 Where proxies provide location on behalf of
the proxy MUST provide a mechanism to supply emergency dial strings endpoints, the the service provider MUST ensure that either the end
to the device if the device recognizes them, or the proxy MUST track device is provided with the local dial strings for its current
the location of the device with sufficient accuracy and timeliness to location (where the end device recognizes dial strings), or the
be able to recognize the local dial string at the time of an service provider proxy MUST detect the appropriate local dial strings
emergency call. at the time of the call.
6.4. Location and references to location 6.4. Location and references to location
ED-20 Devices SHOULD be able to accept and forward location by value ED-20/INT-10 Devices SHOULD be able to accept and forward location by
or by reference. An end device that receives location by reference value or by reference. An end device that receives location by
(and does not also get the corresponding value) MUST be able to reference (and does not also get the corresponding value) MUST be
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 endpoints MUST support all of: DHCP Location options [RFC4676] ED-21/INT-11 Devices MUST support all of: DHCP location options
and [RFC3825], HELD[I-D.ietf-geopriv-http-location-delivery] and [RFC4676] and [RFC3825], HELD
LLDP-MED[LLDP-MED]. [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED].
AN-11 The access network MUST support at least one of DHCP location AN-11/INT-12 The access network MUST support at least one of: DHCP
options, HELD or LLDP-MED. location options, HELD or LLDP-MED.
AN-12 Where a router is employed between a LAN and WAN in a small AN-12/INT-13 Where a router is employed between a LAN and WAN in a
(less than approximately 650m2), the LAN MUST reflect the location small (less than approximately 650 square meters) area, the router
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
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.
ED-22 Endpoints SHOULD try all LCPs supported by the device in any ED-22/INT-14 Endpoints SHOULD try all LCPs supported by the device in
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 can be used.
AN-13 Access networks that support more than one LCP MUST reply with AN-13/INT-15 Access networks that support more than one LCP MUST
the same location information (within the limits of the data format reply with the same location information (within the limits of the
for the specific LCP) for all LCPs it supports. data format for the specific LCP) for all LCPs it supports.
ED-??/INT-??/SP-?? When HELD is the LCP, the request MUST specify a
value of "emergencyRouting" for the "responseTime" parameter and use
the resulting location for routing. If a value for dispatch location
will be sent, another request with the "responseTime" parameter set
to "emergencyDispatch" must be completed, with the result sent for
dispatch purposes.
ED-?? Where the operating system supporting application programs
which need location for emergency calls does not allow access to
Layer 2 and Layer 3 functions necessary for a client application to
use DHCP location options and/or LLDP-MED, the operating system MUST
provide a published API conforming to ED-12 through ED-18 and ED-21
through ED-27. It is RECOMMENDED that all operating systems provide
such an API.
6.6. When location should be configured 6.6. When location should be configured
ED-23 Endpoints SHOULD obtain location immediately after obtaining ED-23/INT-16 Endpoints SHOULD obtain location immediately after
local network configuration information. 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.
ED-24 To minimize the effects of non-bypassable VPNs, location ED-??/INT-?? If the device is configured to use DHCP for
configuration SHOULD be attempted before such tunnels are bootstrapping, it MUST include both options for location acquisition
established. (civic and geodetic), the option for LIS discovery, and the option
for LoST discovery as defined in [RFC4676], [RFC3825],
[I-D.thomson-geopriv-lis-discovery] and
[I-D.ietf-ecrit-dhc-lost-discovery].
ED-25 Software which uses LCPs SHOULD locate and use the actual ED-??/INT-?? If the device sends a DHCP INFORM message, it MUST
hardware network interface. include both options for location acquisition (civic and geodetic),
the option for LIS discovery, and the option for LoST discovery as
defined in [RFC4676], [RFC3825], [I-D.thomson-geopriv-lis-discovery]
and [I-D.ietf-ecrit-dhc-lost-discovery].
ED-24/INT-16 To minimize the effects of VPNs that do not allow split
tunneling VPNs, location configuration SHOULD be attempted before
such tunnels are established.
ED-25/INT-17 Software which uses LCPs SHOULD locate and use the
actual hardware network interface rather than a VPN tunnel interface
to direct LCP requests to the LIS in the actual access network.
AN-14 Network administrators MUST take care in assigning IP addresses AN-14 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.
AN-15 Placement of NAT devices should consider the effect of the NAT AN-15 Placement of NAT devices SHOULD consider the effect of the NAT
on the LCP. on the LCP.
ED-26 For devices which are not expected to roam, refreshing on the ED-26/INT-18 For devices which are not expected to roam, refreshing
order of once per day is RECOMMENDED. location on the order of once per day is RECOMMENDED.
ED-27 For devices which roam, refresh of location SHOULD be more ED-27/INT-19 For devices which roam, refresh of location information
frequent, with the frequency related to the mobility of the device SHOULD be more frequent, with the frequency related to the mobility
and the ability of the access network to support the refresh of the device and the ability of the access network to support the
operation. There can be instances in which a device is aware of when refresh operation. If the device can detect that it has moved, for
it moves, for example when it changes access points. When this type example when it changes access points, the device SHOULD refresh its
of event occurs, the device SHOULD refresh its location. location.
ED-28/AN-16 It is RECOMMENDED that location determination not take ED-28/INT-20/AN-16 It is RECOMMENDED that location determination not
longer than 250 ms to obtain routing location and systems SHOULD be take longer than 250 ms to obtain routing location and systems SHOULD
designed such that the typical response is under 100ms. However, as be designed such that the typical response is under 100 ms. However,
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-29/SP-14 Location sent between SIP elements MUST be conveyed using ED-29/SP-14 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-30/AN-17 Where the absolute location, or the accuracy of location ED-30/AN-17 Where the absolute location or the accuracy of location
of the endpoint may change between the time the call is received at 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 provided.
ED-31/AN-18 mobile devices MUST be provided with a mechanism to get ED-31/AN-18 Mobile devices MUST be provided with a mechanism to get
repeated location updates to track the motion of the device during repeated location updates to track the motion of the device during
the complete processing of the call. the complete processing of the call.
ED-32/AN-19 The LIS SHOULD provide a location reference which permits ED-32/AN-19 The LIS SHOULD provide a location reference which permits
a subscription with appropriate filtering. a subscription with appropriate filtering.
ED-33/AN-20 For calls sent with location-by-reference, with a SIP or ED-33/AN-20 For calls sent with location-by-reference, with a SIP or
SIPS scheme, the server resolving the reference MUST support a SIPS scheme, the server resolving the reference MUST support a
SUBSCRIBE [RFC3118] to the presence event [RFC3856]. For other SUBSCRIBE [RFC3118] to the presence event [RFC3856]. For other
location-by-reference schemes, a repeated location dereference by the location-by-reference schemes, the PSAP will have to repeatedly
PSAP MUST be supported. dereference the URI to determine if the device moved.
ED-34 If location was sent by value, and the endpoint gets updated ED-34 If location was sent by value, and the endpoint gets updated
location, it MUST send the updated location to the PSAP via reINVITE location, it MUST send the updated location to the PSAP via a SIP re-
or UPDATE. Such updates SHOULD be limited to no more than one update INVITE or UPDATE request. Such updates SHOULD be limited to no more
every 10 seconds. than one update every 10 seconds.
6.9. Multiple locations 6.9. Multiple locations
ED-35 If a UA has more than one location available to it, it MUST ED-35 If a UA has more than one location available to it, it MUST
choose one location to use to route the call towards the PSAP. choose one location to route the call towards the PSAP.
SP-15 If a proxy inserts location on behalf of an endpoint, and it SP-15 If a proxy inserts location on behalf of an endpoint, and it
has multiple locations available for the endpoint it MUST choose one 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.
SP-16 If a proxy is attempting to assert location but the UA conveyed SP-16 If a proxy is attempting to insert location but the UA conveyed
a location to it, the proxy must use the UA?s location for routing 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. what it believes the location to be in a separate Geolocation header.
SP-17 All location objects received by a proxy MUST be delivered to SP-17 All location objects received by a proxy MUST be delivered to
the PSAP. the PSAP.
ED-36/SP-18 Location objects MUST contain information about the ED-36/SP-18 Location objects MUST contain information about the
method by which the location was determined, such as GPS, manually method by which the location was determined, such as GPS, manually
entered, or based on access network topology included in a PIDF- LO entered, or based on access network topology included in a PIDF- LO
?method? element. In addition, the source of the location "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-37/SP-19 The "used-for-routing" parameter MUST be set to the ED-37/SP-19 The "used-for-routing" parameter MUST be set to the
location that was used to query LoST. location that was used to query LoST.
6.10. Location validation 6.10. Location validation
AN-21 Location validation of civic locations via LoST SHOULD be AN-21 A LIS should perform location validation of civic locations via
performed by the LIS before entering a location in its database. LoST before entering a location in its database.
ED-38 Endpoints SHOULD validate civic locations when they receive ED-38 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-22 When the access network cannot determine the actual location of AN-22 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. network can determine. See [I-D.ietf-ecrit-framework]
SP-20 Proxies handling emergency calls MUST insert a default location SP-20 Proxies handling emergency calls MUST insert a default location
if the call does not contain a location. if the call does not contain a location and the proxy does not have a
method for obtaining a better location.
AN-23/SP-21 Default locations MUST be marked with method=Default and AN-23/SP-21 Default locations MUST be marked with method=Default and
an appropriate provided-by in the PIDF-LO. an appropriate provided-by in the PIDF-LO.
6.12. Other location considerations 6.12. Other location considerations
ED-39 If the LCP does not return location in the form of a PIDF-LO ED-39 If the LCP does not return location in the form of a PIDF-LO
[RFC4119], the endpoint MUST map the location information it receives [RFC4119], the endpoint MUST map the location information it receives
from the configuration protocol to a PIDF-LO. from the configuration protocol to a PIDF-LO.
ED-40/AN-24 To prevent against spoofing of the DHCP server, elements ED-40/AN-24 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].
ED-41 S/MIME MUST NOT be used to protect the Geolocation header or ED-41 S/MIME MUST NOT be used to encrypt the SIP Geolocation header
bodies. or bodies.
ED-42/SP-22 TLS MUST be used to protect location (but see Section 9). ED-42/SP-22 TLS MUST be used to protect location (but see
Section 9.1). IPSEC [RFC2401] is an acceptable alternative.
6.13. LIS and LoST Discovery
ED-xx Endpoints MUST support one or more mechanisms that allow them
to determine their public IP address. Examples include ICE
[I-D.ietf-mmusic-ice] and HTTP get.
ED-xx Endpoints MUST support LIS discovery as described in
[I-D.thomson-geopriv-lis-discovery], and the LoST discovery as
described in [I-D.ietf-ecrit-dhc-lost-discovery].
ED-xx The device MUST have a configurable default LoST server
parameter. If the device is provided by or managed by service
provider, it is expected that the service provider will configure
this option.
7. Uninitialized devices 7. Uninitialized devices
ED-43 Uninitialized devices SHOULD NOT lead a user to believe an ED-43 Uninitialized devices SHOULD NOT lead a user to believe an
emergency call could be placed on it unless local regulations require emergency call could be placed on it unless local regulations require
it. it.
ED-44/AN-25/SP-23 Uninitialized devices SHOULD NOT be capable of ED-44/AN-25/SP-23 Uninitialized devices SHOULD NOT be capable of
placing an emergency call unless local regulations require it. placing an emergency call unless local regulations require it.
ED-45/AN-26/SP-24 Uninitialized devices that can place emergency ED-45/AN-26/SP-24 Uninitialized devices that can place emergency
calls MUST supply location the same as a fully capable device would. calls MUST supply location the same as a fully capable device would.
ED-46/SP-25 Unitialized Devices MUST supply a call back URI. See ED-46/SP-25 Unitialized devices MUST supply a call back URI. See
Section 7. Section 7.
ED-47/SP-26 Unitialized Devices MUST include identifiers in the ED-47/SP-26 Unitialized devices MUST include identifiers in the
signaling that can be used by the service provider to identify the signaling that can be used by the service provider to identify the
device and to allow filtering of calls from the device by the PSAP/ device and to allow filtering of calls from the device by the PSAP/
ESRP. ESRP.
8. Routing the call to the PSAP 8. Routing the call to the PSAP
ED-48 Endpoints who obtain their own location SHOULD perform LoST ED-48 Endpoints who obtain their own location SHOULD perform LoST
mapping to the PSAP URI. mapping to the PSAP URI.
ED-49 Mapping SHOULD be performed at boot time and whenever location ED-49 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 use. expired. The value MUST be cached for possible later use.
ED-50 The endpoint SHOULD attempt to update its location at the time ED-50 The endpoint MUST attempt to update its location at the time of
of an emergency call. If it cannot obtain a new location quickly an emergency call. If it cannot obtain a new location quickly (see
(See Section 6), it MUST use the cached value. Section 6), it MUST use the cached value.
ED-51 The endpoint SHOULD attempt to update the LoST mapping at the ED-51 The endpoint SHOULD attempt to update the LoST mapping at the
time of an emergency call. If it cannot obtain a new mapping time of an emergency call. If it cannot obtain a new mapping
quickly, it MUST use the cached value. quickly, it MUST use the cached value.
SP-27 All proxies in the outbound path SHOULD recognize emergency SP-27 All proxies in the outbound path SHOULD recognize emergency
calls with a Request URI of the service URN in the "sos" tree. An 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 places a service URN in the Request URI to indicate that the
endpoint understood the call was an emergency call. A proxy that endpoint understood the call was an emergency call. A proxy that
processes such a call looks for the presence of a Route header with a processes such a call looks for the presence of a SIP Route header
URI of a PSAP. Absence of such a Route header indicates the UAC was field with a URI of a PSAP. Absence of such a Route header indicates
unable to invoke LoST and the proxy MUST perform the LoST mapping and the UAC was unable to invoke LoST and the proxy MUST perform the LoST
insert a Route header with the URI obtained. mapping and insert a Route header field with the URI obtained.
SP-28 To deal with old user agents that predate this specification SP-28 To deal with old user agents that predate this specification
and with UAs that do not have access to their own location data, and with UAs that do not have access to their own location data, a
proxies that recognize a call as an emergency call that is not marked 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 as such (see Section 5) MUST also perform this mapping, with the best
location it has available for the endpoint. The resulting PSAP URI location it has available for the endpoint. The resulting PSAP URI
would become the Request URI. would be placed in a Route header with the service URN in the Request
URI.
SP-29 Proxy servers performing mapping SHOULD use location obtained SP-29 Proxy servers performing mapping SHOULD use location obtained
from the access network for the mapping. If no location is from the access network for the mapping. If no location is
available, a default location (see Section 6.11) MUST be supplied. available, a default location (see Section 6.11) MUST be supplied.
SP-30 A proxy server which attempts mapping and fails to get a SP-30 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-52/SP-31 [RFC3261] and [RFC3263] procedures MUST be used to route ED-52/SP-31 [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-53 Initial INVITES MUST provide an Offer [RFC3264]. ED-53 Initial INVITES MUST provide an Offer [RFC3264].
9. Signaling of emergency calls 9. Signaling of emergency calls
ED-54 Best Current Practice for SIP user agents including handling of ED-54 Best Current Practice for SIP user agents [RFC4504] including
audio, video and real-time text [RFC4103] SHOULD be applied. This handling of audio, video and real-time text [RFC4103] MUST be
memo can be considered as an addition to it for endpoints. applied. This memo can be considered as an addition to [RFC4504] for
endpoints.
9.1. Use of TLS 9.1. Use of TLS
ED-55/SP-32 sips: MUST be specified when attempting to signal an ED-55/SP-32 TLS MUST be specified when attempting to signal an
emergency call with SIP. emergency call with SIP per [I-D.ietf-sip-sips]. IPSEC [RFC2401] is
an acceptable alternative.
ED-56/SP-33 If TLS session establishment fails, the call MUST be ED-56/SP-33 If TLS session establishment fails, the call MUST be
retried with sip:. retried without TLS.
ED-57/SP-34 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain ED-57/SP-34 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain
persistent TLS connections between elements. persistent TLS connections between elements.
ED-58/AN-27 https: MUST be specified when attempting to retrieve ED-58/AN-27 TLS MUST be specified when attempting to retrieve
location (configuration or dereferencing) with HELD. location (configuration or dereferencing) with HELD. The use of
[RFC4507] is RECOMMENDED to minimise the time to establish TLS
sessions.
ED-59/AN33 If TLS session establishment fails, the location ED-59/AN33 If TLS session establishment fails, the location
retrieveal MUST be retried with http:. retrieveal MUST be retried without TLS.
9.2. SIP signaling requirements for User Agents 9.2. SIP signaling requirements for User Agents
ED-60 The initial SIP signaling Method is an INVITE: ED-60 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 do local dial string interpretation, the the device cannot interpert local dial strings, the Request-URI
Request-URI SHOULD be a dialstring URI [RFC4967] with the dialed SHOULD be a dial string URI [RFC4967] with the dialed digits.
digits. 2. The To header SHOULD be a service URN in the "sos" tree. If the
2. The To: header MUST be present and SHOULD be a service URN in device cannot do interpret local dial strings, the To: SHOULD be
the "sos" tree. If the device cannot do local dial string a dial string URI with the dialed digits.
interpretation, the To: SHOULD be a dialstring URI with the 3. The From header MUST be present and SHOULD be the AoR of the
dialed digits.
3. The From: header MUST be present and SHOULD be the AoR of the
caller. caller.
4. A Via: header MUST be present and SHOULD include the URI of the 4. A Via header MUST be present and SHOULD include the URI of the
device. device.
5. A Route: header SHOULD be present with a PSAP URI obtained from 5. A Route header SHOULD be present with a PSAP URI obtained from
LoST (see Section 8) and the loose route parameter. A sips URI LoST (see Section 8) and the loose route parameter. If the
[RFC3261] SHOULD be specified, unless the operation must be device does not interpet dial plans, no Route header will be
retried due to a failure to establish a TLS connection. If the present.
device does not do dial plan interpretation, no Route: header
will be present.
6. A Contact header MUST be present which MUST be globally 6. A Contact header MUST be present which MUST be globally
routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an
immediate call-back to the specific device which placed the immediate call-back to the specific device which placed the
emergency call. emergency call.
7. Other headers MAY be included as per normal SIP behavior.
7. Other headers MAY be included as per normal sip behavior. 8. A Supported header 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 9. If a device understands the SIP location conveyance
[I-D.ietf-sip-location-conveyance] extension and has its [I-D.ietf-sip-location-conveyance] extension and has its
location available, it MUST include location either by- value or location available, it MUST include location either by- value or
by-reference. by-reference.
10. If a device understands the SIP Location Conveyance extension 10. If a device understands the SIP Location Conveyance extension
and has its location unavailable or unknown to that device, it and has its location unavailable or unknown to that device, it
MUST include a Supported header with a "geolocation" option tag, MUST include a Supported header with a "geolocation" option tag,
and MUST NOT include a Geolocation header, and not include a and MUST NOT include a Geolocation header, and not include a
PIDF-LO message body. PIDF-LO message body.
11. If a device understands the SIP Location Conveyance extension 11. If a device understands the SIP Location Conveyance extension
and supports LoST [I-D.ietf-ecrit-lost] then whichever location and supports LoST [I-D.ietf-ecrit-lost], the Geolocation "used-
is used for routing the message towards the PSAP or ESRP, even for-routing" header parameter MUST be added to the corresponding
if there is only one, the Geolocation "message-routed-on- this- URI in the Geolocation header.
uri" header parameter SHOULD be added to the corresponding URI 12. A normal SDP offer SHOULD be included in the INVITE. If voice
in the Geolocation header. is supported the offer MUST include the G.711 codec, see
12. A normal SDP offer SHOULD be included in the INVITE. The offer Section 14.
MUST include the G.711 codec, see Section 14.
13. If the device includes location-by-value, the UA MUST support 13. If the device includes location-by-value, the UA MUST support
multipart message bodies, since SDP will likely be also in the multipart message bodies, since SDP will likely be also in the
INVITE. INVITE.
14. A UAC SHOULD include a "inserted-by=endpoint" header parameter 14. A UAC SHOULD include a "inserted-by=endpoint" header parameter
on all Geolocation headers . This informs downstream elements on all Geolocation headers . This informs downstream elements
which device entered the location at this URI (either cid-URL or which device entered the location at this URI (either cid-URL or
location-by-reference URI). location-by-reference URI).
15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the
PSAP should handle the call. For example, a language preference PSAP should handle the call. For example, a language preference
expressed in an Accept-Language header may be used as a hint to 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 cause the PSAP to route the call to a call taker who speaks the
requested language. 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-35 SIP Proxy servers processing emergency calls: SP-35 SIP Proxy servers processing emergency calls:
1. If the proxy does dial plan interpretation on behalf of user 1. If the proxy does interprets dial plans on behalf of user agents,
agents, the proxy MUST look for the local emergency dialstring at the proxy MUST look for the local emergency dial string at the
the location of the end device and MAY look for the home location of the end device and MAY look for the home dial string.
dialstring. If it finds it, the proxy MUST: If it finds it, the proxy MUST:
* Insert a Geolocation header as per 10-12 above. Location-by- * Insert a Geolocation header as above. Location-by-reference
reference MUST be used because proxies may not insert bodies. MUST be used because proxies must not insert bodies.
* Include the Geolocation "inserted-by=server" AND "routed-by- * Include the Geolocation "inserted-by=server" and "used-for-
this-uri" parameters. routing" parameters.
* Map the location to a PSAP uri using LoST. * Map the location to a PSAP URI using LoST.
* Add a Route header with the PSAP URI.
* Add a Route header with the service URN appropriate for the
emergency dialstring.
* Replace the Request-URI (which was the dialstring) with the * Replace the Request-URI (which was the dialstring) with the
PSAP URI obtained from LoST. 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 Route header with a PSAP URI, it MUST run LoST does not find a Route header with a PSAP URI, it MUST run LoST
routing. If a location was provided (which should be the case), routing. If a location was provided (which should be the case),
the proxy uses that location to query LoST. The proxy may have the proxy uses that location to query LoST. The proxy may have
to dereference a location by reference to get a value. If a 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 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, 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 and the proxy does not have access to a LIS which could provide
location, the proxy MUST supply a default location (See location, the proxy MUST supply a default location (See
Section 6.11). The location (in the signaling, obtained from a 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 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 URN received with the call. The resulting URI MUST be placed in
a Route: header added to the call. 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: 4. The proxy SHOULD NOT modify any parameters in Geolocation headers
headers received in the call. It MAY add a Geolocation: header. received in the call. It MAY add a Geolocation header. Such an
Such an additional location SHOULD NOT be used for routing; the additional location SHOULD NOT be used for routing; the location
location provided by the UA should be used. 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, MUST be included to identify the sender. [RFC4474], or both, MUST be included to identify the sender.
10. Call backs 10. Call backs
SP-36 Unitialized devices MUST have a globally routable URI in a SP-36 Unitialized devices, like any device MUST have a globally
Contact: header. routable URI in a Contact: header.
SP-37 Unitialized devices SHOULD have a persistent URI in a SP-37 Unitialized devices SHOULD have a persistent URI in a
P-Asserted-Identity: header. P-Asserted-Identity: header if there is some way to assign such an
identifier to the device.
11. Mid-call behavior 11. Mid-call behavior
ED-61/SP-38 During the course of an emergency call, devices and ED-61/SP-38 During the course of an emergency call, devices and
proxies MUST support REFER transactions and the Referred-by: header proxies MUST support REFER transactions and the Referred-by: header
[RFC3515] to: [RFC3515].
1. Be REFERed to a conference bridge; PSAPs often include
dispatchers, responders or specialists on a call.
2. Be REFERed to a secondary PSAP. Some responder's dispatchers are
not located in the primary PSAP. The call may have to be
transferred to another PSAP. Most often this will be an attended
transfer, or a bridged transfer.(For devices that are Mobile).
ED-62/SP-39User agents and proxies MUST Support Session ED-62/SP-39 User agents and proxies MUST support Session Timer
Timer[RFC4028] to guard against session corruption. [RFC4028] to guard against session corruption.
12. Call termination 12. Call termination
ED-63 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT ED-63 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT
generate a BYE request (or equivalent for other non-SIP signaling). generate a BYE request (or equivalent for other non-SIP signaling).
The PSAP must be the only entity that can terminate a call. If the The PSAP must be the only entity that can terminate a call. If the
user "hangs up" an emergency call, the device should alert, and when user "hangs up" an emergency call, the device should alert the user,
answered, reconnect the caller to the PSAP. and when answered, reconnect the caller to the PSAP.
ED-64 There can be a case where the session signaling path is lost, ED-64 There can be a case where the session signaling path is lost,
and the user agent does not receive the BYE. If the call is hung up, and the user agent does not receive the BYE. If the call is hung up,
and the session timer expires the call MAY be declared lost. If in and the session timer expires the call MAY be declared lost. If in
the interval, an incoming call is received from the domain of the the interval, an incoming call is received from the domain of the
PSAP, the device SHOULD drop the old call and alert for the (new) PSAP, the device SHOULD drop the old call and alert for the (new)
incoming call. Dropping of the old call SHOULD only occur if the incoming call. Dropping of the old call SHOULD only occur if the
user is attempting to hang up; the domain of an incoming call can 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 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 could be spoofed. Dropping an active call by a new call with a
spoofed From: would be a DoS attack. spoofed From: would be a DoS attack.
13. Disabling of features 13. Disabling of features
ED-65/SP-40 User Agents and proxys MUST disable outgoing call ED-65/SP-40 User Agents and proxys MUST disable outgoing call
features such as: features such as
o Call Waiting o Call Waiting
o Call Transfer o Call Transfer
o Three Way Call o Three Way Call
o Flash hold o Flash hold
o Outbound Call Blocking o Outbound Call Blocking
when an emergency call is established. when an emergency call is established. Also see ED-72 in Section 14.
ED-66/SP-41 The emergency dialstrings SHOULD NOT be permitted in Call ED-66/SP-41 The emergency dialstrings SHOULD NOT be permitted in Call
Forward numbers or speed dial lists. Forward numbers or speed dial lists.
ED-67/SP-42 The User Agent and Proxies SHOULD disable the following ED-67/SP-42 The User Agent and Proxies SHOULD disable the following
incoming call features on call backs from the PSAP: incoming call features on call backs from the PSAP:
o Call Waiting o Call Waiting
o Do Not Disturb o Do Not Disturb
o Call Forward (all kinds) o Call Forward (all kinds)
skipping to change at page 16, line 15 skipping to change at page 17, line 40
to be a call back. The suggested timer period is 5 minutes. to be a call back. The suggested timer period is 5 minutes.
14. Media 14. Media
ED-69 Endpoints MUST send and receive media streams on RTP [RFC3550]. ED-69 Endpoints MUST send and receive media streams on RTP [RFC3550].
ED-70 Normal SIP offer/answer [RFC3264] negotiations MUST be used to ED-70 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-71 Endpoints supporting voice MUST support G.711 A law (and mu Law ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law
in North America) encoded voice as described in [RFC3551]. It is if they could be used in North America) encoded voice as described in
desirable to support wideband codecs in the offer. [RFC3551]. It is desirable to include wideband codecs such as AMR-WB
in the offer.
ED-72 Silence suppression (Voice Activity Detection methods) MUST NOT ED-72 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-73 Endpoints supporting IM MUST support either [RFC3428] or ED-73 Endpoints supporting IM MUST support either [RFC3428] or
[RFC3920]. [RFC3920].
ED-74 Endpoints supporting real-time text MUST use [RFC4103]. The ED-74 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 [I-D.ietf-sipping-toip], section 7.1 SHOULD be medium, described in [I-D.ietf-sipping-toip], Section 7.1 SHOULD be
fulfilled. fulfilled.
ED-75 Endpoints supporting video MUST support H.264 per [RFC3984]. ED-75 Endpoints supporting video MUST support H.264 per [RFC3984].
15. Testing 15. Testing
ED-76 INVITE requests to a service urn with a urn parameter of "test" ED-76 INVITE requests to a service URN with a urn parameter of "test"
indicates a request for an automated test. For example, indicates a request for an automated test. For example,
"urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response "urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response
indicates that the address was recognized and a 404 (Not found) that indicates that the address was recognized and a 404 (Not found) that
it was not. A 486 (Busy Here) MUST be returned if the test service it was not. A 486 (Busy Here) MUST be returned if the test service
is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP
does not support the test mechanism. does not support the test mechanism.
ED-77 In its response to the test, the PSAP MAY include a text body ED-77 In its response to the test, the PSAP MAY include a text body
(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,
skipping to change at page 17, line 19 skipping to change at page 18, line 44
ED-78 A PSAP accepting a test call SHOULD accept a media loopback ED-78 A PSAP accepting a test call SHOULD accept a media loopback
test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 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-79 User agents SHOULD perform a full call test, including media ED-79 User agents SHOULD perform a full call test, including media
loopback, after a disconnect and subsequent change in IP address. loopback, after a disconnect and subsequent change in IP address not
After an initial IP address assignment 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-80 User agents MUST NOT place a test call immediately after ED-80 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-81 PSAPs MAY refuse repeated requests for test from the same ED-81 PSAPs MAY refuse repeated requests for test from the same
device in a short period of time. Any refusal is signaled with a 486 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
draft-ietf-ecrit-security- threats, and the forthcoming GEOPRIV [I-D.ietf-ecrit-security-threats], and [I-D.barnes-geopriv-lo-sec].
security document(s).
Ed. Note: go through that doc and make sure any actions needed are
captured in the BCP text.
17. Acknowledgements 17. Acknowledgements
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,
Roger Marshall, Barbara Stark, Richard Barnes and Peter Blatherwick. Barbara Stark, Richard Barnes and Peter Blatherwick.
18. Normative References 18. Normative References
[I-D.barnes-geopriv-lo-sec]
Barnes, R., "Threats to GEOPRIV Location Objects",
draft-barnes-geopriv-lo-sec-00 (work in progress),
July 2007.
[I-D.ietf-ecrit-dhc-lost-discovery]
Schulzrinne, H., "A Dynamic Host Configuration Protocol
(DHCP) based Location-to-Service Translation Protocol
(LoST) Discovery Procedure",
draft-ietf-ecrit-dhc-lost-discovery-02 (work in progress),
July 2007.
[I-D.ietf-ecrit-framework] [I-D.ietf-ecrit-framework]
Rosen, B., "Framework for Emergency Calling using Internet Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
Multimedia", draft-ietf-ecrit-framework-02 (work in "Framework for Emergency Calling using Internet
progress), July 2007. Multimedia", draft-ietf-ecrit-framework-03 (work in
progress), September 2007.
[I-D.ietf-ecrit-lost] [I-D.ietf-ecrit-lost]
Hardie, T., "LoST: A Location-to-Service Translation Hardie, T., "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-06 (work in progress), Protocol", draft-ietf-ecrit-lost-06 (work in progress),
August 2007. August 2007.
[I-D.ietf-ecrit-requirements] [I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
skipping to change at page 18, line 36 skipping to change at page 20, line 19
draft-ietf-ecrit-security-threats-05 (work in progress), draft-ietf-ecrit-security-threats-05 (work in progress),
August 2007. August 2007.
[I-D.ietf-ecrit-service-urn] [I-D.ietf-ecrit-service-urn]
Schulzrinne, H., "A Uniform Resource Name (URN) for Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", Emergency and Other Well-Known Services",
draft-ietf-ecrit-service-urn-07 (work in progress), draft-ietf-ecrit-service-urn-07 (work in progress),
August 2007. August 2007.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., "HTTP Enabled Location Delivery (HELD)", Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
draft-ietf-geopriv-http-location-delivery-01 (work in "HTTP Enabled Location Delivery (HELD)",
progress), July 2007. draft-ietf-geopriv-http-location-delivery-03 (work in
progress), November 2007.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Considerations and Recommendations", PIDF-LO Usage Clarification, Considerations and
draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), Recommendations", draft-ietf-geopriv-pdif-lo-profile-10
July 2007. (work in progress), October 2007.
[I-D.ietf-geopriv-revised-civic-lo] [I-D.ietf-geopriv-revised-civic-lo]
Thomson, M. and J. Winterbottom, "Revised Civic Location Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for PIDF-LO", Format for PIDF-LO",
draft-ietf-geopriv-revised-civic-lo-05 (work in progress), draft-ietf-geopriv-revised-civic-lo-06 (work in progress),
February 2007. October 2007.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Hedayat, K., "An Extension to the Session Description Hedayat, K., "An Extension to the Session Description
Protocol (SDP) for Media Loopback", Protocol (SDP) for Media Loopback",
draft-ietf-mmusic-media-loopback-06 (work in progress), draft-ietf-mmusic-media-loopback-07 (work in progress),
April 2007. November 2007.
[I-D.ietf-sip-connected-identity] [I-D.ietf-sip-connected-identity]
Elwell, J., "Connected Identity in the Session Initiation Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", draft-ietf-sip-connected-identity-05 Protocol (SIP)", draft-ietf-sip-connected-identity-05
(work in progress), February 2007. (work in progress), February 2007.
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-14 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
June 2007. October 2007.
[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-08 (work in progress), draft-ietf-sip-location-conveyance-08 (work in progress),
July 2007. July 2007.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-10 (work in progress), July 2007. draft-ietf-sip-outbound-10 (work in progress), July 2007.
[I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-07 (work
in progress), November 2007.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Petrie, D. and S. Channabasappa, "A Framework for Session Channabasappa, S., "A Framework for Session Initiation
Initiation Protocol User Agent Profile Delivery", Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-12 (work in progress), draft-ietf-sipping-config-framework-14 (work in progress),
June 2007. November 2007.
[I-D.ietf-sipping-toip] [I-D.ietf-sipping-toip]
Wijk, A. and G. Gybels, "Framework for real-time text over Wijk, A. and G. Gybels, "Framework for real-time text over
IP using the Session Initiation Protocol (SIP)", IP using the Session Initiation Protocol (SIP)",
draft-ietf-sipping-toip-07 (work in progress), draft-ietf-sipping-toip-08 (work in progress),
August 2006. October 2007.
[I-D.thomson-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
draft-thomson-geopriv-lis-discovery-03 (work in progress),
September 2007.
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Dec 2004. Dec 2004.
[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".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001. RFC 3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
skipping to change at page 21, line 44 skipping to change at page 23, line 49
IP Telephony", RFC 4190, November 2005. IP Telephony", RFC 4190, November 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
Device Requirements and Configuration", RFC 4504, Device Requirements and Configuration", RFC 4504,
May 2006. May 2006.
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 4507, May 2006.
[RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4676, October 2006. Configuration Information", RFC 4676, October 2006.
[RFC4967] Rosen, B., "Dial String Parameter for the Session [RFC4967] Rosen, B., "Dial String Parameter for the Session
Initiation Protocol Uniform Resource Identifier", Initiation Protocol Uniform Resource Identifier",
RFC 4967, July 2007. RFC 4967, July 2007.
Appendix A. BCP Requirements Sorted by Responsible Party Appendix A. BCP Requirements Sorted by Responsible Party
skipping to change at page 23, line 22 skipping to change at page 25, line 30
of less than 100 m with 95% confidence SHOULD be available for of less than 100 m with 95% confidence SHOULD be available for
dispatch. dispatch.
ED-17 Devices that support endpoint measuring of location MUST have ED-17 Devices that support endpoint measuring of location MUST have
at least a coarse location (<1km) capability at all times for routing at least a coarse location (<1km) capability at all times for routing
of calls. This mechanism MAY be a service provided by the access of calls. This mechanism MAY be a service provided by the access
network. network.
ED-18 Endpoints SHOULD do location configuration themselves. ED-18 Endpoints SHOULD do location configuration themselves.
ED-19 Where proxies provide location on behalf of endpoints, the the
service provider MUST ensure that either the end device is provided
with the local dial strings for its current location (where the end
device recognizes dial strings), or that the service provider can
detect the appropriate local dial strings at the time of the call.
ED-20 Devices SHOULD be able to accept and forward location by value ED-20 Devices SHOULD be able to accept and forward location by value
or by reference. An end device that receives location by reference or by reference. An end device that receives location by reference
(and does not also get the corresponding value) MUST be able to (and does not also get the corresponding value) MUST be able to
perform a dereference operation to obtain a value. perform a dereference operation to obtain a value.
ED-21 endpoints MUST support all of: DHCP Location options [RFC4676] ED-21 endpoints MUST support all of: DHCP Location options [RFC4676]
and [RFC3825], HELD[I-D.ietf-geopriv-http-location-delivery] and and [RFC3825], HELD[I-D.ietf-geopriv-http-location-delivery] and
LLDP-MED[LLDP-MED]. LLDP-MED[LLDP-MED].
ED-22 Endpoints SHOULD try all LCPs supported by the device in any ED-22 Endpoints SHOULD try all LCPs supported by the device in any
skipping to change at page 23, line 43 skipping to change at page 26, line 8
location can be used. location can be used.
ED-23 Endpoints SHOULD obtain location immediately after obtaining ED-23 Endpoints SHOULD obtain location immediately after obtaining
local network configuration information. local network configuration information.
ED-24 To minimize the effects of non-bypassable VPNs, location ED-24 To minimize the effects of non-bypassable VPNs, location
configuration SHOULD be attempted before such tunnels are configuration SHOULD be attempted before such tunnels are
established. established.
ED-25 Software which uses LCPs SHOULD locate and use the actual ED-25 Software which uses LCPs SHOULD locate and use the actual
hardware network interface. hardware network interface rather than a VPN tunnel interface to
direct LCP requests to the LIS in the actual access network.
ED-26 For devices which are not expected to roam, refreshing on the ED-26 For devices which are not expected to roam, refreshing on the
order of once per day is RECOMMENDED order of once per day is RECOMMENDED
ED-27 For devices which roam, refresh of location SHOULD be more ED-27 For devices which roam, refresh of location SHOULD be more
frequent, with the frequency related to the mobility of the device frequent, with the frequency related to the mobility of the device
and the ability of the access network to support the refresh and the ability of the access network to support the refresh
operation. There can be instances in which a device is aware of when operation. There can be instances in which a device is aware of when
it moves, for example when it changes access points. When this type it moves, for example when it changes access points. When this type
of event occurs, the device SHOULD refresh its location. of event occurs, the device SHOULD refresh its location.
skipping to change at page 24, line 16 skipping to change at page 26, line 31
ED-28 It is RECOMMENDED that location determination not take longer ED-28 It is RECOMMENDED that location determination not take longer
than 250 ms to obtain routing location and systems SHOULD be designed than 250 ms to obtain routing location and systems SHOULD be designed
such that the typical response is under 100ms. However, as much as 3 such that the typical response is under 100ms. However, as much as 3
seconds to obtain routing location MAY be tolerated if location seconds to obtain routing location MAY be tolerated if location
accuracy can be substantially improved over what can be obtained in accuracy can be substantially improved over what can be obtained in
250 ms. 250 ms.
ED-29 Location sent between SIP elements MUST be conveyed using ED-29 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sip-location-conveyance]. [I-D.ietf-sip-location-conveyance].
ED-30 Where the absolute location, or the accuracy of location of the ED-30 Where the absolute location or the accuracy of location of the
endpoint may change between the time the call is received at the PSAP endpoint may change between the time the call is received at the PSAP
and the time dispatch is completed, location update mechanisms MUST and the time dispatch is completed, location update mechanisms MUST
be provided. be provided.
ED-31 mobile devices MUST be provided with a mechanism to get ED-31 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-32 The LIS SHOULD provide a location reference which permits a ED-32 The LIS SHOULD provide a location reference which permits a
subscription with appropriate filtering. subscription with appropriate filtering.
skipping to change at page 25, line 17 skipping to change at page 27, line 32
ED-39 If the LCP does not return location in the form of a PIDF-LO ED-39 If the LCP does not return location in the form of a PIDF-LO
[RFC4119], the endpoint MUST map the location information it receives [RFC4119], the endpoint MUST map the location information it receives
from the configuration protocol to a PIDF-LO. from the configuration protocol to a PIDF-LO.
ED-40 To prevent against spoofing of the DHCP server, elements ED-40 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].
ED-41 S/MIME MUST NOT be used to protect the Geolocation header or ED-41 S/MIME MUST NOT be used to protect the Geolocation header or
bodies. bodies.
ED-42 TLS MUST be used to protect location (but see Section 9). ED-42 TLS MUST be used to protect location (but see Section 9.1).
ED-43 Uninitialized devices SHOULD NOT lead a user to believe an ED-43 Uninitialized devices SHOULD NOT lead a user to believe an
emergency call could be placed on it unless local regulations require emergency call could be placed on it unless local regulations require
it. it.
ED-44 Uninitialized devices SHOULD NOT be capable of placing an ED-44 Uninitialized devices SHOULD NOT be capable of placing an
emergency call unless local regulations require it. emergency call unless local regulations require it.
ED-45 Uninitialized devices that can place emergency calls MUST ED-45 Uninitialized devices that can place emergency calls MUST
supply location the same as a fully capable device would. supply location the same as a fully capable device would.
ED-46 Unitialized Devices MUST supply a call back URI. See Section 7 ED-46 Unitialized Devices MUST supply a call back URI. See Section 7
ED-47 Unitialized Devices MUST include identifiers in the signaling ED-47 Unitialized Devices MUST include identifiers in the signaling
that can be used by the service provider to identify the device and that can be used by the service provider to identify the device and
to allow filtering of calls from the device by the PSAP/ESRP. to allow filtering of calls from the device by the PSAP/ESRP.
ED-48 Endpoints who obtain their own location SHOULD perform LoST ED-48 Endpoints who obtain their own location SHOULD perform LoST
mapping to the PSAP URI. mapping to the PSAP URI whenever they get an initial or updated
location.
ED-49 Mapping SHOULD be performed at boot time and whenever location ED-49 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 use. expired. The value MUST be cached for possible use.
ED-50 The endpoint SHOULD attempt to update its location at the time ED-50 The endpoint MUST attempt to update its location at the time of
of an emergency call. If it cannot obtain a new location quickly an emergency call. If it cannot obtain a new location quickly (See
(See Section 6), it MUST use the cached value. Section 6), it MUST use the cached value.
ED-51 The endpoint SHOULD attempt to update the LoST mapping at the ED-51 The endpoint SHOULD attempt to update the LoST mapping at the
time of an emergency call. If it cannot obtain a new mapping time of an emergency call. If it cannot obtain a new mapping
quickly, it MUST use the cached value. quickly, it MUST use the cached value.
ED-52 [RFC3261] and [RFC3263] procedures MUST be used to route an ED-52 [RFC3261] and [RFC3263] procedures MUST be used to route an
emergency call towards the PSAP's URI. emergency call towards the PSAP's URI.
ED-53 Initial INVITES MUST provide an Offer [RFC3264] ED-53 Initial INVITES MUST provide an Offer [RFC3264]
ED-54 Best Current Practice for SIP user agents including handling of ED-54 Best Current Practice for SIP user agents [RFC4504] including
audio, video and real-time text [RFC4103] SHOULD be applied. This handling of audio, video and real-time text [RFC4103] SHOULD be
memo can be considered as an addition to it for endpoints. applied. This memo can be considered as an addition to [RFC4504] for
endpoints.
ED-55 sips: MUST be specified when attempting to signal an emergency ED-55 TLS MUST be specified when attempting to signal an emergency
call with SIP call with SIP per [I-D.ietf-sip-sips]. IPSEC [RFC2401] is an
acceptable alternative.
ED-56 If TLS session establishment fails, the call MUST be retried ED-56 If TLS session establishment fails, the call MUST be retried
with sip: with sip:
ED-57 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent ED-57 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent
TLS connections between elements TLS connections between elements
ED-58 https: MUST be specified when attempting to retrieve location ED-58 https: MUST be specified when attempting to retrieve location
(configuration or dereferencing) with HELD (configuration or dereferencing) with HELD. The use of [RFC4507] is
RECOMMENDED to minimise the time to establish TLS sessions.
ED-59 If TLS session establishment fails, the location retrieveal ED-59 If TLS session establishment fails, the location retrieveal
MUST be retried with http: MUST be retried with http:
ED-60 The initial SIP signaling Method is an INVITE: ED-60 The initial SIP signaling Method is an INVITE:
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 do local dialstring interpretation, the the device cannot do local dialstring interpretation, the
Request-URI SHOULD be a dialstring URI [RFC4967] with the dialed Request-URI SHOULD be a dialstring URI [RFC4967] with the dialed
digits. digits.
2. The To: header MUST be present and SHOULD be a service URN in 2. The To: header MUST be present and SHOULD be a service URN in
the "sos" tree. If the device cannot do local dialstring the "sos" tree. If the device cannot do local dialstring
interpretation, the To: SHOULD be a dialstring URI with the interpretation, the To: SHOULD be a dialstring URI with the
dialed digits. dialed digits.
3. The From: header MUST be present and SHOULD be the AoR of the 3. The From: header MUST be present and SHOULD be the AoR of the
caller. caller.
4. A Via: header MUST be present and SHOULD include the URI of the 4. A Via: header MUST be present and SHOULD include the URI of the
device. device.
5. A Route: header SHOULD be present with a PSAP URI obtained from 5. A Route: header SHOULD be present with a PSAP URI obtained from
LoST (see Section 8 ) and the loose route parameter. A sips URI LoST (see Section 8 ) and the loose route parameter. A sips URI
skipping to change at page 27, line 21 skipping to change at page 29, line 39
location available, it MUST include location either by- value or location available, it MUST include location either by- value or
by-reference. by-reference.
10. If a device understands the SIP Location Conveyance extension 10. If a device understands the SIP Location Conveyance extension
and has its location unavailable or unknown to that device, it and has its location unavailable or unknown to that device, it
MUST include a Supported header with a "geolocation" option tag, MUST include a Supported header with a "geolocation" option tag,
and MUST NOT include a Geolocation header, and not include a and MUST NOT include a Geolocation header, and not include a
PIDF-LO message body. PIDF-LO message body.
11. If a device understands the SIP Location Conveyance extension 11. If a device understands the SIP Location Conveyance extension
and supports LoST [I-D.ietf-ecrit-lost] then whichever location and supports LoST [I-D.ietf-ecrit-lost] then whichever location
is used for routing the message towards the PSAP or ESRP, even is used for routing the message towards the PSAP or ESRP, even
if there is only one, the Geolocation "message-routed-on- this- if there is only one, the Geolocation "used-for-routing" header
uri" header parameter SHOULD be added to the corresponding URI parameter SHOULD be added to the corresponding URI in the
in the Geolocation header. Geolocation header.
12. A normal SDP offer SHOULD be included in the INVITE. The offer 12. A normal SDP offer SHOULD be included in the INVITE. If voice
MUST include the G.711 codec, see Section 14. is supported the offer MUST include the G.711 codec, see
Section 14.
13. If the device includes location-by-value, the UA MUST support 13. If the device includes location-by-value, the UA MUST support
multipart message bodies, since SDP will likely be also in the multipart message bodies, since SDP will likely be also in the
INVITE. INVITE.
14. A UAC SHOULD include a "inserted-by=endpoint" header parameter 14. A UAC SHOULD include a "inserted-by=endpoint" header parameter
on all Geolocation headers . This informs downstream elements on all Geolocation headers . This informs downstream elements
which device entered the location at this URI (either cid-URL or which device entered the location at this URI (either cid-URL or
location-by-reference URI). location-by-reference URI).
15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the
PSAP should handle the call. For example, a language preference PSAP should handle the call.
expressed in an Accept-Language header may be used as a hint to
cause the PSAP to route the call to a call taker who speaks the
requested language.
ED-61 During the course of an emergency call, devices and proxies ED-61 During the course of an emergency call, devices and proxies
MUST support REFER transactions and the Referred-by: header [RFC3515] MUST support REFER transactions and the Referred-by: header
to: [RFC3515].
1. Be REFERed to a conference bridge; PSAPs often include
dispatchers, responders or specialists on a call.
2. Be REFERed to a secondary PSAP. Some responder's dispatchers are
not located in the primary PSAP. The call may have to be
transferred to another PSAP. Most often this will be an attended
transfer, or a bridged transfer.(For devices that are Mobile).
ED-62 User agents and proxies MUST Support Session Timer [RFC4028] to ED-62 User agents and proxies MUST Support Session Timer [RFC4028] to
guard against session corruption. guard against session corruption.
ED-63 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT ED-63 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT
generate a BYE request (or equivalent for other non-SIP signaling). generate a BYE request (or equivalent for other non-SIP signaling).
The PSAP must be the only entity that can terminate a call. If the The PSAP must be the only entity that can terminate a call. If the
user "hangs up" an emergency call, the device should alert, and when user "hangs up" an emergency call, the device should alert, and when
answered, reconnect the caller to the PSAP. answered, reconnect the caller to the PSAP.
skipping to change at page 28, line 27 skipping to change at page 30, line 39
could be spoofed. Dropping an active call by a new call with a could be spoofed. Dropping an active call by a new call with a
spoofed From: would be a DoS attack. spoofed From: would be a DoS attack.
ED-65 User Agents and proxys MUST disable outgoing call features such ED-65 User Agents and proxys MUST disable outgoing call features such
as: as:
o Call Waiting o Call Waiting
o Call Transfer o Call Transfer
o Three Way Call o Three Way Call
o Flash hold o Flash hold
o Outbound Call Blocking o Outbound Call Blocking
when an emergency call is established. when an emergency call is established. Also see ED-72 in Section 14.
ED-66 The emergency dialstrings SHOULD NOT be permitted in Call ED-66 The emergency dialstrings SHOULD NOT be permitted in Call
Forward numbers or speed dial lists. Forward numbers or speed dial lists.
ED-67 The User Agent and Proxies SHOULD disable the following ED-67 The User Agent and Proxies SHOULD disable the following
incoming call features on call backs from the PSAP: incoming call features on call backs from the PSAP:
o Call Waiting o Call Waiting
o Do Not Disturb o Do Not Disturb
o Call Forward (all kinds) o Call Forward (all kinds)
skipping to change at page 29, line 51 skipping to change at page 32, line 14
ED-78 A PSAP accepting a test call SHOULD accept a media loopback ED-78 A PSAP accepting a test call SHOULD accept a media loopback
test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- 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-79 User agents SHOULD perform a full call test, including media ED-79 User agents SHOULD perform a full call test, including media
loopback, after a disconnect and subsequent change in IP address. loopback, after a disconnect and subsequent change in IP address not
due to a reboot. After an initial IP address assignment test, a full
After an initial IP address assignment test, a full test SHOULD be test SHOULD be repeated approximately every 30 days with a random
repeated approximately every 30 days with a random interval. interval.
ED-80 User agents MUST NOT place a test call immediately after ED-80 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-81 PSAPs MAY refuse repeated requests for test from the same ED-81 PSAPs MAY refuse repeated requests for test from the same
device in a short period of time. Any refusal is signaled with a 486 device in a short period of time. Any refusal is signaled with a 486
or 488 response. or 488 response.
skipping to change at page 31, line 14 skipping to change at page 33, line 24
SP-12 Proxies MAY provide location on behalf of devices it supports SP-12 Proxies MAY provide location on behalf of devices it supports
if: if:
o It has a relationship with all access networks the device could o It has a relationship with all access networks the device could
connect to, and the relationship allows it to obtain location. connect to, and the relationship allows it to obtain location.
o It has an identifier that can be used by the access network to o It has an identifier that can be used by the access network to
determine the location of the endpoint, particularly in the determine the location of the endpoint, particularly in the
presence of NAT and VPN tunnels that may exist between the access presence of NAT and VPN tunnels that may exist between the access
network and the service provider. network and the service provider.
SP-13 Where proxies provide location on behalf of endpoints, the SP-13 Where proxies provide location on behalf of endpoints, the the
proxy MUST provide a mechanism to supply emergency dia lstrings to service provider MUST ensure that either the end device is provided
the device if the device recognizes them, or the proxy MUST track the with the local dial strings for its current location (where the end
location of the device with sufficient accuracy and timeliness to be device recognizes dial strings), or that the service provider can
able to recognize the local dial string at the time of an emergency detect the appropriate local dial strings at the time of the call.
call.
SP-14 Location sent between SIP elements MUST be conveyed using SP-14 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sip-location-conveyance]. [I-D.ietf-sip-location-conveyance].
SP-15 If a proxy inserts location on behalf of an endpoint, and it SP-15 If a proxy inserts location on behalf of an endpoint, and it
has multiple locations available for the endpoint it MUST choose one 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.
SP-16 If a proxy is attempting to assert location but the UA conveyed SP-16 If a proxy is attempting to assert location but the UA conveyed
a location to it, the proxy must use the UA?s location for routing a location to it, the proxy must use the UA?s location for routing
skipping to change at page 31, line 51 skipping to change at page 34, line 11
SP-19 The "used-for-routing" parameter MUST be set to the location SP-19 The "used-for-routing" parameter MUST be set to the location
that was used to query LoST. that was used to query LoST.
SP-20 Proxies handling emergency calls MUST insert a default location SP-20 Proxies handling emergency calls MUST insert a default location
if the call does not contain a location. if the call does not contain a location.
SP-21 Default locations MUST be marked with method=Default and an SP-21 Default locations MUST be marked with method=Default and an
appropriate provided-by in the PIDF-LO. appropriate provided-by in the PIDF-LO.
SP-22 TLS MUST be used to protect location (but see Section 9). SP-22 TLS MUST be used to protect location (but see Section 9.1).
IPSEC [RFC2401] is an acceptable alternative.
SP-23 Uninitialized devices SHOULD NOT be capable of placing an SP-23 Uninitialized devices SHOULD NOT be capable of placing an
emergency call unless local regulations require it. emergency call unless local regulations require it.
SP-24 Uninitialized devices that can place emergency calls MUST SP-24 Uninitialized devices that can place emergency calls MUST
supply location the same as a fully capable device would. supply location the same as a fully capable device would.
SP-25 Unitialized Devices MUST supply a call back URI. See Section 7 SP-25 Unitialized Devices MUST supply a call back URI. See Section 7
SP-26 Unitialized Devices MUST include identifiers in the signaling SP-26 Unitialized Devices MUST include identifiers in the signaling
skipping to change at page 32, line 31 skipping to change at page 34, line 40
processes such a call looks for the presence of a Route header with a processes such a call looks for the presence of a Route header with a
URI of a PSAP. Absence of such a Route header indicates the UAC was 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 unable to invoke LoST and the proxy MUST perform the LoST mapping and
insert a Route header with the URI obtained. insert a Route header with the URI obtained.
SP-28 To deal with old user agents that predate this specification SP-28 To deal with old user agents that predate this specification
and with UAs that do not have access to their own location data, and with UAs that do not have access to their own location data,
proxies that recognize a call as an emergency call that is not marked proxies that recognize a call as an emergency call that is not marked
as such (see Section 5) MUST also perform this mapping, with the best as such (see Section 5) MUST also perform this mapping, with the best
location it has available for the endpoint. The resulting PSAP URI location it has available for the endpoint. The resulting PSAP URI
would become the Request URI. would be placed in a Route header with the service URN in the Request
URI.
SP-29 Proxy servers performing mapping SHOULD use location obtained SP-29 Proxy servers performing mapping SHOULD use location obtained
from the access network for the mapping. If no location is from the access network for the mapping. If no location is
available, a default location (see Section 6.11) MUST be supplied. available, a default location (see Section 6.11) MUST be supplied.
SP-30 A proxy server which attempts mapping and fails to get a SP-30 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.
SP-31 [RFC3261] and [RFC3263] procedures MUST be used to route an SP-31 [RFC3261] and [RFC3263] procedures MUST be used to route an
emergency call towards the PSAP's URI. emergency call towards the PSAP's URI.
SP-32 sips: MUST be specified when attempting to signal an emergency SP-32 TLS MUST be specified when attempting to signal an emergency
call with SIP call with SIP per [I-D.ietf-sip-sips]. IPSEC [RFC2401] is an
acceptable alternative.
SP-33 If TLS session establishment fails, the call MUST be retried SP-33 If TLS session establishment fails, the call MUST be retried
with sip: with sip:
SP-34 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent SP-34 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent
TLS connections between elements TLS connections between elements
SP-35 SIP Proxy servers processing emergency calls: SP-35 SIP Proxy servers processing emergency calls:
1. If the proxy does dial plan interpretation on behalf of user 1. If the proxy does dial plan interpretation on behalf of user
agents, the proxy MUST look for the local emergency dialstring at agents, the proxy MUST look for the local emergency dial string
the location of the end device and MAY look for the home at the location of the end device and MAY look for the home dial
dialstring. If it finds it it MUST: string. If it finds it the proxy MUST:
* Insert a Geolocation header as per 10-12 above. Location-by- * Insert a Geolocation header as per 10-12 above. Location-by-
reference MUST be used because proxies may not insert bodies. reference MUST be used because proxies may not insert bodies.
* Include the Geolocation "inserted-by=server" AND "routed-by- * Include the Geolocation "inserted-by=server" AND "used-for-
this-uri" parameters. routing" parameters.
* Map the location to a PSAP uri using LoST. * Map the location to a PSAP uri using LoST.
* Add a Route header with the service URN appropriate for the * Add a Route header with the PSAP URI.
emergency dialstring.
* Replace the Request-URI (which was the dialstring) with the * Replace the Request-URI (which was the dialstring) with the
PSAP URI obtained from LoST. service URN appropriate for the emergency dialstring.
* 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 Route header with a PSAP URI, it MUST run LoST does not find a Route header with a PSAP URI, it MUST run LoST
routing. If a location was provided (which should be the case), routing. If a location was provided (which should be the case),
the proxy uses that location to query LoST. The proxy may have the proxy uses that location to query LoST. The proxy may have
to dereference a location by reference to get a value. If a 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 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, 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 and the proxy does not have access to a LIS which could provide
location, the proxy MUST supply a default location (See location, the proxy MUST supply a default location (See
Section 6.11). The location (in the signaling, obtained from a 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 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 URN received with the call. The resulting URI MUST be placed in
a Route: header added to the call. 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: 4. The proxy SHOULD NOT modify any parameters in Geolocation headers
headers received in the call. It MAY add a Geolocation: header. received in the call. It MAY add a Geolocation header. Such an
Such an additional location SHOULD NOT be used for routing; the additional location SHOULD NOT be used for routing; the location
location provided by the UA should be used. 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, MUST be included to identify the sender. [RFC4474], or both, MUST be included to identify the sender.
SP-36 Unitialized devices MUST have a globally routable URI in a SP-36 Unitialized devices MUST have a globally routable URI in a
Contact: header Contact header
SP-37 Unitialized devices SHOULD have a persistent URI in a SP-37 Unitialized devices SHOULD have a persistent URI in a
P-Asserted-Identity: header P-Asserted-Identity header
SP-38 During the course of an emergency call, devices and proxies SP-38 During the course of an emergency call, devices and proxies
MUST support REFER transactions and the Referred-by: header [RFC3515] MUST support REFER transactions and the Referred-by header [RFC3515].
to:
1. Be REFERed to a conference bridge; PSAPs often include
dispatchers, responders or specialists on a call.
2. Be REFERed to a secondary PSAP. Some responder's dispatchers are
not located in the primary PSAP. The call may have to be
transferred to another PSAP. Most often this will be an attended
transfer, or a bridged transfer.(For devices that are Mobile)
SP-39User agents and proxies MUST Support Session Timer [RFC4028] to SP-39User agents and proxies MUST Support Session Timer [RFC4028] to
guard against session corruption. guard against session corruption.
SP-40 User Agents and proxys MUST disable outgoing call features such SP-40 User Agents and proxys MUST disable outgoing call features such
as: as:
o Call Waiting o Call Waiting
o Call Transfer o Call Transfer
o Three Way Call o Three Way Call
o Flash hold o Flash hold
o Outbound Call Blocking o Outbound Call Blocking
when an emergency call is established. when an emergency call is established. Also see ED-72 in .
(Section 14)
SP-41 The emergency dialstrings SHOULD NOT be permitted in Call SP-41 The emergency dialstrings SHOULD NOT be permitted in Call
Forward numbers or speed dial lists. Forward numbers or speed dial lists.
SP-42 The User Agent and Proxies SHOULD disable the following SP-42 The User Agent and Proxies SHOULD disable the following
incoming call features on call backs from the PSAP: incoming call features on call backs from the PSAP:
o Call Waiting o Call Waiting
o Do Not Disturb o Do Not Disturb
o Call Forward (all kinds) o Call Forward (all kinds)
skipping to change at page 35, line 36 skipping to change at page 37, line 40
of calls. of calls.
AN-10 Access networks with range of <10M MUST provide a location to AN-10 Access networks with range of <10M MUST provide a location to
mobile devices connected to it. The location provided SHOULD be that mobile devices connected to it. The location provided SHOULD be that
of the beacon location unless a more accurate mechanism is provided. of the beacon location unless a more accurate mechanism is provided.
AN-11 The access network MUST support at least one of DHCP location AN-11 The access network MUST support at least one of DHCP location
options, HELD or LLDP-MED. options, HELD or LLDP-MED.
AN-12 Where a router is employed between a LAN and WAN in a small AN-12 Where a router is employed between a LAN and WAN in a small
(less than approximately 650m2), the LAN MUST reflect the location (less than approximately 650m2) area, the LAN MUST reflect the
provided by the WAN to the LAN. location provided by the WAN to the LAN. Where the area is larger,
the LAN MUST have a location configuration mechanism meeting this
BCP.
AN-13 Access networks that support more than one LCP MUST reply with AN-13 Access networks that support more than one LCP MUST reply with
the same location information (within the limits of the data format the same location information (within the limits of the data format
for the specific LCP) for all LCPs it supports. for the specific LCP) for all LCPs it supports.
AN-14 Network administrators MUST take care in assigning IP addresses AN-14 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.
AN-15 Placement of NAT devices should consider the effect of the NAT AN-15 Placement of NAT devices SHOULD consider the effect of the NAT
on the LCP. on the LCP.
AN-16 It is RECOMMENDED that location determination not take longer AN-16 It is RECOMMENDED that location determination not take longer
than 250 ms to obtain routing location and systems SHOULD be designed than 250 ms to obtain routing location and systems SHOULD be designed
such that the typical response is under 100ms. However, as much as 3 such that the typical response is under 100ms. However, as much as 3
seconds to obtain routing location MAY be tolerated if location seconds to obtain routing location MAY be tolerated if location
accuracy can be substantially improved over what can be obtained in accuracy can be substantially improved over what can be obtained in
250 ms. 250 ms.
AN-17 Where the absolute location, or the accuracy of location of the AN-17 Where the absolute location or the accuracy of location of the
endpoint may change between the time the call is received at the PSAP endpoint may change between the time the call is received at the PSAP
and the time dispatch is completed, location update mechanisms MUST and the time dispatch is completed, location update mechanisms MUST
be provided. be provided.
AN-18 mobile devices MUST be provided with a mechanism to get AN-18 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.
AN-19 The LIS SHOULD provide a location reference which permits a AN-19 The LIS SHOULD provide a location reference which permits a
subscription with appropriate filtering. subscription with appropriate filtering.
skipping to change at page 36, line 49 skipping to change at page 39, line 7
AN-24 To prevent against spoofing of the DHCP server, elements AN-24 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].
AN-25 Uninitialized devices SHOULD NOT be capable of placing an AN-25 Uninitialized devices SHOULD NOT be capable of placing an
emergency call unless local regulations require it. emergency call unless local regulations require it.
AN-26 Uninitialized devices that can place emergency calls MUST AN-26 Uninitialized devices that can place emergency calls MUST
supply location the same as a fully capable device would. supply location the same as a fully capable device would.
AN-27 https: MUST be specified when attempting to retrieve location AN-27 https: MUST be specified when attempting to retrieve location
(configuration or dereferencing) with HELD (configuration or dereferencing) with HELD. The use of [RFC4507] is
RECOMMENDED to minimise the time to establish TLS sessions.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar NeuStar
470 Conrad Dr. 470 Conrad Dr.
Mars, PA 16046 Mars, PA 16046
US US
Phone: +1 724 382 1051 Phone: +1 724 382 1051
Email: br@brianrosen.net Email: br@brianrosen.net
James M. Polk James Polk
Cisco Systems Cisco Systems
3913 Treemont Circle 3913 Treemont Circle
Colleyville, TX 76034 Colleyville, TX 76034
US US
Phone: +1-817-271-3552 Phone: +1-817-271-3552
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
Full Copyright Statement Full Copyright Statement
 End of changes. 152 change blocks. 
396 lines changed or deleted 504 lines changed or added

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