draft-ietf-ecrit-phonebcp-08.txt   draft-ietf-ecrit-phonebcp-09.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: BCP J. Polk Intended status: BCP J. Polk
Expires: August 30, 2009 Cisco Systems Expires: September 28, 2009 Cisco Systems
February 26, 2009 March 27, 2009
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-08 draft-ietf-ecrit-phonebcp-09
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2009. This Internet-Draft will expire on September 28, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of how emergency calls are placed . . . . . . . . . . 4 3. Overview of how emergency calls are placed . . . . . . . . . . 4
4. Which devices and services should support emergency calls . . 5 4. Which devices and services should support emergency calls . . 5
5. Identifying an emergency call . . . . . . . . . . . . . . . . 5 5. Identifying an emergency call . . . . . . . . . . . . . . . . 5
6. Location and its role in an emergency call . . . . . . . . . . 6 6. Location and its role in an emergency call . . . . . . . . . . 6
6.1. Types of location information . . . . . . . . . . . . . . 6 6.1. Types of location information . . . . . . . . . . . . . . 6
6.2. Location Determination . . . . . . . . . . . . . . . . . . 7 6.2. Location Determination . . . . . . . . . . . . . . . . . . 7
6.2.1. User-entered location information . . . . . . . . . . 7 6.2.1. User-entered location information . . . . . . . . . . 7
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 . . . . . . . 7 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 . . . . . . . . . . . 8 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 in SIP . . . . . . . . . . . . . . . . 11 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 11
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12
6.10. Location validation . . . . . . . . . . . . . . . . . . . 12 6.10. Location validation . . . . . . . . . . . . . . . . . . . 12
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . 17 9.3. SIP signaling requirements for proxy servers . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . 19
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16. Security Considerations . . . . . . . . . . . . . . . . . . . 21 16. Security Considerations . . . . . . . . . . . . . . . . . . . 21
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
19.1. Normative References . . . . . . . . . . . . . . . . . . . 21 19.1. Normative References . . . . . . . . . . . . . . . . . . . 21
19.2. Informative References . . . . . . . . . . . . . . . . . . 24 19.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. BCP Requirements Sorted by Responsible Party . . . . 25 Appendix A. BCP Requirements Sorted by Responsible Party . . . . 25
A.1. Requirements of End Devices . . . . . . . . . . . . . . . 25 A.1. Requirements of End Devices . . . . . . . . . . . . . . . 25
A.2. Requirements of Service Providers . . . . . . . . . . . . 34 A.2. Requirements of Service Providers . . . . . . . . . . . . 35
A.3. Requirements of Access Network . . . . . . . . . . . . . . 39 A.3. Requirements of Access Network . . . . . . . . . . . . . . 39
A.4. Requirements of Intermediate Devices . . . . . . . . . . . 42 A.4. Requirements of Intermediate Devices . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 4, line 33 skipping to change at page 4, line 33
"AN-", service providers (requirements prefaced by "SP-") and PSAPs "AN-", service providers (requirements prefaced by "SP-") and PSAPs
to achieve globally interoperable emergency calling on the Internet. to achieve globally interoperable emergency calling on the Internet.
This document also defines requirements for "Intermediate" devices This document also defines requirements for "Intermediate" devices
which exist between end devices or applications and the access which exist between end devices or applications and the access
network. For example, a home router is an "Intermediate" device. network. For example, a home router is an "Intermediate" device.
Reporting location on an emergency call (see Section 6) may depend on Reporting location on an emergency call (see Section 6) may depend on
the ability of such intermediate devices to meet the requirements the ability of such intermediate devices to meet the requirements
prefaced by "INT-". prefaced by "INT-".
This document focuses on the case in which all three steps in the
emergency calling process -- location configuration, call routing,
and call placement - can be and are performed by the calling
endpoint, with the endpoint's Access Service Provider supporting the
process by providing location information. Calls in this case may be
routed via an application-layer Communications Service Provider
(e.g., a Voice Service Provider), but need not be. The underlying
protocols can also be used to support other models in which parts of
the process are delegated to the Communications Service Provider.
This document does not address in detail either these models or
interoperability issues between them and the model described here.
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
geographic regions, a caller must obtain his location (Section 6) geographic regions, a caller must obtain his location (Section 6)
prior to making emergency calls. To get this location, either a form prior to making emergency calls. To get this location, either a form
of measuring (e.g., GPS) (Section 6.2.3) device location in the of measuring (e.g., GPS) (Section 6.2.3) device location in the
endpoint is deployed, or the endpoint is configured (Section 6.5) endpoint is deployed, or the endpoint is configured (Section 6.5)
skipping to change at page 15, line 24 skipping to change at page 15, line 35
ED-58 Initial INVITES MUST provide an Offer [RFC3264]. ED-58 Initial INVITES MUST provide an Offer [RFC3264].
9. Signaling of emergency calls 9. Signaling of emergency calls
ED-59 deleted ED-59 deleted
9.1. Use of TLS 9.1. Use of TLS
ED-60/SP-31 TLS MUST be specified when attempting to signal an ED-60/SP-31 TLS MUST be specified when attempting to signal an
emergency call with SIP per Section 3.1 of [I-D.ietf-sip-sips]. emergency call. IPSEC [RFC3986] is an acceptable alternative.
IPSEC [RFC3986] is an acceptable alternative.
ED-61/SP-32 If TLS session establishment fails, the call MUST be ED-61/SP-32 If TLS session establishment is not available, or fails,
retried without TLS. the call MUST be retried without TLS.
ED-62/SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain ED-62/SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain
persistent TLS connections between elements. persistent TLS connections between elements.
ED-63/AN-28 TLS MUST be specified when attempting to retrieve ED-63/AN-28 TLS MUST be specified when attempting to retrieve
location (configuration or dereferencing) with HELD. The use of location (configuration or dereferencing) with HELD. The use of
[RFC5077] is RECOMMENDED to minimize the time to establish TLS [RFC5077] is RECOMMENDED to minimize the time to establish TLS
sessions without keeping server-side state. sessions without keeping server-side state.
ED-64/AN-29 If TLS session establishment fails, the location ED-64/AN-29 If TLS session establishment fails, the location
skipping to change at page 16, line 4 skipping to change at page 16, line 14
9.2. SIP signaling requirements for User Agents 9.2. SIP signaling requirements for User Agents
ED-65 The initial SIP signaling method is an INVITE request: ED-65 The initial SIP signaling method is an INVITE request:
1. The Request URI SHOULD be the service URN in the "sos" tree, If 1. The Request URI SHOULD be the service URN in the "sos" tree, If
the device cannot interpret local dial strings, the Request-URI the device cannot interpret local dial strings, the Request-URI
SHOULD be a dial string URI [RFC4967] with the dialed digits. SHOULD be a dial string URI [RFC4967] with the dialed digits.
2. The To header SHOULD be a service URN in the "sos" tree. If the 2. The To header SHOULD be a service URN in the "sos" tree. If the
device cannot interpret local dial strings, the To: SHOULD be a device cannot interpret local dial strings, the To: SHOULD be a
dial string URI with the dialed digits. dial string URI with the dialed digits.
3. The From header MUST be present and SHOULD be the AoR of the 3. The From header MUST be present and SHOULD be the AoR of the
caller. caller.
4. A Via header MUST be present. 4. A Via header MUST be present.
5. A Route header SHOULD be present with a PSAP URI obtained from 5. A Route header SHOULD be present with a PSAP URI obtained from
LoST (see Section 8) and the loose route parameter. If the LoST (see Section 8) and the loose route parameter. If the
device does not interpret dial plans, or was unable to obtain a device does not interpret dial plans, or was unable to obtain a
route from a LoST server, no Route header will be present. route from a LoST server, no Route header will be present.
6. A Contact header MUST be present which MUST be globally 6. A Contact header MUST be present which MUST be globally
routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid
for several minutes following the termination of the call to for several minutes following the termination of the call,
permit an immediate call-back to the specific device which provided that the UAC remains registered with the same
placed the emergency call. registrar, to permit an immediate call-back to the specific
device which placed the emergency call. It is acceptable if the
UAC inserts a locally routable URI and a subsequent B2BUA maps
that to a globally routable URI.
7. Other headers MAY be included as per normal SIP behavior. 7. Other headers MAY be included as per normal SIP behavior.
8. A Supported header MUST be included with the 'geolocation' 8. A Supported header MUST be included with the 'geolocation'
option tag [I-D.ietf-sip-location-conveyance], unless the device option tag [I-D.ietf-sip-location-conveyance], unless the device
does not understand the concept of SIP location. does not understand the concept of SIP location.
9. If a device understands the SIP location conveyance 9. If a device understands the SIP location conveyance
[I-D.ietf-sip-location-conveyance] extension and has its [I-D.ietf-sip-location-conveyance] extension and has its
location available, it MUST include location either by-value, location available, it MUST include location either by-value,
by-reference or both. by-reference or both.
10. If a device understands the SIP Location Conveyance extension 10. If a device understands the SIP Location Conveyance extension
and has its location unavailable or unknown to that device, it and has its location unavailable or unknown to that device, it
skipping to change at page 18, line 21 skipping to change at page 18, line 35
SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted-
Identity: header or From: protected by an Identity header suitable Identity: header or From: protected by an Identity header suitable
for returning a call some time after the original call. Such a call for returning a call some time after the original call. Such a call
back would not necessarily reach the device that originally placed back would not necessarily reach the device that originally placed
the call. the call.
11. Mid-call behavior 11. Mid-call behavior
ED-67/SP-38 During the course of an emergency call, devices and ED-67/SP-38 During the course of an emergency call, devices and
proxies MUST support REFER transactions and the Referred-by: header proxies MUST support REFER transactions with method=INVITE and the
[RFC3515]. Referred-by: header [RFC3515] in that transaction.
12. Call termination 12. Call termination
ED-68 deleted ED-68 deleted
ED-69 There can be a case where the session signaling path is lost, ED-69 There can be a case where the session signaling path is lost,
and the user agent does not receive the BYE. If the call is hung up, and the user agent does not receive the BYE. If the call is hung up,
and the session timer (if implemented) expires, the call MAY be and the session timer (if implemented) expires, the call MAY be
declared lost. If in the interval, an incoming call is received from declared lost. If in the interval, an incoming call is received from
the domain of the PSAP, the device MUST drop the old call and alert the domain of the PSAP, the device MUST drop the old call and alert
for the (new) incoming call. Dropping of the old call MUST only for the (new) incoming call. Dropping of the old call MUST only
occur if the user is attempting to hang up; the domain of an incoming occur if the user is attempting to hang up; the domain of an incoming
call can only be determined from the From header, which is not call can only be determined from the From header, which is not
reliable, and could be spoofed. Dropping an active call by a new reliable, and could be spoofed. Dropping an active call by a new
call with a spoofed From: would be a DoS attack. call with a spoofed From: would be a DoS attack.
13. Disabling of features 13. Disabling of features
ED-70/SP-39 User Agents and proxies MUST disable outgoing call ED-70/SP-39 User Agents and proxies MUST disable features that will
features 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, including Flash hold o Hold
o Outbound Call Blocking o Outbound Call Blocking
when an emergency call is established. Also see ED-77 in Section 14. when an emergency call is established. Also see ED-77 in Section 14.
ED-71/SP-40 The emergency dial strings SHOULD NOT be permitted in ED-71/SP-40 The emergency dial strings SHOULD NOT be permitted in
Call Forward numbers or speed dial lists. Call Forward numbers or speed dial lists.
ED-72/SP-41 The User Agent and Proxies SHOULD disable the following ED-72/SP-41 The User Agent and Proxies MUST disable call features
incoming call features on call backs from the PSAP: which would interfere with the ability of call backs from the PSAP to
o Call Waiting be completed such as:
o Do Not Disturb o Do Not Disturb
o Call Forward (all kinds) o Call Forward (all kinds)
ED-73 Call backs SHOULD be determined by retaining the domain of the ED-73 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
the PSAP. Recognizing a call back from the domain of the PSAP will
not always work, and further standardization will be required to give
the UA the ability to recognize a call back.
14. Media 14. Media
ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550]. ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550].
ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to
agree on the media streams to be used. agree on the media streams to be used.
ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law
if they are intended be used in North America) encoded voice as if they are intended be used in North America) encoded voice as
skipping to change at page 20, line 24 skipping to change at page 20, line 38
ED-82 In its response to the test, the PSAP MAY include a text body ED-82 In its response to the test, the PSAP MAY include a text body
(text/plain) indicating the identity of the PSAP, the requested (text/plain) indicating the identity of the PSAP, the requested
service, and the location reported with the call. For the latter, service, and the location reported with the call. For the latter,
the PSAP SHOULD return location-by-value even if the original the PSAP SHOULD return location-by-value even if the original
location delivered with the test was by-reference. If the location- location delivered with the test was by-reference. If the location-
by-reference was supplied, and the dereference requires credentials, by-reference was supplied, and the dereference requires credentials,
the PSAP SHOULD use credentials supplied by the LIS for test the PSAP SHOULD use credentials supplied by the LIS for test
purposes. This alerts the LIS that the dereference is not for an purposes. This alerts the LIS that the dereference is not for an
actual emergency call and location hiding techniques, if they are actual emergency call and location hiding techniques, if they are
being used, may be employed for this dereference. The test response being used, may be employed for this dereference. Use of SIPS for
SHOULD be protected with TLS. If the body cannot be protected, the the request would assure the response containing the location is kept
location SHOULD NOT be included in the response.. private
ED-83 A PSAP accepting a test call SHOULD accept a media loopback ED-83 A PSAP accepting a test call SHOULD accept a media loopback
test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-
pkt-loopback" and "rtp-start-loopback" options. The user agent would pkt-loopback" and "rtp-start-loopback" options. The user agent would
specify a loopback attribute of "loopback-source", the PSAP being the specify a loopback attribute of "loopback-source", the PSAP being the
mirror. User Agents should expect the PSAP to loop back no more than mirror. User Agents should expect the PSAP to loop back no more than
3 packets of each media type accepted (which limits the duration of 3 packets of each media type accepted (which limits the duration of
the test), after which the PSAP would normally send BYE. the test), after which the PSAP would normally send BYE.
ED-84 User agents SHOULD perform a full call test, including media ED-84 User agents SHOULD perform a full call test, including media
skipping to change at page 21, line 34 skipping to change at page 21, line 45
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-13 (work in draft-ietf-geopriv-http-location-delivery-13 (work in
progress), February 2009. progress), February 2009.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-07 (work in progress), draft-ietf-geopriv-lis-discovery-08 (work in progress),
February 2009. March 2009.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), November 2008. (work in progress), November 2008.
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Hedayat, K., "An Extension to the Session Description Venna, N., Jones, P., Roychowdhury, A., and K. Hedayat,
Protocol (SDP) for Media Loopback", "An Extension to the Session Description Protocol (SDP)
draft-ietf-mmusic-media-loopback-09 (work in progress), for Media Loopback", draft-ietf-mmusic-media-loopback-10
August 2008. (work in progress), February 2009.
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007. October 2007.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-12 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
November 2008. March 2009.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-16 (work in progress), draft-ietf-sip-outbound-16 (work in progress),
October 2008. October 2008.
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Dec 2004. Dec 2004.
skipping to change at page 24, line 10 skipping to change at page 24, line 23
Format", RFC 4119, December 2005. Format", RFC 4119, 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
Protocol (SIP)", RFC 4916, June 2007.
[RFC4967] Rosen, B., "Dial String Parameter for the Session [RFC4967] Rosen, B., "Dial String Parameter for the Session
Initiation Protocol Uniform Resource Identifier", Initiation Protocol Uniform Resource Identifier",
RFC 4967, July 2007. RFC 4967, July 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
skipping to change at page 24, line 37 skipping to change at page 25, line 8
Protocol", RFC 5222, August 2008. Protocol", RFC 5222, August 2008.
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
Location-to-Service Translation (LoST) Servers Using the Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223, Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008. August 2008.
19.2. Informative References 19.2. Informative References
[I-D.barnes-geopriv-lo-sec] [I-D.barnes-geopriv-lo-sec]
Barnes, R., Lepinski, M., Tschofenig, H., and H. Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Schulzrinne, "Additional Location Privacy Considerations", Tschofenig, H., and H. Schulzrinne, "An Architecture for
draft-barnes-geopriv-lo-sec-04 (work in progress), Location and Location Privacy in Internet Applications",
January 2009. draft-barnes-geopriv-lo-sec-05 (work in progress),
March 2009.
[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-07 (work in Multimedia", draft-ietf-ecrit-framework-08 (work in
progress), January 2009. progress), February 2009.
[I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work
in progress), November 2008.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008. RFC 5012, January 2008.
skipping to change at page 30, line 44 skipping to change at page 31, line 11
emergency call without a Route header containing a PSAP URI. emergency call without a Route header containing a PSAP URI.
ED-57 [RFC3261] and [RFC3263] procedures MUST be used to route an ED-57 [RFC3261] and [RFC3263] procedures MUST be used to route an
emergency call towards the PSAP's URI. emergency call towards the PSAP's URI.
ED-58 Initial INVITES MUST provide an Offer [RFC3264]. ED-58 Initial INVITES MUST provide an Offer [RFC3264].
ED-59 deleted ED-59 deleted
ED-60 TLS MUST be specified when attempting to signal an emergency ED-60 TLS MUST be specified when attempting to signal an emergency
call with SIP per Section 3.1 of [I-D.ietf-sip-sips]. IPSEC call with SIP. IPSEC [RFC3986] is an acceptable alternative.
[RFC3986] is an acceptable alternative.
ED-61 If TLS session establishment fails, the call MUST be retried ED-61 If TLS session establishment is not available, or fails, the
without TLS. call MUST be retried without TLS.
ED-62 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent ED-62 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent
TLS connections between elements. TLS connections between elements.
ED-63 TLS MUST be specified when attempting to retrieve location ED-63 TLS MUST be specified 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-64 If TLS session establishment fails, the location retrieval MUST ED-64 If TLS session establishment fails, the location retrieval MUST
skipping to change at page 31, line 29 skipping to change at page 31, line 43
dial string URI with the dialed digits. dial string URI with the dialed digits.
3. The From header MUST be present and SHOULD be the AoR of the 3. The From header MUST be present and SHOULD be the AoR of the
caller. caller.
4. A Via header MUST be present. 4. A Via header MUST be present.
5. A Route header SHOULD be present with a PSAP URI obtained from 5. A Route header SHOULD be present with a PSAP URI obtained from
LoST (see Section 8) and the loose route parameter. If the LoST (see Section 8) and the loose route parameter. If the
device does not interpret dial plans, or was unable to obtain a device does not interpret dial plans, or was unable to obtain a
route from a LoST server, no Route header will be present. route from a LoST server, no Route header will be present.
6. A Contact header MUST be present which MUST be globally 6. A Contact header MUST be present which MUST be globally
routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid
for several minutes following the termination of the call to for several minutes following the termination of the call,
permit an immediate call-back to the specific device which provided that the UAC remains registered with the same
placed the emergency call. registrar, to permit an immediate call-back to the specific
device which placed the emergency call. It is acceptable if the
UAC inserts a locally routable URI and a subsequent B2BUA maps
that to a globally routable URI.
7. Other headers MAY be included as per normal SIP behavior. 7. Other headers MAY be included as per normal SIP behavior.
8. A Supported header MUST be included with the 'geolocation' 8. A Supported header MUST be included with the 'geolocation'
option tag [I-D.ietf-sip-location-conveyance], unless the device option tag [I-D.ietf-sip-location-conveyance], unless the device
does not understand the concept of SIP location. does not understand the concept of SIP location.
9. If a device understands the SIP location conveyance 9. If a device understands the SIP location conveyance
[I-D.ietf-sip-location-conveyance] extension and has its [I-D.ietf-sip-location-conveyance] extension and has its
location available, it MUST include location either by-value, location available, it MUST include location either by-value,
by-reference or both. by-reference or both.
10. If a device understands the SIP Location Conveyance extension 10. If a device understands the SIP Location Conveyance extension
and has its location unavailable or unknown to that device, it and has its location unavailable or unknown to that device, it
MUST include a Supported header with a "geolocation" option tag, MUST include a Supported header with a "geolocation" option tag,
skipping to change at page 32, line 29 skipping to change at page 32, line 48
requested language. SIP Caller Preferences may also be used to requested language. SIP Caller Preferences may also be used to
indicate a need to invoke a relay service for communication with indicate a need to invoke a relay service for communication with
people with disabilities in the call. people with disabilities in the call.
ED-66 Devices device SHOULD have a globally routable URI in a ED-66 Devices device SHOULD have a globally routable URI in a
Contact: header which remains valid for 30 minutes past the time the Contact: header which remains valid for 30 minutes past the time the
original call containing the URI completes unless the device original call containing the URI completes unless the device
registration expires and is not renewed. registration expires and is not renewed.
ED-67 During the course of an emergency call, devices and proxies ED-67 During the course of an emergency call, devices and proxies
MUST support REFER transactions and the Referred-by: header MUST support REFER transactions with method=INVITE and the
[RFC3515]. Referred-by: header [RFC3515] in that transaction.
ED-68 deleted ED-68 deleted
ED-69 There can be a case where the session signaling path is lost, ED-69 There can be a case where the session signaling path is lost,
and the user agent does not receive the BYE. If the call is hung up, and the user agent does not receive the BYE. If the call is hung up,
and the session timer (if implemented) expires, the call MAY be and the session timer (if implemented) expires, the call MAY be
declared lost. If in the interval, an incoming call is received from declared lost. If in the interval, an incoming call is received from
the domain of the PSAP, the device MUST drop the old call and alert the domain of the PSAP, the device MUST drop the old call and alert
for the (new) incoming call. Dropping of the old call MUST only for the (new) incoming call. Dropping of the old call MUST only
occur if the user is attempting to hang up; the domain of an incoming occur if the user is attempting to hang up; the domain of an incoming
call can only be determined from the From header, which is not call can only be determined from the From header, which is not
reliable, and could be spoofed. Dropping an active call by a new reliable, and could be spoofed. Dropping an active call by a new
call with a spoofed From: would be a DoS attack. call with a spoofed From: would be a DoS attack.
skipping to change at page 32, line 45 skipping to change at page 33, line 15
and the user agent does not receive the BYE. If the call is hung up, and the user agent does not receive the BYE. If the call is hung up,
and the session timer (if implemented) expires, the call MAY be and the session timer (if implemented) expires, the call MAY be
declared lost. If in the interval, an incoming call is received from declared lost. If in the interval, an incoming call is received from
the domain of the PSAP, the device MUST drop the old call and alert the domain of the PSAP, the device MUST drop the old call and alert
for the (new) incoming call. Dropping of the old call MUST only for the (new) incoming call. Dropping of the old call MUST only
occur if the user is attempting to hang up; the domain of an incoming occur if the user is attempting to hang up; the domain of an incoming
call can only be determined from the From header, which is not call can only be determined from the From header, which is not
reliable, and could be spoofed. Dropping an active call by a new reliable, and could be spoofed. Dropping an active call by a new
call with a spoofed From: would be a DoS attack. call with a spoofed From: would be a DoS attack.
ED-70 User Agents and proxies MUST disable outgoing call features ED-70 User Agents and proxies MUST disable features that will
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 Flash hold o Hold
o Outbound Call Blocking o Outbound Call Blocking
when an emergency call is established. Also see ED-77 in Section 14. when an emergency call is established. Also see ED-77 in Section 14.
ED-71 The emergency dial strings SHOULD NOT be permitted in Call ED-71 The emergency dial strings SHOULD NOT be permitted in Call
Forward numbers or speed dial lists. Forward numbers or speed dial lists.
ED-72 The User Agent and Proxies SHOULD disable the following ED-72 The User Agent and Proxies MUST disable call features which
incoming call features on call backs from the PSAP: would interfere with the ability of call backs from the PSAP to be
o Call Waiting completed such as:
o Do Not Disturb o Do Not Disturb
o Call Forward (all kinds) o Call Forward (all kinds)
ED-73 Call backs SHOULD be determined by retaining the domain of the ED-73 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
the PSAP. Recognizing a call back from the domain of the PSAP will
not always work, and further standardization will be required to give
the UA the ability to recognize a call back.
ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550]. ED-74 Endpoints MUST send and receive media streams on RTP [RFC3550].
ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to ED-75 Normal SIP offer/answer [RFC3264] negotiations MUST be used to
agree on the media streams to be used. agree on the media streams to be used.
ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law ED-76 Endpoints supporting voice MUST support G.711 A law (and mu Law
if they are intended be used in North America) encoded voice as if they are intended be used in North America) encoded voice as
described in [RFC3551]. It is desirable to include wideband codecs described in [RFC3551]. It is desirable to include wideband codecs
such as AMR-WB in the offer. such as AMR-WB in the offer.
skipping to change at page 34, line 16 skipping to change at page 34, line 37
ED-82 In its response to the test, the PSAP MAY include a text body ED-82 In its response to the test, the PSAP MAY include a text body
(text/plain) indicating the identity of the PSAP, the requested (text/plain) indicating the identity of the PSAP, the requested
service, and the location reported with the call. For the latter, service, and the location reported with the call. For the latter,
the PSAP SHOULD return location-by-value even if the original the PSAP SHOULD return location-by-value even if the original
location delivered with the test was by-reference. If the location- location delivered with the test was by-reference. If the location-
by-reference was supplied, and the dereference requires credentials, by-reference was supplied, and the dereference requires credentials,
the PSAP SHOULD use credentials supplied by the LIS for test the PSAP SHOULD use credentials supplied by the LIS for test
purposes. This alerts the LIS that the dereference is not for an purposes. This alerts the LIS that the dereference is not for an
actual emergency call and location hiding techniques, if they are actual emergency call and location hiding techniques, if they are
being used, may be employed for this dereference. The test response being used, may be employed for this dereference. Use of SIPS for
SHOULD be protected with TLS. If the body cannot be protected, the the request would assure the response containing the location is kept
location SHOULD NOT be included in the response. private.
ED-83 A PSAP accepting a test call SHOULD accept a media loopback ED-83 A PSAP accepting a test call SHOULD accept a media loopback
test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-
pkt-loopback" and "rtp-start-loopback" options. The user agent would pkt-loopback" and "rtp-start-loopback" options. The user agent would
specify a loopback attribute of "loopback-source", the PSAP being the specify a loopback attribute of "loopback-source", the PSAP being the
mirror. User Agents should expect the PSAP to loop back no more than mirror. User Agents should expect the PSAP to loop back no more than
3 packets of each media type accepted (which limits the duration of 3 packets of each media type accepted (which limits the duration of
the test), after which the PSAP would normally send BYE. the test), after which the PSAP would normally send BYE.
ED-84 User agents SHOULD perform a full call test, including media ED-84 User agents SHOULD perform a full call test, including media
skipping to change at page 37, line 30 skipping to change at page 37, line 50
SP-29 A proxy server which attempts mapping and fails to get a SP-29 A proxy server which attempts mapping and fails to get a
mapping MUST provide a default mapping. A suitable default mapping mapping MUST provide a default mapping. A suitable default mapping
would be the mapping obtained previously for the default location would be the mapping obtained previously for the default location
appropriate for the caller. appropriate for the caller.
SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route an SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route an
emergency call towards the PSAP's URI. emergency call towards the PSAP's URI.
SP-31 TLS MUST be specified when attempting to signal an emergency SP-31 TLS MUST be specified when attempting to signal an emergency
call with SIP per Section 3.1 of [I-D.ietf-sip-sips]. IPSEC call with SIP. IPSEC [RFC3986] is an acceptable alternative.
[RFC3986] is an acceptable alternative.
SP-32 If TLS session establishment fails, the call MUST be retried SP-32 If TLS session establishment is not available, or fails, the
without TLS. call MUST be retried without TLS.
SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent
TLS connections between elements. TLS connections between elements.
SP-34 SIP Proxy servers processing emergency calls: SP-34 SIP Proxy servers processing emergency calls:
1. If the proxy interprets dial plans on behalf of user agents, the 1. If the proxy interprets dial plans on behalf of user agents, the
proxy MUST look for the local emergency dial string at the proxy MUST look for the local emergency dial string at the
location of the end device and MAY look for the home dial string. location of the end device and MAY look for the home dial string.
If it finds it, the proxy MUST: If it finds it, the proxy MUST:
* Insert a Geolocation header as above. Location-by-reference * Insert a Geolocation header as above. Location-by-reference
skipping to change at page 38, line 48 skipping to change at page 39, line 18
features or services that would normally cause the call to be routed features or services that would normally cause the call to be routed
to some other entity. to some other entity.
SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted-
Identity: header or From: protected by an Identity header suitable Identity: header or From: protected by an Identity header suitable
for returning a call some time after the original call. Such a call for returning a call some time after the original call. Such a call
back would not necessarily reach the device that originally placed back would not necessarily reach the device that originally placed
the call. the call.
SP-38 During the course of an emergency call, devices and proxies SP-38 During the course of an emergency call, devices and proxies
MUST support REFER transactions and the Referred-by: header MUST support REFER transactions with method=INVITE and the
[RFC3515]. Referred-by: header [RFC3515] in that transaction.
SP-39 User Agents and proxies MUST disable outgoing call features SP-39 User Agents and proxies MUST disable features that will
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 Flash hold o Hold
o Outbound Call Blocking o Outbound Call Blocking
when an emergency call is established. Also see ED-77 in Section 14. when an emergency call is established. Also see ED-77 in Section 14.
SP-40 The emergency dial strings SHOULD NOT be permitted in Call SP-40 The emergency dial strings SHOULD NOT be permitted in Call
Forward numbers or speed dial lists. Forward numbers or speed dial lists.
SP-41 The User Agent and Proxies SHOULD disable the following SP-41 The User Agent and Proxies MUST disable call features which
incoming call features on call backs from the PSAP: would interfere with the ability of call backs from the PSAP to be
o Call Waiting completed such as:
o Do Not Disturb o Do Not Disturb
o Call Forward (all kinds) o Call Forward (all kinds)
A.3. Requirements of Access Network A.3. Requirements of Access Network
AN-1 LoST servers MUST return dial strings for emergency services AN-1 LoST servers MUST return dial strings for emergency services
AN-2 Elements MUST NOT convert (civic to geo or geo to civic) from AN-2 Elements MUST NOT convert (civic to geo or geo to civic) from
the form of location the determination mechanism supplied. the form of location the determination mechanism supplied.
 End of changes. 46 change blocks. 
82 lines changed or deleted 103 lines changed or added

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