draft-ietf-ecrit-phonebcp-16.txt   draft-ietf-ecrit-phonebcp-17.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: BCP J. Polk Intended status: BCP J. Polk
Expires: April 28, 2011 Cisco Systems Expires: September 29, 2011 Cisco Systems
October 25, 2010 March 28, 2011
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-16 draft-ietf-ecrit-phonebcp-17
Abstract Abstract
The IETF and other standards organization have efforts targeted at The IETF and other standards organization have efforts targeted at
standardizing various aspects of placing emergency calls on IP standardizing various aspects of placing emergency calls on IP
networks. This memo describes best current practice on how devices, networks. This memo describes best current practice on how devices,
networks and services should use such standards to make emergency networks and services should use such standards to make emergency
calls. calls.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on September 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of how emergency calls are placed . . . . . . . . . . 3 3. Overview of how emergency calls are placed . . . . . . . . . . 4
4. Which devices and services should support emergency calls . . 4 4. Which devices and services should support emergency calls . . 5
5. Identifying an emergency call . . . . . . . . . . . . . . . . 4 5. Identifying an emergency call . . . . . . . . . . . . . . . . 5
6. Location and its role in an emergency call . . . . . . . . . . 5 6. Location and its role in an emergency call . . . . . . . . . . 6
6.1. Types of location information . . . . . . . . . . . . . . 5 6.1. Types of location information . . . . . . . . . . . . . . 6
6.2. Location Determination . . . . . . . . . . . . . . . . . . 6 6.2. Location Determination . . . . . . . . . . . . . . . . . . 7
6.2.1. User-entered location information . . . . . . . . . . 6 6.2.1. User-entered location information . . . . . . . . . . 7
6.2.2. Access network "wire database" location information . 6 6.2.2. Access network "wire database" location information . 7
6.2.3. End-system measured location information . . . . . . . 6 6.2.3. End-system measured location information . . . . . . . 7
6.2.4. Network-measured location information . . . . . . . . 7 6.2.4. Network-measured location information . . . . . . . . 8
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 7 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8
6.4. Location and references to location . . . . . . . . . . . 8 6.4. Location and references to location . . . . . . . . . . . 9
6.5. End system location configuration . . . . . . . . . . . . 8 6.5. End system location configuration . . . . . . . . . . . . 9
6.6. When location should be configured . . . . . . . . . . . . 9 6.6. When location should be configured . . . . . . . . . . . . 10
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 10 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 11
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 10 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12
6.10. Location validation . . . . . . . . . . . . . . . . . . . 11 6.10. Location validation . . . . . . . . . . . . . . . . . . . 12
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 13
6.12. Other location considerations . . . . . . . . . . . . . . 12 6.12. Other location considerations . . . . . . . . . . . . . . 13
7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 12 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 13 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 14 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. SIP signaling requirements for User Agents . . . . . . . . 14 9.2. SIP signaling requirements for User Agents . . . . . . . . 15
9.3. SIP signaling requirements for proxy servers . . . . . . . 15 9.3. SIP signaling requirements for proxy servers . . . . . . . 16
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 17 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 17 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 17 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
16. Security Considerations . . . . . . . . . . . . . . . . . . . 20 16. Security Considerations . . . . . . . . . . . . . . . . . . . 20
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 17.1. test service urn . . . . . . . . . . . . . . . . . . . . . 21
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 17.2. 'test' Subregistry . . . . . . . . . . . . . . . . . . . . 21
19.1. Normative References . . . . . . . . . . . . . . . . . . . 20 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
19.2. Informative References . . . . . . . . . . . . . . . . . . 23 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 19.1. Normative References . . . . . . . . . . . . . . . . . . . 21
19.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses terms from [RFC3261], [RFC5012] and This document uses terms from [RFC3261], [RFC5012] and
[I-D.ietf-ecrit-framework]. [I-D.ietf-ecrit-framework].
2. Introduction 2. Introduction
This document describes how access networks, Session Initiation This document describes how access networks, Session Initiation
Protocol [RFC3261] user agents, proxy servers and PSAPs support Protocol [RFC3261] user agents, proxy servers and Public Safety
emergency calling, as outlined in [I-D.ietf-ecrit-framework], which Access Points (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 (requirements prefaced BCP succinctly describes the requirements of end devices and
by "ED-"), access networks (including enterprise access networks) applications (requirements prefaced by "ED-"), access networks
(requirements prefaced by "AN-"), service providers (requirements (including enterprise access networks) (requirements prefaced by
prefaced by "SP-") and PSAPs to achieve globally interoperable "AN-"), service providers (requirements prefaced by "SP-") and PSAPs
emergency calling on the Internet. to achieve globally interoperable emergency calling on the Internet.
This document also defines requirements for "Intermediate" devices This document also defines requirements for "Intermediate" devices
which exist between end devices or applications and the access which exist between end devices or applications and the access
network. For example, a home router is an "Intermediate" device. network. For example, a home router is an "Intermediate" device.
Reporting location on an emergency call (see Section 6) may depend on Reporting location on an emergency call (see Section 6) may depend on
the ability of such intermediate devices to meet the requirements the ability of such intermediate devices to meet the requirements
prefaced by "INT-". prefaced by "INT-".
3. Overview of how emergency calls are placed 3. Overview of how emergency calls are placed
skipping to change at page 3, line 47 skipping to change at page 4, line 47
call by a unique Service URN [RFC5031], which is placed in the call call by a unique Service URN [RFC5031], which is placed in the call
set-up signaling when a home or visited emergency dial string is set-up signaling when a home or visited emergency dial string is
detected. Because emergency services are local to specific detected. Because emergency services are local to specific
geographic regions, a caller must obtain his location (Section 6) geographic regions, a caller must obtain his location (Section 6)
prior to making emergency calls. To get this location, either a form prior to making emergency calls. To get this location, either a form
of measuring (e.g., GPS) (Section 6.2.3) device location in the of measuring (e.g., GPS) (Section 6.2.3) device location in the
endpoint is deployed, or the endpoint is configured (Section 6.5) endpoint is deployed, or the endpoint is configured (Section 6.5)
with its location from the access network's Location Information with its location from the access network's Location Information
Server (LIS). The location is conveyed (Section 6.7) in the SIP Server (LIS). The location is conveyed (Section 6.7) in the SIP
signaling with the call. The call is routed (Section 8) based on signaling with the call. The call is routed (Section 8) based on
location using the LoST protocol [RFC5222], which maps a location to location using the Location-to-Service Translation (LoST) protocol
a set of PSAP URIs. Each URI resolves to a PSAP or an Emergency [RFC5222], which maps a location to a set of PSAP URIs. Each URI
Services Routing Proxy (ESRP), which serves a group of PSAPs. The resolves to a PSAP or an Emergency Services Routing Proxy (ESRP),
call arrives at the PSAP with the location included in the SIP INVITE which serves a group of PSAPs. The call arrives at the PSAP with the
request. location included in the SIP INVITE request.
4. Which devices and services should support emergency calls 4. Which devices and services should support emergency calls
ED-1 A device or application SHOULD support emergency calling if a ED-1 A device or application SHOULD support emergency calling if a
user could reasonably expect to be able to place a call for help with user could reasonably expect to be able to place a call for help with
the device. Some jurisdictions have regulations governing this. the device. Some jurisdictions have regulations governing this.
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 provider that supports it MUST facilitate for help, the service provider that supports it MUST facilitate
emergency calling. Some jurisdictions have regulations governing emergency calling. Some jurisdictions have regulations governing
skipping to change at page 4, line 35 skipping to change at page 5, line 35
ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If
the service provider always knows the location of the device, then the service provider always knows the location of the device, then
the service provider could recognize them. the service provider could recognize them.
SP-2 Proxy servers SHOULD recognize emergency dial strings if for SP-2 Proxy servers SHOULD recognize emergency dial strings if for
some reason the endpoint does not recognize them. some reason the endpoint does not recognize them.
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 Geographically local dial strings MUST be recognized.
ED-6/SP-5 Devices MUST be able to be configured with the home country ED-6/SP-5 Devices MUST be able to be configured with the home country
from which the home dial string(s) can be determined. from which the home dial string(s) can be determined.
ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST
[RFC5222]. Dial Strings MAY be configured directly in the device. [RFC5222]. Dial Strings MAY be configured directly into the device.
AN-1 LoST servers MUST return dial strings for emergency services AN-1 LoST servers MUST return dial strings for emergency services.
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 If a proxy server recognizes dial strings on behalf of its SP-7 If a proxy server recognizes dial strings on behalf of its
clients it MUST recognize emergency dial strings represented by clients, it MUST recognize emergency dial strings represented by
[RFC4967] and SHOULD recognize emergency dial strings represented by [RFC4967] and SHOULD recognize the emergency dial strings represented
a tel URI [RFC3966]. by a tel URI [RFC3966].
ED-9 Endpoints SHOULD be able to have home dial strings provisioned. ED-9 Endpoints SHOULD be able to have home dial strings provisioned.
SP-8 Service providers MAY provision home dial strings in devices. SP-8 Service providers MAY provision home dial strings in devices.
ED-10 Devices SHOULD NOT have one button emergency calling ED-10 Devices SHOULD NOT have one button emergency calling
initiation. initiation.
ED-11/SP-9 All sub-services for the 'sos' service specified in ED-11/SP-9 All sub-services for the 'sos' service specified in
[RFC5031] MUST be recognized. [RFC5031]. MUST be recognized.
6. Location and its role in an emergency call 6. Location and its role in an emergency call
Handling location for emergency calling usually involves several Handling location for emergency calling usually involves several
steps to process and multiple elements are involved. In Internet steps to process and multiple elements are involved. In Internet
emergency calling, where the endpoint is located is "determined" emergency calling, where the endpoint is located is "determined"
using a variety of measurement or wiretracing methods. Endpoints may using a variety of measurement or wiretracing methods. Endpoints can
be "configured" with their own location by the access network. In be "configured" with their own location by the access network. In
some circumstances, a proxy server may insert location into the some circumstances, a proxy server can insert location into the
signaling on behalf of the endpoint. The location is "mapped" to the signaling on behalf of the endpoint. The location is "mapped" to the
URI to send the call to, and the location is "conveyed" to the PSAP URI to send the call to, and the location is "conveyed" to the PSAP
(and other elements) in the signaling. Likewise, we employ Location (and other elements) in the signaling. Likewise, we employ Location
Configuration Protocols, the Location-to-Service Mapping Protocol, Configuration Protocols, the Location-to-Service Mapping Protocol,
and Location Conveyance Protocols for these functions. The Location- and Location Conveyance Protocols for these functions. The Location-
to-Service Translation protocol [RFC5222] is the Location Mapping to-Service Translation protocol [RFC5222] is the Location Mapping
Protocol defined by the IETF. Protocol defined by the IETF.
6.1. Types of location information 6.1. Types of location information
There are several forms of location. In IETF location configuration There are several forms of location. All IETF location configuration
and location conveyance protocols, civic and geospatial (geo) forms and location conveyance protocols support both civic and geospatial
are both supported. The civic forms include both postal and (geo) forms. The civic forms include both postal and jurisdictional
jurisdictional fields. A cell tower/sector can be represented as a fields. A cell tower/sector can be represented as a point (geo or
point (geo or civic) or polygon. Other forms of location civic) or polygon. Other forms of location representation MUST be
representation must be mapped into either a geo or civic for use in mapped into either a geo or civic for use in emergency calls.
emergency calls.
ED-12/INT-1/SP-10 Endpoints, Intermediate Devices and Service ED-12/INT-1/SP-10 Endpoints, Intermediate Devices and Service
Providers MUST be prepared to handle location represented in either Providers MUST be prepared to handle location represented in either
civic or geo form. civic or geo form.
ED-13/INT-2/SP-11/AN-2 Elements MUST NOT convert (civic to geo or geo ED-13/INT-2/SP-11/AN-2 Elements MUST NOT convert (civic to geo or geo
to civic) from the form of location the determination mechanism to civic) from the form of location the determination mechanism
supplied. supplied prior to receipt by the PSAP.
6.2. Location Determination 6.2. Location Determination
ED-14/INT-3/AN-3 Any location determination mechanism MAY be used, ED-14/INT-3/AN-3 Any location determination mechanism MAY be used,
provided the accuracy of the location meets local requirements. provided the accuracy of the location meets local requirements.
6.2.1. User-entered location information 6.2.1. User-entered location information
ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access networks ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access networks
SHOULD support a manual method to override the location the access SHOULD support a manual method to override the location the access
network determines. Where a civic form of location is provided, all network determines. When the override location is supplied in civic
fields in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be form, it MUST be possible for the resultant Presence Information Data
specified. Format - Location Object (PIDF-LO) received at the PSAP to contain
any of the elements specified in [RFC4119] and [RFC5139].
6.2.2. Access network "wire database" location information 6.2.2. Access network "wire database" location information
AN-5 Access networks supporting copper, fiber or other hard wired IP AN-5 Access networks supporting copper, fiber or other hard wired IP
packet service SHOULD support location configuration. If the network packet service SHOULD support location configuration. If the network
does not support location configuration, it MUST require every device does not support location configuration, it MUST require every device
that connects to the network to support end system measured location. that connects to the network to support end system measured location.
AN-6/INT-5 Access networks and intermediate devices providing wire AN-6/INT-5 Access networks and intermediate devices providing wire
database location information SHOULD provide interior location data database location information SHOULD provide interior location data
skipping to change at page 7, line 7 skipping to change at page 8, line 8
device was not in the path. device was not in the path.
6.2.3. End-system measured location information 6.2.3. End-system measured location information
ED-16/INT-8 Devices MAY support end-system measured location. See ED-16/INT-8 Devices MAY support end-system measured location. See
[I-D.ietf-ecrit-framework] Section 6 for a discussion of accuracy of [I-D.ietf-ecrit-framework] Section 6 for a discussion of accuracy of
location. location.
ED-17/INT-9/AN-9 Devices that support endpoint measuring of location ED-17/INT-9/AN-9 Devices that support endpoint measuring of location
MUST have at least a coarse location capability (typically <1km MUST have at least a coarse location capability (typically <1km
accuracy when not location hiding) for routing of calls. The accuracy) for routing of calls. The location mechanism MAY be a
location mechanism MAY be a service provided by the access network. service provided by the access network.
6.2.4. Network-measured location information 6.2.4. Network-measured location information
AN-10 Access networks MAY provide network-measured location AN-10 Access networks MAY provide network-measured location
determination. Wireless access networks that do not supply network determination. Wireless access networks that do not supply network
measured location MUST require that all devices connected to the measured location MUST require that all devices connected to the
network have end-system measured location. Uncertainty and network have end-system measured location. Uncertainty and
confidence may be specified by local regulation. Where not confidence may be specified by local regulation. Where not
specified, uncertainty of less than 100 m with 95% confidence is specified, uncertainty of less than 100 meters with 95% confidence is
recommended for dispatch location. RECOMMENDED for dispatch location.
AN-11 Access networks that provide network measured location MUST AN-11 Access networks that provide network measured location MUST
have at least a coarse location (typically <1km when not location have at least a coarse location (typically <1km when not location
hiding) capability at all times for routing of calls. hiding) capability at all times for routing of calls.
AN-12 Access networks with range of <10 meters (e.g. personal area AN-12 Access networks with range of <10 meters (e.g. personal area
networks such as Bluetooth MUST provide a location to mobile devices networks such as Bluetooth MUST provide a location to mobile devices
connected to them. The location provided SHOULD be that of the connected to them. The location provided SHOULD be that reported by
access point location unless a more accurate mechanism is provided. the upstream access network unless a more accurate mechanism is
available.
6.3. Who adds location, endpoint or proxy 6.3. Who adds location, endpoint or proxy
ED-18/INT-10 Endpoints SHOULD attempt to configure their own location ED-18/INT-10 Endpoints SHOULD attempt to configure their own location
using the LCPs listed in ED-21. using the Location Configuration Protocols (LCPs) listed in ED-21.
SP-12 Proxies MAY provide location on behalf of devices if: SP-12 Proxies MAY provide location on behalf of devices if:
o The proxy has a relationship with all access networks the device o The proxy has a relationship with all access networks the device
could connect to, and the relationship allows it to obtain could connect to, and the relationship allows it to obtain
location. location.
o The proxy has an identifier, such as an IP address, that can be o The proxy has an identifier, such as an IP address, that can be
used by the access network to determine the location of the used by the access network to determine the location of the
endpoint, even in the presence of NAT and VPN tunnels that may endpoint, even in the presence of NAT and VPN tunnels that may
obscure the identifier between the access network and the service obscure the identifier between the access network and the service
provider. provider.
skipping to change at page 8, line 14 skipping to change at page 9, line 14
6.4. Location and references to location 6.4. Location and references to location
ED-20/INT-12 Devices SHOULD be able to accept and forward location by ED-20/INT-12 Devices SHOULD be able to accept and forward location by
value or by reference. An end device that receives location by value or by reference. An end device that receives location by
reference (and does not also get the corresponding value) MUST be reference (and does not also get the corresponding value) MUST be
able to perform a dereference operation to obtain a value. able to perform a dereference operation to obtain a value.
6.5. End system location configuration 6.5. End system location configuration
ED-21/INT-13 Devices MUST support both the DHCP location options ED-21/INT-13 Devices MUST support both the Dynamic Host Configuration
[RFC4776], [RFC3825] and HELD [RFC5985]. When devices deploy a Protocol (DHCP) location options [RFC4776], [RFC3825] and HTTP
Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a
specific access network interface for which location configuration specific access network interface for which location configuration
mechanisms such as LLDP-MED [LLDP-MED] or 802.11v are specified, the mechanisms such as Link Layer Discovery Protocol - Media Endpoint
device SHOULD support the additional respective access network Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device
specific location configuration mechanism. SHOULD support the additional respective access network specific
location configuration mechanism.
AN-13/INT-14 The access network MUST support either DHCP location AN-13/INT-14 The access network MUST support either DHCP location
options or HELD. The access network SHOULD support other location options or HELD. The access network SHOULD support other location
configuration technologies that are specific to the type of access configuration technologies that are specific to the type of access
network. If the access network supports more than one location network.
configuration protocol, all such protocols MUST return the same
location, within the constraints of the protocols deployed.
AN-14/INT-15 Where a router is employed between a LAN and WAN in a AN-14/INT-15 Where a router is employed between a LAN and WAN in a
small (less than approximately 650 square meters) area, the router small (less than approximately 650 square meters) area, the router
MUST be transparent to the location provided by the WAN to the LAN. MUST be transparent to the location provided by the WAN to the LAN.
This may mean the router must obtain location as a client from the This may mean the router must obtain location as a client from the
WAN, and supply an LCP server to the LAN with the location it WAN, and supply an LCP server to the LAN with the location it
obtains. Where the area is larger, the LAN MUST have a location obtains. Where the area is larger, the LAN MUST have a location
configuration mechanism satisfying the requirements of this document. configuration mechanism satisfying the requirements of this document.
ED-22/INT-16 Endpoints SHOULD try all LCPs supported by the device in ED-22/INT-16 Endpoints SHOULD try all LCPs supported by the device in
skipping to change at page 10, line 5 skipping to change at page 11, line 5
identifier SHOULD consider the effect of the NAT on the LCP. The identifier SHOULD consider the effect of the NAT on the LCP. The
address used to query the LIS MUST be able to correctly identify the address used to query the LIS MUST be able to correctly identify the
record in the LIS representing the location of the querying device record in the LIS representing the location of the querying device
ED-30/INT-24 For devices which are not expected to change location, ED-30/INT-24 For devices which are not expected to change location,
refreshing location on the order of once per day is RECOMMENDED. refreshing location on the order of once per day is RECOMMENDED.
ED-31/INT-25 For devices which roam, refresh of location information ED-31/INT-25 For devices which roam, refresh of location information
SHOULD be more frequent, with the frequency related to the mobility SHOULD be more frequent, with the frequency related to the mobility
of the device and the ability of the access network to support the of the device and the ability of the access network to support the
refresh operation. If the device detects a state change that might refresh operation. If the device detects a link state change that
indicate having moved, for example when it changes access points, the might indicate having moved, for example when it changes access
device SHOULD refresh its location. points, the device SHOULD refresh its location.
ED-32/INT-26/AN-18 It is RECOMMENDED that location determination not ED-32/INT-26/AN-18 It is RECOMMENDED that location determination not
take longer than 250 ms to obtain routing location and systems SHOULD take longer than 250 ms to obtain routing location and systems SHOULD
be designed such that the typical response is under 100 ms. However, be designed such that the typical response is under 100 ms. However,
as much as 3 seconds to obtain routing location MAY be tolerated if as much as 3 seconds to obtain routing location MAY be tolerated if
location accuracy can be substantially improved over what can be location accuracy can be substantially improved over what can be
obtained in 250 ms. obtained in 250 ms.
6.7. Conveying location in SIP 6.7. Conveying location in SIP
ED-33/SP-15 Location sent between SIP elements MUST be conveyed using ED-33/SP-15 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sip-location-conveyance]. [I-D.ietf-sipcore-location-conveyance].
6.8. Location updates 6.8. Location updates
ED-34/AN-19 Where the absolute location or the accuracy of location ED-34/AN-19 Where the absolute location or the accuracy of location
of the endpoint may change between the time the call is received at of the endpoint may change between the time the call is received at
the PSAP and the time dispatch is completed, location update the PSAP and the time dispatch is completed, location update
mechanisms MUST be implemented and used. mechanisms MUST be implemented and used.
ED-35/AN-20 Mobile devices MUST be provided with a mechanism to get ED-35/AN-20 Mobile devices MUST be provided with a mechanism to get
repeated location updates to track the motion of the device during repeated location updates to track the motion of the device during
skipping to change at page 11, line 12 skipping to change at page 12, line 12
on a large PSAP manageable, and yet provide sufficient indication to on a large PSAP manageable, and yet provide sufficient indication to
the PSAP of motion. the PSAP of motion.
6.9. Multiple locations 6.9. Multiple locations
ED-39/SP-16 If the LIS has more than one location for an endpoint it ED-39/SP-16 If the LIS has more than one location for an endpoint it
MUST conform to the rules in Section 3 of [RFC5491] MUST conform to the rules in Section 3 of [RFC5491]
ED-40 If a UA has more than one location available to it, it MUST ED-40 If a UA has more than one location available to it, it MUST
choose one location to route the call towards the PSAP. If multiple choose one location to route the call towards the PSAP. If multiple
locations are in a single PIDF, the procedures in [RFC5491] MUST be locations are in a single Presence Information Data Format (PIDF),
followed. If the UA has multiple PIDFs, and has no reasonable basis the procedures in [RFC5491] MUST be followed. If the UA has multiple
to choose from among them, a random choice is acceptable. PIDFs, and has no reasonable basis to choose from among them, a
random choice is acceptable.
SP-17 If a proxy inserts location on behalf of an endpoint, and it SP-17 If a proxy inserts location on behalf of an endpoint, and it
has multiple locations available for the endpoint it MUST choose one has multiple locations available for the endpoint it MUST choose one
location to use to route the call towards the PSAP. If multiple location to use to route the call towards the PSAP. If multiple
locations are in a single PIDF, the procedures in [RFC5491] MUST be locations are in a single PIDF, the procedures in [RFC5491] MUST be
followed. If the proxy has multiple PIDFs, and has no reasonable followed. If the proxy has multiple PIDFs, and has no reasonable
basis to choose from among them, a random choice is acceptable. basis to choose from among them, a random choice is acceptable.
SP-18 If a proxy is attempting to insert location but the UA conveyed SP-18 If a proxy is attempting to insert location but the UA conveyed
a location to it, the proxy MUST use the UA's location for routing in a location to it, the proxy MUST use the UA's location for routing in
skipping to change at page 11, line 43 skipping to change at page 12, line 44
the method by which the location was determined, such as GPS, the method by which the location was determined, such as GPS,
manually entered, or based on access network topology included in a manually entered, or based on access network topology included in a
PIDF- LO "method" element. In addition, the source of the location PIDF- LO "method" element. In addition, the source of the location
information MUST be included in a PIDF-LO "provided-by" element. information MUST be included in a PIDF-LO "provided-by" element.
ED-42/SP-21 A location with a method of "derived" MUST NOT be used ED-42/SP-21 A location with a method of "derived" MUST NOT be used
unless no other location is available. unless no other location is available.
6.10. Location validation 6.10. Location validation
AN-23 A LIS should perform location validation of civic locations via AN-23 A LIS SHOULD perform location validation of civic locations via
LoST before entering a location in its database. LoST before entering a location in its database.
ED-44 Endpoints SHOULD validate civic locations when they receive ED-44 Endpoints SHOULD validate civic locations when they receive
them from their LCP. Validation SHOULD be performed in conjunction them from their LCP. Validation SHOULD be performed in conjunction
with the LoST route query to minimize load on the LoST server. with the LoST route query to minimize load on the LoST server.
6.11. Default location 6.11. Default location
AN-24 When the access network cannot determine the actual location of AN-24 When the access network cannot determine the actual location of
the caller, it MUST supply a default location. The default SHOULD be the caller, it MUST supply a default location. The default SHOULD be
chosen to be as close to the probable location of the device as the chosen to be as close to the probable location of the device as the
network can determine. See [I-D.ietf-ecrit-framework] network can determine. See [I-D.ietf-ecrit-framework]
SP-22 Proxies handling emergency calls MUST insert a default location SP-22 Proxies handling emergency calls MUST insert a default location
in the INVITE if the call does not contain a location and the proxy in the INVITE if the incoming INVITE does not contain a location and
does not have a method for obtaining a better location. the proxy does not have a method for obtaining a better location.
AN-25/SP-23 Default locations MUST be marked with method=Default and AN-25/SP-23 Default locations MUST be marked with method=Default and
the proxy MUST be identified in provided-by element of the PIDF-LO. the proxy MUST be identified in provided-by element of the PIDF-LO.
6.12. Other location considerations 6.12. Other location considerations
ED-45 If the LCP does not return location in the form of a PIDF-LO ED-45 If the LCP does not return location in the form of a PIDF-LO
[RFC4119], the endpoint MUST map the location information it receives [RFC4119], the endpoint MUST map the location information it receives
from the configuration protocol to a PIDF-LO. from the configuration protocol to a PIDF-LO.
ED-46/AN-26 To prevent against spoofing of the DHCP server, elements ED-46/AN-26 To prevent against spoofing of the DHCP server, elements
implementing DHCP for location configuration SHOULD use [RFC3118] implementing DHCP for location configuration SHOULD use [RFC3118],
although the difficulty in providing appropriate credentials is although the difficulty in providing appropriate credentials is
significant. significant.
ED-47 If S/MIME is used, the INVITE message MUST provide enough ED-47 If S/MIME is used, the INVITE message MUST provide enough
information unencrypted for intermediate proxies to route the call information unencrypted for intermediate proxies to route the call
based on the location information included. This would include the based on the location information included. This would include the
Geolocation header, and any bodies containing location information. Geolocation header, and any bodies containing location information.
Use of S/MIME with emergency calls is NOT RECOMMENDED. Use of S/MIME with emergency calls is NOT RECOMMENDED.
ED-48/SP-24 Either TLS or IPSEC [RFC3986] MUST be used to protect ED-48/SP-24 Either TLS or IPSEC [RFC3986] MUST be used to protect
skipping to change at page 12, line 48 skipping to change at page 13, line 48
7. LIS and LoST Discovery 7. LIS and LoST Discovery
ED-49 Endpoints MUST support one or more mechanisms that allow them ED-49 Endpoints MUST support one or more mechanisms that allow them
to determine their public IP address, for example, STUN [RFC5389]. to determine their public IP address, for example, STUN [RFC5389].
ED-50 Endpoints MUST support LIS discovery as described in [RFC5986], ED-50 Endpoints MUST support LIS discovery as described in [RFC5986],
and the LoST discovery as described in [RFC5223]. and the LoST discovery as described in [RFC5223].
ED-51 The device MUST have a configurable default LoST server ED-51 The device MUST have a configurable default LoST server
parameter. If the device is provided by or managed by a service parameter.
provider, it is expected that the service provider will configure
this option.
ED-52 DHCP LoST discovery MUST be used, if available, in preference ED-52 DHCP LoST discovery MUST be used, if available, in preference
to configured LoST servers. That is, the endpoint MUST send queries to configured LoST servers. That is, the endpoint MUST send queries
to this LoST server first, using other LoST servers only if these to this LoST server first, using other LoST servers only if these
queries fail. queries fail.
AN-27 Access networks which support DHCP MUST implement the LIS and AN-27 Access networks which support DHCP MUST implement the LIS and
LoST discovery options in their DHCP servers and return suitable LoST discovery options in their DHCP servers and return suitable
server addresses as appropriate. server addresses as appropriate.
skipping to change at page 14, line 43 skipping to change at page 15, line 40
(configuration or dereferencing) with HELD. The use of [RFC5077] is (configuration or dereferencing) with HELD. The use of [RFC5077] is
RECOMMENDED to minimize the time to establish TLS sessions without RECOMMENDED to minimize the time to establish TLS sessions without
keeping server-side state. keeping server-side state.
ED-62/AN-29 When TLS session establishment fails, the location ED-62/AN-29 When TLS session establishment fails, the location
retrieval MUST be retried without TLS. retrieval MUST be retried without TLS.
9.2. SIP signaling requirements for User Agents 9.2. SIP signaling requirements for User Agents
ED-63 The initial SIP signaling method is an INVITE request: ED-63 The initial SIP signaling method is an INVITE request:
1. The Request URI SHOULD be the service URN in the "sos" tree, If 1. The Request URI SHOULD be the service URN in the "sos" tree. If
the device cannot interpret local dial strings, the Request-URI the device does not interpret local dial strings, the Request-
SHOULD be a dial string URI [RFC4967] with the dialed digits. URI MUST be a dial string URI [RFC4967] with the dialed digits.
2. The To header field SHOULD be a service URN in the "sos" tree. 2. The To header field SHOULD be a service URN in the "sos" tree.
If the device cannot interpret local dial strings, the To: If the device does not interpret local dial strings, the To:
SHOULD be a dial string URI with the dialed digits. MUST be a dial string URI with the dialed digits.
3. The From header field SHOULD contain the AoR of the caller. 3. The From header field SHOULD contain the AoR of the caller.
4. A Route header field SHOULD be present with a PSAP URI obtained 4. A Route header field SHOULD be present with a PSAP URI obtained
from LoST (see Section 8). If the device does not interpret from LoST (see Section 8). If the device does not interpret
dial plans, or was unable to obtain a route from a LoST server, dial plans, or was unable to obtain a route from a LoST server,
no such Route header field will be present. no such Route header field will be present.
5. A Contact header field MUST be globally routable, for example a 5. A Contact header field MUST be globally routable, for example a
GRUU [RFC5627], and be valid for several minutes following the GRUU [RFC5627], and be valid for several minutes following the
termination of the call, provided that the UAC remains termination of the call, provided that the UAC remains
registered with the same registrar, to permit an immediate call- registered with the same registrar, to permit an immediate call-
back to the specific device which placed the emergency call. It back to the specific device which placed the emergency call. It
is acceptable if the UAC inserts a locally routable URI and a is acceptable if the UAC inserts a locally routable URI and a
subsequent B2BUA maps that to a globally routable URI. subsequent B2BUA maps that to a globally routable URI.
6. Other header fields MAY be included as per normal SIP behavior. 6. Other header fields MAY be included as per normal SIP behavior.
7. A Supported header field MUST be included with the 'geolocation' 7. If a geolocation URI is included in the INVITE, a Supported
option tag [I-D.ietf-sip-location-conveyance], unless the device header field MUST be included with a 'geolocation-sip' or
does not understand the concept of SIP location. 'geolocation-http" option tag, as appropriate.
[I-D.ietf-sipcore-location-conveyance].
8. If a device understands the SIP location conveyance 8. If a device understands the SIP location conveyance
[I-D.ietf-sip-location-conveyance] extension and has its [I-D.ietf-sipcore-location-conveyance] extension and has its
location available, it MUST include location either by-value, location available, it MUST include location either by-value,
by-reference or both. by-reference or both.
9. If a device understands the SIP Location Conveyance extension 9. A SDP offer SHOULD be included in the INVITE. If voice is
and has its location unavailable or unknown to that device, it supported the offer SHOULD include the G.711 codec, see
MUST include a Supported header field with a "geolocation"
option tag, and MUST NOT include a Geolocation header field, and
not include a PIDF-LO message body.
10. A SDP offer SHOULD be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see
Section 14. As PSAPs may support a wide range of media types Section 14. As PSAPs may support a wide range of media types
and codecs, sending an offerless INVITE may result in a lengthy and codecs, sending an offerless INVITE may result in a lengthy
return offer, but is permitted. Cautions in [RFC3261] on return offer, but is permitted. Cautions in [RFC3261] on
offerless INVITEs should be considered before such use. offerless INVITEs should be considered before such use.
11. If the device includes location-by-value, the UA MUST support 10. 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.
12. A UAC SHOULD include a "inserted-by" header parameter with its
own hostname on all Geolocation header fields. This informs
downstream elements which device entered the location at this
URI (either cid-URL or location-by-reference URI).
9.3. SIP signaling requirements for proxy servers 9.3. SIP signaling requirements for proxy servers
SP-33 SIP Proxy servers processing emergency calls: SP-33 SIP Proxy servers processing emergency calls:
1. If the proxy interprets dial plans on behalf of user agents, the 1. If the proxy interprets dial plans on behalf of user agents, the
proxy MUST look for the local emergency dial string at the proxy MUST look for the local emergency dial string at the
location of the end device and MAY look for the home dial string. location of the end device and MAY look for the home dial string.
If it finds it, the proxy MUST: If it finds it, the proxy MUST:
* Insert a Geolocation header field. Location-by-reference MUST * Insert a Geolocation header field. Location-by-reference MUST
be used because proxies must not insert bodies. be used because proxies must not insert bodies.
* Insert the Geolocation-Routing header with appropriate
* Include the Geolocation "inserted-by" and "used-for-routing" parameters .
parameters with its own hostname (which should match the Via
it inserts) on the inserted-by.
* Map the location to a PSAP URI using LoST. * Map the location to a PSAP URI using LoST.
* Add a Route header with the PSAP URI. * Add a Route header with the PSAP URI.
* Replace the Request-URI (which was the dial string) with the * Replace the Request-URI (which was the dial string) with the
service URN appropriate for the emergency dial string. service URN appropriate for the emergency dial string.
* Route the call using normal SIP routing mechanisms. * Route the call using normal SIP routing mechanisms.
2. If the proxy recognizes the service URN in the Request URI, and 2. If the proxy recognizes the service URN in the Request URI, and
does not find a a Route header, it MUST query a LoST server. If does not find a Route header, it MUST query a LoST server
a location was provided (which should be the case), the proxy immediately. If a location was provided (which should be the
uses that location to query LoST. The proxy may have to case), the proxy uses that location to query LoST. The proxy may
dereference a location by reference to get a value. If a have to dereference a location by reference to get a value. If a
location is not present, and the proxy can query a LIS which has 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 proxy SHOULD NOT modify any parameters in Geolocation header 3. The proxy MAY add a Geolocation header field. Such an additional
fields received in the call. It MAY add a Geolocation header location SHOULD NOT be used for routing; the location provided by
field. Such an additional location SHOULD NOT be used for the UA should be used.
routing; the location provided by the UA should be used.
4. Either a P-Asserted-Identity [RFC3325] or an Identity header 4. Either a P-Asserted-Identity [RFC3325] or an Identity header
field [RFC4474], or both, SHOULD be included to identify the field [RFC4474], or both, SHOULD be included to identify the
sender. For services which must support emergency calls from sender. For services which must support emergency calls from
unauthenticated devices, valid identity may not be available. unauthenticated devices, valid identity may not be available.
Proxies encountering a P-Asserted-Identity will need to pass the Proxies encountering a P-Asserted-Identity will need to pass the
header to the PSAP, which is in a different domain. [RFC3325] header to the PSAP, which is in a different domain. [RFC3325]
requires a "spec(T)" to determine what happens if the "id" requires a "spec(T)" to determine what happens if the "id"
privacy service, or a Privacy header is present and requests privacy service, or a Privacy header is present and requests
privacy. In the absence of another spec(T), such proxies should privacy. In the absence of another spec(T), such proxies should
pass the header unmodified if and only if the connection between pass the header unmodified if and only if the connection between
the proxy and the PSAP is, as far as the proxy can determine, the proxy and the PSAP is, as far as the proxy can determine,
protected by TLS with mutual authentication using keys reliably protected by TLS with mutual authentication using keys reliably
known by the parties, encrypted with no less strength than AES known by the parties, encrypted with no less strength than AES
and the local regulations governing the PSAP do not otherwise and the local regulations governing the PSAP do not otherwise
specify. specify.
5. Proxies SHOULD NOT return a 424 error. It should process the
INVITE as best as it can.
6. Proxies SHOULD NOT obey a Geolocation-Routing value of "no" or a
missing value if the proxy must query LoST to obtain a route.
Emergency calls are always routed by location.
10. Call backs 10. Call backs
ED-64/SP-34 Devices device SHOULD have a globally routable URI in a ED-64/SP-34 Devices device SHOULD have a globally routable URI in a
Contact: header field which remains valid for several minutes past Contact: header field which remains valid for several minutes past
the time the original call containing the URI completes unless the the time the original call containing the URI completes unless the
device registration expires and is not renewed. device registration expires and is not renewed.
SP-35 Call backs to the Contact: header URI received within 30 SP-35 Call backs to the Contact: header URI received within 30
minutes of an emergency call must reach the device regardless of call minutes of an emergency call must reach the device regardless of call
skipping to change at page 17, line 20 skipping to change at page 18, line 10
SP-36 Devices MUST have a persistent AOR URI either in a P-Asserted- SP-36 Devices MUST have a persistent AOR URI either in a P-Asserted-
Identity header field or From protected by an Identity header field Identity header field or From protected by an Identity header field
suitable for returning a call some time after the original call. suitable for returning a call some time after the original call.
Such a call back would not necessarily reach the device that Such a call back would not necessarily reach the device that
originally placed the call. originally placed the call.
11. Mid-call behavior 11. Mid-call behavior
ED-65/SP-37 During the course of an emergency call, devices and ED-65/SP-37 During the course of an emergency call, devices and
proxies MUST initiate a call transfer upon receipt of REFER request proxies MUST initiate a call transfer upon receipt of REFER request
within the dialog with method=INVITE and the Referred-by: header within the dialog with method=INVITE and the Referred-by header field
field [RFC3515] in that request. [RFC3515] in that request.
12. Call termination 12. Call termination
ED-66 There can be a case where the session signaling path is lost, ED-66 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, the PSAP terminates the call but the user agent does not receive the
and the session timer (if implemented) expires, the call MAY be BYE. The PSAP would not receive the ACK and may initiate a call
declared lost. If in the interval, an incoming call is received from back. If an incoming call is received from the domain of the PSAP,
the domain of the PSAP, the device MUST drop the old call and alert the device MUST alert for the (new) incoming call. The domain of an
for the (new) incoming call. Dropping of the old call MUST only incoming call can only be determined from the From header, which is
occur if the user is attempting to hang up; the domain of an incoming not reliable, and could be spoofed. Dropping an active call by a new
call can only be determined from the From header, which is not
reliable, and could be spoofed. Dropping an active call by a new
call with a spoofed From header field would be a DoS attack. call with a spoofed From header field would be a DoS attack.
13. Disabling of features 13. Disabling of features
ED-67/SP-38 User Agents and proxies MUST disable features that will ED-67/SP-38 User Agents and proxies MUST disable features that will
interrupt an ongoing emergency call, such as: interrupt an ongoing emergency call, such as:
o Call Waiting o Call Waiting
o Call Transfer o Call Transfer
o Three Way Call o Three Way Call
o Hold o Hold
o Outbound Call Blocking o Outbound Call Blocking
when an emergency call is established. Also see ED-74 in Section 14. when an emergency call is established, but see ED-66 with respect to
Call Waiting. Also see ED-74 in Section 14.
ED-68/SP-39 The emergency dial strings SHOULD NOT be permitted in ED-68/SP-39 The emergency dial strings SHOULD NOT be permitted in
Call Forward numbers or speed dial lists. Call Forward numbers or speed dial lists.
ED-69/SP-40 The User Agent and Proxies MUST disable call features ED-69/SP-40 The User Agent and Proxies MUST disable call features
which would interfere with the ability of call backs from the PSAP to which would interfere with the ability of call backs from the PSAP to
be completed such as: be completed such as:
o Do Not Disturb o Do Not Disturb
o Call Forward (all kinds) o Call Forward (all kinds)
These features SHOULD be disabled for approximately 30 minutes
following termination of an emergency call.
ED-70 Call backs SHOULD be determined by retaining the domain of the ED-70 Call backs SHOULD be determined by retaining the domain of the
PSAP which answers an outgoing emergency call and instantiating a PSAP which answers an outgoing emergency call and instantiating a
timer which starts when the call is terminated. If a call is timer which starts when the call is terminated. If a call is
received from the same domain and within the timer period, sent to received from the same domain and within the timer period, sent to
the Contact: or AoR used in the emergency call, it should be assumed the Contact: or AoR used in the emergency call, it should be assumed
to be a call back. The suggested timer period is 5 minutes. to be a call back. The suggested timer period is 5 minutes.
[RFC4916] may be used by the PSAP to inform the UA of the domain of [RFC4916] may be used by the PSAP to inform the UA of the domain of
the PSAP. Recognizing a call back from the domain of the PSAP will the PSAP. Recognizing a call back from the domain of the PSAP will
not always work, and further standardization will be required to give not always work, and further standardization will be required to give
the UA the ability to recognize a call back. the UA the ability to recognize a call back.
14. Media 14. Media
ED-71 Endpoints MUST send and receive media streams on RTP [RFC3550]. ED-71 Endpoints MUST send and receive media streams on RTP [RFC3550].
ED-72 Normal SIP offer/answer [RFC3264] negotiations MUST be used to ED-72 Normal SIP offer/answer [RFC3264] negotiations MUST be used to
agree on the media streams to be used. agree on the media streams to be used.
ED-73 Endpoints supporting voice MUST support G.711 A law (and mu Law ED-73/SP-41 G.711 A law (and mu Law if they are intended be used in
if they are intended be used in North America) encoded voice as North America) encoded voice as described in [RFC3551] MUST be
described in [RFC3551]. It is desirable to include wideband codecs supported. If the endpoint cannot support G.711, a transcoder MUST
such as AMR-WB in the offer. be used so that the offer received at the PSAP contains G.711. It is
desirable to include wideband codecs such as G.722 and AMR-WB in the
offer. PSAPs SHOULD support narrowband codecs common on endpoints in
their area to avoid transcoding.
ED-74 Silence suppression (Voice Activity Detection methods) MUST NOT ED-74 Silence suppression (Voice Activity Detection methods) MUST NOT
be used on emergency calls. PSAP call takers sometimes get be used on emergency calls. PSAP call takers sometimes get
information on what is happening in the background to determine how information on what is happening in the background to determine how
to process the call. to process the call.
ED-75 Endpoints supporting Instant Messaging (IM) MUST support both ED-75 Endpoints supporting Instant Messaging (IM) MUST support either
[RFC3428] and [RFC4975]. [RFC3428] and [RFC4975].
ED-76 Endpoints supporting real-time text MUST use [RFC4103]. The ED-76 Endpoints supporting real-time text MUST use [RFC4103]. The
expectations for emergency service support for the real-time text expectations for emergency service support for the real-time text
medium are described in [RFC5194], Section 7.1. medium are described in [RFC5194], Section 7.1.
ED-77 Endpoints supporting video MUST support H.264 per ED-77 Endpoints supporting video MUST support H.264 per
[I-D.ietf-avt-rtp-rfc3984bis]. [I-D.ietf-avt-rtp-rfc3984bis].
15. Testing 15. Testing
ED-78 INVITE requests to a service URN ending in ".test" indicates a ED-78 INVITE requests to a service URN starting with "test."
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:servicetest.sos.fire". As in standard SIP, a 200 (OK) response
indicates that the address was recognized and a 404 (Not found) that indicates that the address was recognized and a 404 (Not found) that
it was not. A 486 (Busy Here) MUST be returned if the test service it was not. A 486 (Busy Here) MUST be returned if the test service
is busy, and a 404 (Not found) MUST be returned if the PSAP does not is busy, and a 404 (Not found) MUST be returned if the PSAP does not
support the test mechanism. support the test mechanism.
ED-79 In its response to the test, the PSAP MAY include a text body ED-79 In its response to the test, the PSAP MAY include a text body
(text/plain) indicating the identity of the PSAP, the requested (text/plain) indicating the identity of the PSAP, the requested
service, and the location reported with the call. For the latter, service, and the location reported with the call. For the latter,
the PSAP SHOULD return location-by-value even if the original the PSAP SHOULD return location-by-value even if the original
location delivered with the test was by-reference. If the location- location delivered with the test was by-reference. If the location-
skipping to change at page 20, line 12 skipping to change at page 20, line 49
device in a short period of time. Any refusal is signaled with a 486 device in a short period of time. Any refusal is signaled with a 486
or 488 response. or 488 response.
16. Security Considerations 16. Security Considerations
Security considerations for emergency calling have been documented in Security considerations for emergency calling have been documented in
[RFC5069], and [I-D.ietf-geopriv-arch]. [RFC5069], and [I-D.ietf-geopriv-arch].
17. IANA Considerations 17. IANA Considerations
This document has no actions for IANA. This document registers service URNs in the Service URN Labels
registry per [RFC5031] for testing.
17.1. test service urn
A new entry in the URN Service Label registry is added. The new
service is "test", the reference is this document, and the
description is "self test".
17.2. 'test' Subregistry
A new Subregistry is created, the "'test' Sub-Service. The
registration process is Expert review by ECRIT working group, its
successor, or, in their absence, the IESG. The Reference is this
document. The initial content of the subregistry is:
Service Reference Description
--------------------------------------------------------------------
test.sos [this document] test for sos
test.sos.ambulance [this document] test for sos.ambulance
test.sos.animal-control [this document] test for sos.animal-control
test.sos.fire [this document] test for sos.fire
test.sos.gas [this document] test for sos.gas
test.sos.marine [this document] test for sos.marine
test.sos.mountain [this document] test for sos.mountain
test.sos.physician [this document] test for sos.physician
test.sos.poison [this document] test for sos.poison
test.sos.police [this document] test for sos.police
18. Acknowledgements 18. 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 Hannes Tschofenig, Ted Hardie, Marc Linsner, Roger
Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Barbara
Barbara Stark, Richard Barnes and Peter Blatherwick. Stark, Richard Barnes and Peter Blatherwick.
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-avt-rtp-rfc3984bis] [I-D.ietf-avt-rtp-rfc3984bis]
Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video", Payload Format for H.264 Video",
draft-ietf-avt-rtp-rfc3984bis-12 (work in progress), draft-ietf-avt-rtp-rfc3984bis-12 (work in progress),
October 2010. October 2010.
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Sivachelvan, C., Venna, N., Jones, P., Stratton, N., Sivachelvan, C., Venna, N., Jones, P., Stratton, N.,
Roychowdhury, A., and K. Hedayat, "An Extension to the Roychowdhury, A., and K. Hedayat, "An Extension to the
Session Description Protocol (SDP) for Media Loopback", Session Description Protocol (SDP) for Media Loopback",
draft-ietf-mmusic-media-loopback-14 (work in progress), draft-ietf-mmusic-media-loopback-15 (work in progress),
July 2010. March 2011.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sipcore-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
Session Initiation Protocol", for the Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress), draft-ietf-sipcore-location-conveyance-06 (work in
March 2009. progress), February 2011.
[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.
[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.
skipping to change at page 23, line 30 skipping to change at page 24, line 48
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, Location Information Server (LIS)", RFC 5986,
September 2010. September 2010.
19.2. Informative References 19.2. Informative References
[I-D.ietf-ecrit-framework] [I-D.ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-11 (work in Multimedia", draft-ietf-ecrit-framework-12 (work in
progress), July 2010. progress), October 2010.
[I-D.ietf-geopriv-arch] [I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-03 (work in progress), draft-ietf-geopriv-arch-03 (work in progress),
October 2010. October 2010.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
 End of changes. 58 change blocks. 
172 lines changed or deleted 200 lines changed or added

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