draft-ietf-ecrit-phonebcp-15.txt   draft-ietf-ecrit-phonebcp-16.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: BCP J. Polk Intended status: BCP J. Polk
Expires: January 14, 2011 Cisco Systems Expires: April 28, 2011 Cisco Systems
July 13, 2010 October 25, 2010
Best Current Practice for Communications Services in support of Best Current Practice for Communications Services in support of
Emergency Calling Emergency Calling
draft-ietf-ecrit-phonebcp-15 draft-ietf-ecrit-phonebcp-16
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 January 14, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 10 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 10
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11
6.10. Location validation . . . . . . . . . . . . . . . . . . . 11 6.10. Location validation . . . . . . . . . . . . . . . . . . . 11
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12
6.12. Other location considerations . . . . . . . . . . . . . . 12 6.12. Other location considerations . . . . . . . . . . . . . . 12
7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 12 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 12
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 13 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 13
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 14 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 14
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. SIP signaling requirements for User Agents . . . . . . . . 14 9.2. SIP signaling requirements for User Agents . . . . . . . . 14
9.3. SIP signaling requirements for proxy servers . . . . . . . 16 9.3. SIP signaling requirements for proxy servers . . . . . . . 15
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 17 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 17
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 17 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 17
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 17 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 17
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
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 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 4, line 17 skipping to change at page 4, line 17
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
this. this.
ED-2 Devices that create media sessions and exchange audio, video ED-2 Devices that create media sessions and exchange real-time audio,
and/or text, and have the capability to establish sessions to a wide video and/or text, have the capability to establish sessions to a
variety of addresses, and communicate over private IP networks or the wide variety of addresses, and communicate over private IP networks
Internet, SHOULD support emergency calls. Some jurisdictions have or the Internet, SHOULD support emergency calls. Some jurisdictions
regulations governing this. have regulations governing this.
5. Identifying an emergency call 5. Identifying an emergency call
ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If
the service provider always knows the location of the device, then the service provider always knows the location of the device, then
the service provider could recognize them. the service provider could recognize them.
SP-2 Proxy servers SHOULD recognize emergency dial strings if for SP-2 Proxy servers SHOULD recognize emergency dial strings if for
some reason the endpoint does not recognize them. some reason the endpoint does not recognize them.
skipping to change at page 6, line 29 skipping to change at page 6, line 29
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
(building, floor, room, cubicle) where possible. It is RECOMMENDED (building, floor, room, cubicle) where possible. It is RECOMMENDED
that interior location be provided when spaces exceed approximately that interior location be provided when spaces exceed approximately
650 square meters. 650 square meters. See [I-D.ietf-ecrit-framework] Section 6.2.2 for
a discussion of how this value was determined.
AN-7/INT-6 Access networks and intermediate devices (including AN-7/INT-6 Access networks and intermediate devices (including
enterprise networks) which support intermediate range wireless enterprise networks) which support intermediate range wireless
connections (typically 100m or less of range) and which do not connections (typically 100m or less of range) and which do not
support a more accurate location determination mechanism such as support a more accurate location determination mechanism such as
triangulation, MUST support location configuration where the location triangulation, MUST support location configuration where the location
of the access point is reflected as the location of the clients of of the access point is reflected as the location of the clients of
that access point. that access point.
AN-8/INT-7 Where the access network provides location configuration, AN-8/INT-7 Where the access network provides location configuration,
intermediate devices MUST either be transparent to it, or provide an intermediate devices MUST either be transparent to it, or provide an
interconnected client for the supported configuration mechanism and a interconnected client for the supported configuration mechanism and a
server for a configuration protocol supported by end devices server for a configuration protocol supported by end devices
downstream of the intermediate device such that the location provided downstream of the intermediate device such that the location provided
by the access network is available to clients as if the intermediate by the access network is available to clients as if the intermediate
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. ED-16/INT-8 Devices MAY support end-system measured location. See
Uncertainty of less than 100 m with 95% confidence SHOULD be [I-D.ietf-ecrit-framework] Section 6 for a discussion of accuracy of
available for dispatch. 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 when not location hiding) for routing of calls. The
location mechanism MAY be a service provided by the access network. location mechanism MAY be a service provided by the access network.
6.2.4. Network-measured location information 6.2.4. Network-measured location information
AN-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
skipping to change at page 8, line 15 skipping to change at page 8, line 15
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 DHCP location options
[RFC4776], [RFC3825] and HELD [RFC4776], [RFC3825] and HELD [RFC5985]. When devices deploy a
[I-D.ietf-geopriv-http-location-delivery]. 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 LLDP-MED [LLDP-MED] or 802.11v are specified, the
device SHOULD support the additional respective access network device SHOULD support the additional respective access network
specific location configuration mechanism. 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. If the access network supports more than one location
configuration protocol, all such protocols MUST return the same configuration protocol, all such protocols MUST return the same
skipping to change at page 9, line 20 skipping to change at page 9, line 19
such an API. such an API.
6.6. When location should be configured 6.6. When location should be configured
ED-25/INT-19 Endpoints SHOULD obtain location immediately after ED-25/INT-19 Endpoints SHOULD obtain location immediately after
obtaining local network configuration information. obtaining local network configuration information.
ED-26/INT-20 If the device is configured to use DHCP for ED-26/INT-20 If the device is configured to use DHCP for
bootstrapping, it MUST include both options for location acquisition bootstrapping, it MUST include both options for location acquisition
(civic and geodetic), the option for LIS discovery, and the option (civic and geodetic), the option for LIS discovery, and the option
for LoST discovery as defined in [RFC4776], [RFC3825], for LoST discovery as defined in [RFC4776], [RFC3825], [RFC5986] and
[I-D.ietf-geopriv-lis-discovery] and [RFC5223]. [RFC5223].
ED-27/INT-21 If the device sends a DHCPINFORM message, it MUST ED-27/INT-21 If the device sends a DHCPINFORM message, it MUST
include both options for location acquisition (civic and geodetic), include both options for location acquisition (civic and geodetic),
the option for LIS discovery, and the option for LoST discovery as the option for LIS discovery, and the option for LoST discovery as
defined in [RFC4776], [RFC3825], [I-D.ietf-geopriv-lis-discovery] and defined in [RFC4776], [RFC3825], [RFC5986] and [RFC5223].
[RFC5223].
ED-28/INT-22 To minimize the effects of VPNs that do not allow ED-28/INT-22 To minimize the effects of VPNs that do not allow
packets to be sent via the native hardware interface rather than via packets to be sent via the native hardware interface rather than via
the VPN tunnel, location configuration SHOULD be attempted before the VPN tunnel, location configuration SHOULD be attempted before
such tunnels are established. such tunnels are established.
ED-29/INT-23 Software which uses LCPs SHOULD locate and use the ED-29/INT-23 Software which uses LCPs SHOULD locate and use the
actual hardware network interface rather than a VPN tunnel interface actual hardware network interface rather than a VPN tunnel interface
to direct LCP requests to the LIS in the actual access network. to direct LCP requests to the LIS in the actual access network.
skipping to change at page 11, line 24 skipping to change at page 11, line 24
to choose from among them, a random choice is acceptable. to choose from among them, a random choice is acceptable.
SP-17 If a proxy inserts location on behalf of an endpoint, and it SP-17 If a proxy inserts location on behalf of an endpoint, and it
has multiple locations available for the endpoint it MUST choose one has multiple locations available for the endpoint it MUST choose one
location to use to route the call towards the PSAP. 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 a location to it, the proxy MUST use the UA's location for routing in
and MUST convey that location towards the PSAP. It MAY also include the initial INVITE and MUST convey that location towards the PSAP.
what it believes the location to be in a separate Geolocation header. It MAY also include what it believes the location to be in a separate
Geolocation header.
SP-19 All location objects received by a proxy MUST be delivered to SP-19 All location objects received by a proxy MUST be delivered to
the PSAP. the PSAP.
ED-41/SP-20 Location objects MUST be created with information about ED-41/SP-20 Location objects MUST be created with information about
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.
ED-43/SP-22 When there are multiple Geolocation header field values
provided, the "used-for-routing" parameter MUST be set to the
location that was chosen for routing.
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-23 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 call does not contain a location and the proxy
does not have a method for obtaining a better location. does not have a method for obtaining a better location.
AN-25/SP-24 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-25 Either TLS or IPSEC [RFC3986] MUST be used to protect ED-48/SP-24 Either TLS or IPSEC [RFC3986] MUST be used to protect
location (but see Section 9.1). location (but see Section 9.1).
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 ED-50 Endpoints MUST support LIS discovery as described in [RFC5986],
[I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described and the LoST discovery as described in [RFC5223].
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. If the device is provided by or managed by a service
provider, it is expected that the service provider will configure provider, it is expected that the service provider will configure
this option. this option.
ED-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.
skipping to change at page 13, line 34 skipping to change at page 13, line 34
ED-55 The endpoint MUST attempt to update its location at the time of ED-55 The endpoint MUST attempt to update its location at the time of
an emergency call. If it cannot obtain a new location quickly (see an emergency call. If it cannot obtain a new location quickly (see
Section 6), it MUST use the cached value. Section 6), it MUST use the cached value.
ED-56 The endpoint SHOULD attempt to update the LoST mapping at the ED-56 The endpoint SHOULD attempt to update the LoST mapping at the
time of an emergency call. If it cannot obtain a new mapping time of an emergency call. If it cannot obtain a new mapping
quickly, it MUST use the cached value. If the device cannot update quickly, it MUST use the cached value. If the device cannot update
the LoST mapping and does not have a cached value, it MUST signal an the LoST mapping and does not have a cached value, it MUST signal an
emergency call without a Route header containing a PSAP URI. emergency call without a Route header containing a PSAP URI.
SP-26 Networks MUST be designed so that at least one proxy in the SP-25 Networks MUST be designed so that at least one proxy in the
outbound path will recognize emergency calls with a Request URI of outbound path will recognize emergency calls with a Request URI of
the service URN in the "sos" tree. An endpoint places a service URN the service URN in the "sos" tree. An endpoint places a service URN
in the Request URI to indicate that the endpoint understood the call in the Request URI to indicate that the endpoint understood the call
was an emergency call. A proxy that processes such a call looks for was an emergency call. A proxy that processes such a call looks for
the presence of a SIP Route header field with a URI of a PSAP. the presence of a SIP Route header field with a URI of a PSAP.
Absence of such a Route header indicates the UAC was unable to invoke Absence of such a Route header indicates the UAC was unable to invoke
LoST and the proxy MUST perform the LoST mapping and insert a Route LoST and the proxy MUST perform the LoST mapping and insert a Route
header field with the URI obtained. header field with the URI obtained.
SP-27 To deal with old user agents that predate this specification SP-26 To deal with old user agents that predate this specification
and with UAs that do not have access to their own location data, a and with UAs that do not have access to their own location data, a
proxy that recognizes a call as an emergency call that is not marked 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 be placed in a Route header with the service URN in the Request would be placed in a Route header with the service URN in the Request
URI. URI.
SP-28 Proxy servers performing mapping SHOULD use location obtained SP-27 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-29 A proxy server which attempts mapping and fails to get a SP-28 A proxy server which attempts mapping and fails to get a
mapping MUST provide a default mapping. A suitable default mapping mapping MUST provide a default mapping. A suitable default mapping
would be the mapping obtained previously for the default location would be the mapping obtained previously for the default location
appropriate for the caller. appropriate for the caller.
ED-57/SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route ED-57/SP-29 [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.
9. Signaling of emergency calls 9. Signaling of emergency calls
9.1. Use of TLS 9.1. Use of TLS
ED-58/SP-31 Either TLS or IPsec MUST be used when attempting to ED-58/SP-30 Either TLS or IPsec MUST be used when attempting to
signal an emergency call. signal an emergency call.
ED-59/SP-32 If TLS session establishment is not available, or fails, ED-59/SP-31 If TLS session establishment is not available, or fails,
the call MUST be retried without TLS. the call MUST be retried without TLS.
ED-60/SP-33 [RFC5626] is RECOMMENDED to maintain persistent TLS ED-60/SP-32 [RFC5626] is RECOMMENDED to maintain persistent TLS
connections between elements when one of the element is an endpoint. connections between elements when one of the element is an endpoint.
Persistent TLS connection between proxies is RECOMMENDED using any Persistent TLS connection between proxies is RECOMMENDED using any
suitable mechanism. suitable mechanism.
ED-61/AN-28 TLS MUST be used when attempting to retrieve location ED-61/AN-28 TLS MUST be used when attempting to retrieve location
(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
skipping to change at page 15, line 29 skipping to change at page 15, line 29
does not understand the concept of SIP location. does not understand the concept of SIP location.
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-sip-location-conveyance] extension and has its
location available, it MUST include location either by-value, location available, it MUST include location either by-value,
by-reference or both. by-reference or both.
9. If a device understands the SIP Location Conveyance extension 9. If a device understands the SIP Location Conveyance extension
and has its location unavailable or unknown to that device, it and has its location unavailable or unknown to that device, it
MUST include a Supported header field with a "geolocation" MUST include a Supported header field with a "geolocation"
option tag, and MUST NOT include a Geolocation header field, and option tag, and MUST NOT include a Geolocation header field, and
not include a PIDF-LO message body. not include a PIDF-LO message body.
10. If a device understands the SIP Location Conveyance extension 10. A SDP offer SHOULD be included in the INVITE. If voice is
and supports LoST [RFC5222], the Geolocation "used-for-routing"
header parameter MUST be added to the corresponding URI in the
Geolocation header field. If the device is unable to obtain a
PSAP URI for any reason it MUST NOT include "used-for-routing"
on a Geolocation URI, so that downstream entities know that LoST
routing has not been completed.
11. A SDP offer SHOULD be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see supported the offer MUST include the G.711 codec, see
Section 14. As PSAPs may support a wide range of media types Section 14. As PSAPs may support a wide range of media types
and codecs, sending an offerless INVITE may result in a lengthy and codecs, sending an offerless INVITE may result in a lengthy
return offer, but is permitted. Cautions in [RFC3261] on return offer, but is permitted. Cautions in [RFC3261] on
offerless INVITEs should be considered before such use. offerless INVITEs should be considered before such use.
12. If the device includes location-by-value, the UA MUST support 11. 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.
13. A UAC SHOULD include a "inserted-by" header parameter with its 12. A UAC SHOULD include a "inserted-by" header parameter with its
own hostname on all Geolocation header fields. This informs own hostname on all Geolocation header fields. This informs
downstream elements which device entered the location at this downstream elements which device entered the location at this
URI (either cid-URL or location-by-reference URI). URI (either cid-URL or location-by-reference URI).
9.3. SIP signaling requirements for proxy servers 9.3. SIP signaling requirements for proxy servers
SP-34 SIP Proxy servers processing emergency calls: SP-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.
* Include the Geolocation "inserted-by" and "used-for-routing" * Include the Geolocation "inserted-by" and "used-for-routing"
parameters with its own hostname (which should match the Via parameters with its own hostname (which should match the Via
it inserts) on the inserted-by. it inserts) on the inserted-by.
* Map the location to a PSAP URI using LoST. * Map the location to a PSAP URI using LoST.
* Add a Route header with the PSAP URI. * Add a Route header with the PSAP URI.
* Replace the Request-URI (which was the dial string) with the * Replace the Request-URI (which was the dial string) with the
service URN appropriate for the emergency dial string. service URN appropriate for the emergency dial string.
* Route the call using normal SIP routing mechanisms. * Route the call using normal SIP routing mechanisms.
2. If the proxy recognizes the service URN in the Request URI, and 2. If the proxy recognizes the service URN in the Request URI, and
does not find a a Route header, it MUST query a LoST server. If does not find a a Route header, it MUST query a LoST server. If
skipping to change at page 16, line 24 skipping to change at page 16, line 15
* Include the Geolocation "inserted-by" and "used-for-routing" * Include the Geolocation "inserted-by" and "used-for-routing"
parameters with its own hostname (which should match the Via parameters with its own hostname (which should match the Via
it inserts) on the inserted-by. it inserts) on the inserted-by.
* Map the location to a PSAP URI using LoST. * Map the location to a PSAP URI using LoST.
* Add a Route header with the PSAP URI. * Add a Route header with the PSAP URI.
* Replace the Request-URI (which was the dial string) with the * Replace the Request-URI (which was the dial string) with the
service URN appropriate for the emergency dial string. service URN appropriate for the emergency dial string.
* Route the call using normal SIP routing mechanisms. * Route the call using normal SIP routing mechanisms.
2. If the proxy recognizes the service URN in the Request URI, and 2. If the proxy recognizes the service URN in the Request URI, and
does not find a a Route header, it MUST query a LoST server. If does not find a a Route header, it MUST query a LoST server. If
multiple locations were provided, the proxy uses the location a location was provided (which should be the case), the proxy
that has the "used-for-routing" marker set. If a location was uses that location to query LoST. The proxy may have to
provided (which should be the case), the proxy uses that location dereference a location by reference to get a value. If a
to query LoST. The proxy may have to dereference a location by location is not present, and the proxy can query a LIS which has
reference to get a value. If a location is not present, and the the location of the UA it MUST do so. If no location is present,
proxy can query a LIS which has the location of the UA it MUST do and the proxy does not have access to a LIS which could provide
so. If no location is present, and the proxy does not have location, the proxy MUST supply a default location (See
access to a LIS which could provide location, the proxy MUST Section 6.11). The location (in the signaling, obtained from a
supply a default location (See Section 6.11). The location (in LIS, or default) MUST be used in a query to LoST with the service
the signaling, obtained from a LIS, or default) MUST be used in a URN received with the call. The resulting URI MUST be placed in
query to LoST with the service URN received with the call. The a Route header added to the call.
resulting URI MUST be placed in a Route header added to the call. 3. The proxy SHOULD NOT modify any parameters in Geolocation header
3. The "inserted-by" parameter in any Geolocation: header received
on the call MUST NOT be modified or deleted in transit.
4. The proxy SHOULD NOT modify any parameters in Geolocation header
fields received in the call. It MAY add a Geolocation header fields received in the call. It MAY add a Geolocation header
field. Such an additional location SHOULD NOT be used for field. Such an additional location SHOULD NOT be used for
routing; the location provided by the UA should be used. routing; the location provided by the UA should be used.
5. Either a P-Asserted-Identity [RFC3325] or an Identity header 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
header to the PSAP, which is in a different domain. [RFC3325]
requires a "spec(T)" to determine what happens if the "id"
privacy service, or a Privacy header is present and requests
privacy. In the absence of another spec(T), such proxies should
pass the header unmodified if and only if the connection between
the proxy and the PSAP is, as far as the proxy can determine,
protected by TLS with mutual authentication using keys reliably
known by the parties, encrypted with no less strength than AES
and the local regulations governing the PSAP do not otherwise
specify.
10. Call backs 10. Call backs
ED-64/SP-35 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-36 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
features or services that would normally cause the call to be routed features or services that would normally cause the call to be routed
to some other entity. to some other entity.
SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- SP-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-38 During the course of an emergency call, devices and ED-65/SP-37 During the course of an emergency call, devices and
proxies MUST complete 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 [RFC3515] in that request. field [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, and the user agent does not receive the BYE. If the call is hung up,
and the session timer (if implemented) expires, the call MAY be and the session timer (if implemented) expires, the call MAY be
declared lost. If in the interval, an incoming call is received from declared lost. If in the interval, an incoming call is received from
the domain of the PSAP, the device MUST drop the old call and alert the domain of the PSAP, the device MUST drop the old call and alert
for the (new) incoming call. Dropping of the old call MUST only for the (new) incoming call. Dropping of the old call MUST only
occur if the user is attempting to hang up; the domain of an incoming occur if the user is attempting to hang up; the domain of an incoming
call can only be determined from the From header, which is not call can only be determined from the From header, which is not
reliable, and could be spoofed. Dropping an active call by a new reliable, and could be spoofed. Dropping an active call by a new
call with a spoofed From 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-39 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. Also see ED-74 in Section 14.
ED-68/SP-40 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-41 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)
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
skipping to change at page 20, line 28 skipping to change at page 20, line 28
Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom,
Barbara Stark, Richard Barnes and Peter Blatherwick. Barbara Stark, Richard Barnes and Peter Blatherwick.
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-avt-rtp-rfc3984bis] [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-11 (work in progress), draft-ietf-avt-rtp-rfc3984bis-12 (work in progress),
June 2010. October 2010.
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009.
[I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-15 (work in progress),
March 2010.
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Sivachelvan, C., Venna, N., Jones, P., Stratton, N., Sivachelvan, C., Venna, N., Jones, P., Stratton, N.,
Roychowdhury, A., and K. Hedayat, "An Extension to the Roychowdhury, A., and K. Hedayat, "An Extension to the
Session Description Protocol (SDP) for Media Loopback", Session Description Protocol (SDP) for Media Loopback",
draft-ietf-mmusic-media-loopback-13 (work in progress), draft-ietf-mmusic-media-loopback-14 (work in progress),
April 2010. July 2010.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009. March 2009.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
skipping to change at page 23, line 31 skipping to change at page 23, line 18
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, October 2009.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986,
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-10 (work in Multimedia", draft-ietf-ecrit-framework-11 (work in
progress), July 2009. progress), July 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-02 (work in progress), May 2010. draft-ietf-geopriv-arch-03 (work in progress),
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
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008. RFC 5012, January 2008.
 End of changes. 44 change blocks. 
95 lines changed or deleted 88 lines changed or added

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