draft-ietf-ecrit-phonebcp-18.txt   draft-ietf-ecrit-phonebcp-19.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 29, 2012 Cisco Systems Expires: March 6, 2012 Cisco Systems
July 28, 2011 September 3, 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-18 draft-ietf-ecrit-phonebcp-19
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 using IETF protocols should use such standards
calls. to make emergency calls.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). 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 29, 2012. This Internet-Draft will expire on March 6, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
6.2.2. Access network "wire database" location information . 7 6.2.2. Access network "wire database" location information . 7
6.2.3. End-system measured location information . . . . . . . 8 6.2.3. End-system measured location information . . . . . . . 8
6.2.4. Network-measured location information . . . . . . . . 8 6.2.4. Network-measured location information . . . . . . . . 8
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8
6.4. Location and references to location . . . . . . . . . . . 9 6.4. Location and references to location . . . . . . . . . . . 9
6.5. End system location configuration . . . . . . . . . . . . 9 6.5. End system location configuration . . . . . . . . . . . . 9
6.6. When location should be configured . . . . . . . . . . . . 10 6.6. When location should be configured . . . . . . . . . . . . 10
6.7. Conveying location . . . . . . . . . . . . . . . . . . . . 11 6.7. Conveying location . . . . . . . . . . . . . . . . . . . . 11
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12
6.10. Location validation . . . . . . . . . . . . . . . . . . . 12 6.10. Location validation . . . . . . . . . . . . . . . . . . . 13
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 13 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 13
6.12. Other location considerations . . . . . . . . . . . . . . 13 6.12. Other location considerations . . . . . . . . . . . . . . 13
7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 14
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. SIP signaling requirements for User Agents . . . . . . . . 15 9.2. SIP signaling requirements for User Agents . . . . . . . . 16
9.3. SIP signaling requirements for proxy servers . . . . . . . 16 9.3. SIP signaling requirements for proxy servers . . . . . . . 16
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16. Security Considerations . . . . . . . . . . . . . . . . . . . 20 16. Security Considerations . . . . . . . . . . . . . . . . . . . 21
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
17.1. test service urn . . . . . . . . . . . . . . . . . . . . . 21 17.1. test service urn . . . . . . . . . . . . . . . . . . . . . 21
17.2. 'test' Subregistry . . . . . . . . . . . . . . . . . . . . 21 17.2. 'test' Subregistry . . . . . . . . . . . . . . . . . . . . 21
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
19.1. Normative References . . . . . . . . . . . . . . . . . . . 21 19.1. Normative References . . . . . . . . . . . . . . . . . . . 22
19.2. Informative References . . . . . . . . . . . . . . . . . . 25 19.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this 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 Public Safety Protocol [RFC3261] user agents, proxy servers and Public Safety
Access Points (PSAPs) support emergency calling, as outlined in Access Points (PSAPs) support emergency calling, as outlined in
[I-D.ietf-ecrit-framework], which is designed to complement the [I-D.ietf-ecrit-framework], which is designed to complement the
skipping to change at page 4, line 36 skipping to change at page 4, line 37
"SP-") and PSAPs to achieve globally interoperable emergency calling "SP-") and PSAPs to achieve globally interoperable emergency calling
on the Internet. 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-".
The access network requirements apply to those networks which may be
used to place emergency calls using IETF protocols. Local
regulations may impact the need to support this document's access
network requirements.
Other organizations, such as the North American Emergency Number Other organizations, such as the North American Emergency Number
Association (NENA), define the PSAP interface. NENA's documents Association (NENA), define the PSAP interface. NENA's documents
reference this document. reference this document.
3. Overview of how emergency calls are placed 3. Overview of how emergency calls are placed
An emergency call can be distinguished (Section 5) from any other An emergency call can be distinguished (Section 5) from any other
call by a unique Service URN [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
skipping to change at page 5, line 32 skipping to change at page 5, line 38
ED-2 Devices that create media sessions and exchange real-time audio, ED-2 Devices that create media sessions and exchange real-time audio,
video and/or text, have the capability to establish sessions to a video and/or text, have the capability to establish sessions to a
wide variety of addresses, and communicate over private IP networks wide variety of addresses, and communicate over private IP networks
or the Internet, SHOULD support emergency calls. Some jurisdictions or the Internet, SHOULD support emergency calls. Some jurisdictions
have 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 (the
the service provider could recognize them. correct dial string depends on which country you are in), the service
provider may recognize them, see SP-2.
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 Geographically 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
skipping to change at page 6, line 26 skipping to change at page 6, line 34
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 entities 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 can 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 can 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 entities) in the signaling. Likewise, we employ Location
Configuration Protocols (LCPs), the Location-to-Service Mapping Configuration Protocols (LCPs), the Location-to-Service Mapping
Protocol, and Location Conveyance Protocols for these functions. The Protocol, and Location Conveyance Protocols for these functions. The
Location-to-Service Translation protocol [RFC5222] is the Location Location-to-Service Translation protocol [RFC5222] is the Location
Mapping Protocol defined by the IETF. Mapping Protocol defined by the IETF.
6.1. Types of location information 6.1. Types of location information
There are several forms of location. All IETF location configuration There are several forms of location. All IETF location configuration
and location conveyance protocols support both civic and geospatial and location conveyance protocols support both civic and geospatial
(geo) forms. The civic forms include both postal and jurisdictional (geo) forms. The civic forms include both postal and jurisdictional
fields. A cell tower/sector can be represented as a point (geo or fields. A cell tower/sector can be represented as a point (geo or
civic) or polygon. Other forms of location representation MUST be civic) or polygon. Endpoints, Intermediate Devices and Service
mapped into either a geo or civic for use in emergency calls. Providers receiving other forms of location representation MUST map
them into either a geo or civic for use in 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 Entities 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 (see
supplied prior to receipt by the PSAP. Section Section 6.2) 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. When the override location is supplied in civic network determines. When the override location is supplied in civic
form, it MUST be possible for the resultant Presence Information Data form, it MUST be possible for the resultant Presence Information Data
Format - Location Object (PIDF-LO) received at the PSAP to contain Format - Location Object (PIDF-LO) received at the PSAP to contain
any of the elements specified in [RFC4119] and [RFC5139]. 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. or intermediate device 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. See [I-D.ietf-ecrit-framework] Section 6.2.2 for 650 square meters. See [I-D.ietf-ecrit-framework] Section 6.2.2 for
a discussion of how this value was determined. 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
skipping to change at page 8, line 20 skipping to change at page 8, line 29
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) for routing of calls. The location mechanism MAY be a accuracy) for routing of calls. The 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 or intermediate measured location MUST require every device or intermediate device
devices connected to the network have end-system measured location. connected to the network to support end-system measured location.
Uncertainty and confidence may be specified by local regulation. Uncertainty and confidence may be specified by local regulation.
Where not specified, uncertainty of less than 100 meters with 95% Where not specified, uncertainty of less than 100 meters with 95%
confidence is RECOMMENDED for dispatch location. confidence is 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
skipping to change at page 9, line 19 skipping to change at page 9, line 31
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 Dynamic Host Configuration ED-21/INT-13 Devices MUST support both the Dynamic Host Configuration
Protocol (DHCP) location options [RFC4776], [RFC3825] and HTTP Protocol (DHCP) location options [RFC4776], [RFC6225] and HTTP
Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a 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 Link Layer Discovery Protocol - Media Endpoint mechanisms such as Link Layer Discovery Protocol - Media Endpoint
Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device
SHOULD support the additional respective access network specific SHOULD support the additional respective access network specific
location configuration mechanism. location configuration mechanism.
AN-13/INT-14 The access network MUST support either DHCP location
options or HELD. The access network SHOULD support other location
configuration technologies that are specific to the type of access
network.
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
any order or in parallel. The first one that succeeds in supplying any order or in parallel. The first one that succeeds in supplying
skipping to change at page 10, line 13 skipping to change at page 10, line 29
which need location for emergency calls does not allow access to which need location for emergency calls does not allow access to
Layer 2 and Layer 3 functions necessary for a client application to Layer 2 and Layer 3 functions necessary for a client application to
use DHCP location options and/or other location technologies that are use DHCP location options and/or other location technologies that are
specific to the type of access network, the operating system MUST specific to the type of access network, the operating system MUST
provide a published API conforming to ED-12 through ED-23 and ED-25 provide a published API conforming to ED-12 through ED-23 and ED-25
through ED-32. It is RECOMMENDED that all operating systems provide through ED-32. It is RECOMMENDED that all operating systems provide
such an API. such an API.
6.6. When location should be configured 6.6. When location should be configured
If an endpoint is manually configured, the requirements in this
section are not applicable.
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, and does not use it MUST include both options for
(civic and geodetic), the option for LIS discovery, and the option location acquisition (civic and geodetic), the option for LIS
for LoST discovery as defined in [RFC4776], [RFC3825], [RFC5986] and discovery, and the option for LoST discovery as defined in [RFC4776],
[RFC5223]. [RFC6225], [RFC5986] and [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], [RFC5986] and [RFC5223]. defined in [RFC4776], [RFC6225], [RFC5986] and [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 18 skipping to change at page 11, line 37
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 6.7. Conveying location
ED-33/SP-15 Location sent between SIP elements MUST be conveyed using ED-33/SP-15 Location sent between SIP entities MUST be conveyed using
[I-D.ietf-sipcore-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
skipping to change at page 12, line 10 skipping to change at page 12, line 25
INVITE or UPDATE request. Such updates SHOULD be limited to no more INVITE or UPDATE request. Such updates SHOULD be limited to no more
than one update every 10 seconds, a value selected to keep the load than one update every 10 seconds, a value selected to keep the load
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 an endpoint has more than one location available to it, it
choose one location to route the call towards the PSAP. If multiple MUST choose one location to route the call towards the PSAP. If
locations are in a single Presence Information Data Format (PIDF), multiple locations are in a single Presence Information Data Format
the procedures in [RFC5491] MUST be followed. If the UA has multiple (PIDF), the procedures in [RFC5491] MUST be followed. If the
PIDFs, and has no reasonable basis to choose from among them, a endpoint has multiple PIDFs, and has no reasonable basis to choose
random choice is acceptable. 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 endpoint
a location to it, the proxy MUST use the UA's location for routing in conveyed a location to it, the proxy MUST use the endpoint's location
the initial INVITE and MUST convey that location towards the PSAP. for routing in the initial INVITE and MUST convey that location
It MAY also include what it believes the location to be in a separate towards the PSAP. It MAY also include what it believes the location
Geolocation header. 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.
skipping to change at page 13, line 25 skipping to change at page 13, line 38
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, entities
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 [RFC5751] is used, the INVITE message MUST provide
information unencrypted for intermediate proxies to route the call enough information unencrypted for intermediate proxies to route the
based on the location information included. This would include the call based on the location information included. This would include
Geolocation header, and any bodies containing location information. the Geolocation header, and any bodies containing location
Use of S/MIME with emergency calls is NOT RECOMMENDED. information. Use of S/MIME with emergency calls is NOT RECOMMENDED
for this reason.
ED-48/SP-24 Either TLS or IPsec [RFC3986] MUST be used to protect ED-48/SP-24 TLS [RFC5746] MUST be used to protect location (but see
location (but see Section 9.1). Section 9.1). All implementations MUST support TLS.
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
skipping to change at page 14, line 37 skipping to change at page 14, line 51
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-25 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 endpoint was unable to
LoST and the proxy MUST perform the LoST mapping and insert a Route invoke LoST and the proxy MUST perform the LoST mapping and insert a
header field with the URI obtained. Route header field with the URI obtained.
SP-26 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 endpoints that do not have access to their own location
proxy that recognizes a call as an emergency call that is not marked data, a proxy that recognizes a call as an emergency call that is not
as such (see Section 5) MUST also perform this mapping, with the best marked as such (see Section 5) MUST also perform this mapping, with
location it has available for the endpoint. The resulting PSAP URI the best location it has available for the endpoint. The resulting
would be placed in a Route header with the service URN in the Request PSAP URI would be placed in a Route header with the service URN in
URI. the Request URI.
SP-27 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-28 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-29 [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-30 Either TLS or IPsec MUST be used when attempting to ED-58/SP-30 TLS is the primary mechanism used to secure the signaling
signal an emergency call. for emergency calls. IPsec [RFC4301] MAY be used instead of TLS for
any hop. Either TLS or IPSEC MUST be used when attempting to signal
an emergency call.
ED-59/SP-31 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-32 [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 entities when one of the entity 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 SHOULD 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. IPsec MAY be used instead of TLS.
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 does not interpret local dial strings, the Request- the device does not interpret local dial strings, the Request-
URI MUST be a dial string URI [RFC4967] with the dialed digits. URI MUST be a dial string URI [RFC4967] with the dialed digits.
skipping to change at page 18, line 47 skipping to change at page 19, line 19
o Call Forward (all kinds) o Call Forward (all kinds)
These features SHOULD be disabled for approximately 30 minutes These features SHOULD be disabled for approximately 30 minutes
following termination of an emergency call. 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 endpoint of the
the PSAP. Recognizing a call back from the domain of the PSAP will domain of the PSAP. Recognizing a call back from the domain of the
not always work, and further standardization will be required to give PSAP will not always work, and further standardization will be
the UA the ability to recognize a call back. required to give the endpoint 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/SP-41 G.711 A law (and mu Law if they are intended be used in ED-73/SP-41 G.711 A law (and mu Law if they are intended be used in
North America) encoded voice as described in [RFC3551] MUST be North America) encoded voice as described in [RFC3551] MUST be
skipping to change at page 19, line 34 skipping to change at page 19, line 51
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 either 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 [RFC6184].
[I-D.ietf-avt-rtp-rfc3984bis].
15. Testing 15. Testing
ED-78 INVITE requests to a service URN starting with "test." ED-78 INVITE requests to a service URN starting with "test."
indicates a request for an automated test. For example, indicates a request for an automated test. For example,
"urn:servicetest.sos.fire". As in standard SIP, a 200 (OK) response "urn:service:test.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 28 skipping to change at page 20, line 42
mirror. User Agents should expect the PSAP to loop back no more than mirror. User Agents should expect the PSAP to loop back no more than
3 packets of each media type accepted (which limits the duration of 3 packets of each media type accepted (which limits the duration of
the test), after which the PSAP would normally send BYE. the test), after which the PSAP would normally send BYE.
ED-81 User agents SHOULD perform a full call test, including media ED-81 User agents SHOULD perform a full call test, including media
loopback, after a disconnect and subsequent change in IP address not loopback, after a disconnect and subsequent change in IP address not
due to a reboot. After an initial test, a full test SHOULD be due to a reboot. After an initial test, a full test SHOULD be
repeated approximately every 30 days with a random interval. repeated approximately every 30 days with a random interval.
ED-82 User agents MUST NOT place a test call immediately after ED-82 User agents MUST NOT place a test call immediately after
booting. If the IP address changes after booting, the UA should wait booting. If the IP address changes after booting, the endpoint
a random amount of time (in perhaps a 30 minute period, sufficient should wait a random amount of time (in perhaps a 30 minute period,
for any avalanche restart to complete) and then test. sufficient for any avalanche restart to complete) and then test.
ED-83 PSAPs MAY refuse repeated requests for test from the same ED-83 PSAPs MAY refuse repeated requests for test from the same
device in a short period of time. Any refusal is signaled with a 486 device in a short period of time. Any refusal is signaled with a 486
or 488 response. or 488 response.
16. Security Considerations 16. Security Considerations
Security considerations for emergency calling have been documented in Security considerations for emergency calling have been documented in
[RFC5069], and [I-D.ietf-geopriv-arch]. This document suggests that [RFC5069], and [RFC6280]. This document suggests that security (TLS
security (TLS or IPsec) be used hop by hop on a SIP call to protect or IPsec) be used hop by hop on a SIP call to protect location
location information, identity, etc. It also suggests that if the information, identity, etc. It also suggests that if the attempt to
attempt to create a security association fails, the call be retried create a security association fails, the call be retried without the
without the security. It's more important to get an emergency call security. It's more important to get an emergency call through than
through than to protect the data; indeed, in many jurisdictions to protect the data; indeed, in many jurisdictions privacy is
privacy is explicitly waived when making emergency calls. Placing a explicitly waived when making emergency calls. Placing a call
call without security may reveal user information, including without security may reveal user information, including location.
location. The alternative - failing the call if security cannot be The alternative - failing the call if security cannot be established,
established, is considered unacceptable. is considered unacceptable.
17. IANA Considerations 17. IANA Considerations
This document registers service URNs in the Service URN Labels This document registers service URNs in the Service URN Labels
registry per [RFC5031] for testing. registry per [RFC5031] for testing.
17.1. test service urn 17.1. test service urn
A new entry in the URN Service Label registry is added. The new A new entry in the URN Service Label registry is added. The new
service is "test", the reference is this document, and the service is "test", the reference is this document, and the
skipping to change at page 21, line 47 skipping to change at page 22, line 16
Work group members participating in the creation and review of this Work group members participating in the creation and review of this
document include Hannes Tschofenig, Ted Hardie, Marc Linsner, Roger document include Hannes Tschofenig, Ted Hardie, Marc Linsner, Roger
Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Barbara Marshall, Stu Goldman, Shida Schubert, James Winterbottom, 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]
Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video",
draft-ietf-avt-rtp-rfc3984bis-12 (work in progress),
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-15 (work in progress), draft-ietf-mmusic-media-loopback-15 (work in progress),
March 2011. March 2011.
[I-D.ietf-sipcore-location-conveyance] [I-D.ietf-sipcore-location-conveyance]
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", for the Session Initiation Protocol",
skipping to change at page 23, line 13 skipping to change at page 23, line 23
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007. Protocol (SIP)", RFC 4916, June 2007.
skipping to change at page 24, line 44 skipping to change at page 24, line 46
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.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010. RFC 5985, September 2010.
[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.
[RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video", RFC 6184, May 2011.
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
Host Configuration Protocol Options for Coordinate-Based
Location Configuration Information", RFC 6225, July 2011.
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-12 (work in Multimedia", draft-ietf-ecrit-framework-12 (work in
progress), October 2010. progress), October 2010.
[I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
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.
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
skipping to change at page 26, line 5 skipping to change at page 25, line 49
January 2008. January 2008.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text
over IP Using the Session Initiation Protocol (SIP)", over IP Using the Session Initiation Protocol (SIP)",
RFC 5194, June 2008. RFC 5194, June 2008.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 2011.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar NeuStar
470 Conrad Dr. 470 Conrad Dr.
Mars, PA 16046 Mars, PA 16046
USA USA
Phone: +1 724 382 1051 Phone: +1 724 382 1051
Email: br@brianrosen.net Email: br@brianrosen.net
 End of changes. 50 change blocks. 
115 lines changed or deleted 132 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/