draft-ietf-ecrit-phonebcp-09.txt   draft-ietf-ecrit-phonebcp-10.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: BCP J. Polk Intended status: BCP J. Polk
Expires: September 28, 2009 Cisco Systems Expires: December 6, 2009 Cisco Systems
March 27, 2009 June 4, 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-09 draft-ietf-ecrit-phonebcp-10
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 September 28, 2009. This Internet-Draft will expire on December 6, 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 31 skipping to change at page 2, line 31
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 in SIP . . . . . . . . . . . . . . . . 11 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 12
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 13 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . 16 9.2. SIP signaling requirements for User Agents . . . . . . . . 15
9.3. SIP signaling requirements for proxy servers . . . . . . . 17 9.3. SIP signaling requirements for proxy servers . . . . . . . 17
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . 25 19.2. Informative References . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . 35 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",
skipping to change at page 12, line 8 skipping to change at page 12, line 8
device moved. device moved.
ED-38 If location was sent by value, and the endpoint gets updated ED-38 If location was sent by value, and the endpoint gets updated
location, it MUST send the updated location to the PSAP via a SIP re- location, it MUST send the updated location to the PSAP via a SIP re-
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. than one update every 10 seconds.
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 use the procedures in [I-D.ietf-geopriv-pdif-lo-profile] MUST use the procedures in [RFC5491]
ED-40 If a UA has more than one location available to it, it MUST ED-40 If a UA has more than one location available to it, it MUST
choose one location to route the call towards the PSAP. If multiple choose one location to route the call towards the PSAP. If multiple
locations are in a single PIDF, the procedures in locations are in a single PIDF, the procedures in [RFC5491] MUST be
[I-D.ietf-geopriv-pdif-lo-profile] MUST be followed. If the UA has followed. If the UA has multiple PIDFs, and has no reasonable basis
multiple PIDFs, and has no reasonable basis to choose from among to choose from among them, a random choice is acceptable.
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. location to use to route the call towards the PSAP.
SP-18 If a proxy is attempting to insert location but the UA conveyed SP-18 If a proxy is attempting to insert location but the UA conveyed
a location to it, the proxy MUST use the UA's location for routing a location to it, the proxy MUST use the UA's location for routing
and MUST convey that location towards the PSAP. It MAY also include and MUST convey that location towards the PSAP. It MAY also include
what it believes the location to be in a separate Geolocation header. what it believes the location to be in a separate Geolocation header.
skipping to change at page 17, line 4 skipping to change at page 16, line 49
11. If a device understands the SIP Location Conveyance extension 11. If a device understands the SIP Location Conveyance extension
and supports LoST [RFC5222], the Geolocation "used-for-routing" and supports LoST [RFC5222], the Geolocation "used-for-routing"
header parameter MUST be added to the corresponding URI in the header parameter MUST be added to the corresponding URI in the
Geolocation header. If the device is unable to obtain a PSAP Geolocation header. If the device is unable to obtain a PSAP
URI for any reason it MUST NOT include "used-for-routing" on a URI for any reason it MUST NOT include "used-for-routing" on a
Geolocation URI, so that downstream entities know that LoST Geolocation URI, so that downstream entities know that LoST
routing has not been completed. routing has not been completed.
12. A SDP offer MUST be included in the INVITE. If voice is 12. A SDP offer MUST be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see supported the offer MUST include the G.711 codec, see
Section 14. Section 14.
13. If the device includes location-by-value, the UA MUST support 13. If the device includes location-by-value, the UA MUST support
multipart message bodies, since SDP will likely be also in the multipart message bodies, since SDP will likely be also in the
INVITE. INVITE.
14. A UAC SHOULD include a "inserted-by=endpoint" header parameter
on all Geolocation headers. This informs downstream elements 14. A UAC SHOULD include a "inserted-by" header parameter with its
which device entered the location at this URI (either cid-URL or own hostname on all Geolocation headers. This informs
location-by-reference URI). downstream elements which device entered the location at this
URI (either cid-URL or location-by-reference URI).
15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the
PSAP should handle the call. For example, a language preference PSAP should handle the call. For example, a language preference
expressed in an Accept-Language header may be used as a hint to expressed in an Accept-Language header may be used as a hint to
cause the PSAP to route the call to a call taker who speaks the cause the PSAP to route the call to a call taker who speaks the
requested language. 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.
9.3. SIP signaling requirements for proxy servers 9.3. SIP signaling requirements for proxy servers
SP-34 SIP Proxy servers processing emergency calls: SP-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
MUST be used because proxies must not insert bodies. MUST be used because proxies must not insert bodies.
* Include the Geolocation "inserted-by=server" and "used-for- * Include the Geolocation "inserted-by" and "used-for-routing"
routing" parameters. parameters with its own hostname (which should match the Via
it inserts) on the inserted-by.
* Map the location to a PSAP URI using LoST. * Map the location to a PSAP URI using LoST.
* Add a Route header with the PSAP URI. * Add a Route header with the PSAP URI.
* Replace the Request-URI (which was the dial string) with the * Replace the Request-URI (which was the dial string) with the
service URN appropriate for the emergency dial string. service URN appropriate for the emergency dial string.
* Route the call using normal SIP routing mechanisms. * Route the call using normal SIP routing mechanisms.
2. If the proxy recognizes the service URN in the Request URI, and 2. If the proxy recognizes the service URN in the Request URI, and
does not find a a Route header, it MUST query a LoST server. If does not find a a Route header, it MUST query a LoST server. If
multiple locations were provided, the proxy uses the location multiple locations were provided, the proxy uses the location
that has the "used-for-routing" marker set. If a location was that has the "used-for-routing" marker set. If a location was
provided (which should be the case), the proxy uses that location provided (which should be the case), the proxy uses that location
to query LoST. The proxy may have to dereference a location by to query LoST. The proxy may have to dereference a location by
reference to get a value. If a location is not present, and the reference to get a value. If a location is not present, and the
proxy can query a LIS which has the location of the UA it MUST do proxy can query a LIS which has the location of the UA it MUST do
so. If no location is present, and the proxy does not have so. If no location is present, and the proxy does not have
access to a LIS which could provide location, the proxy MUST access to a LIS which could provide location, the proxy MUST
supply a default location (See Section 6.11). The location (in supply a default location (See Section 6.11). The location (in
the signaling, obtained from a LIS, or default) MUST be used in a the signaling, obtained from a LIS, or default) MUST be used in a
query to LoST with the service URN received with the call. The query to LoST with the service URN received with the call. The
resulting URI MUST be placed in a Route header added to the call. resulting URI MUST be placed in a Route header added to the call.
3. The "inserted-by=" parameter in any Geolocation: header received 3. The "inserted-by" parameter in any Geolocation: header received
on the call MUST NOT be modified or deleted in transit. on the call MUST NOT be modified or deleted in transit.
4. The proxy SHOULD NOT modify any parameters in Geolocation headers 4. The proxy SHOULD NOT modify any parameters in Geolocation headers
received in the call. It MAY add a Geolocation header. Such an received in the call. It MAY add a Geolocation header. Such an
additional location SHOULD NOT be used for routing; the location additional location SHOULD NOT be used for routing; the location
provided by the UA should be used. provided by the UA should be used.
5. Either a P-Asserted-Identity [RFC3325] or an Identity header 5. Either a P-Asserted-Identity [RFC3325] or an Identity header
[RFC4474], or both, SHOULD be included to identify the sender. [RFC4474], or both, SHOULD be included to identify the sender.
For services which must support emergency calls from For services which must support emergency calls from
unauthenticated devices, valid identity may not be available. unauthenticated devices, valid identity may not be available.
10. Call backs 10. Call backs
skipping to change at page 21, line 39 skipping to change at page 21, line 34
Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom,
Barbara Stark, Richard Barnes and Peter Blatherwick. Barbara Stark, Richard Barnes and Peter Blatherwick.
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-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-14 (work in
progress), February 2009. progress), May 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-08 (work in progress), draft-ietf-geopriv-lis-discovery-11 (work in progress),
March 2009. May 2009.
[I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), November 2008.
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Venna, N., Jones, P., Roychowdhury, A., and K. Hedayat, Venna, N., Jones, P., Roychowdhury, A., and K. Hedayat,
"An Extension to the Session Description Protocol (SDP) "An Extension to the Session Description Protocol (SDP)
for Media Loopback", draft-ietf-mmusic-media-loopback-10 for Media Loopback", draft-ietf-mmusic-media-loopback-10
(work in progress), February 2009. (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-13 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009. March 2009.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C., "Managing Client Initiated Connections in
Connections in the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-16 (work in progress), draft-ietf-sip-outbound-19 (work in progress), June 2009.
October 2008.
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Dec 2004. Dec 2004.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 25, line 5 skipping to change at page 24, line 37
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
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.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
19.2. Informative References 19.2. Informative References
[I-D.barnes-geopriv-lo-sec] [I-D.barnes-geopriv-lo-sec]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-barnes-geopriv-lo-sec-05 (work in progress), draft-barnes-geopriv-lo-sec-05 (work in progress),
March 2009. 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-08 (work in Multimedia", draft-ietf-ecrit-framework-09 (work in
progress), February 2009. progress), March 2009.
[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 29, line 21 skipping to change at page 29, line 11
reference schemes that do not support subscription, the PSAP will reference schemes that do not support subscription, the PSAP will
have to repeatedly dereference the URI to determine if the device have to repeatedly dereference the URI to determine if the device
moved. moved.
ED-38 If location was sent by value, and the endpoint gets updated ED-38 If location was sent by value, and the endpoint gets updated
location, it MUST send the updated location to the PSAP via a SIP re- location, it MUST send the updated location to the PSAP via a SIP re-
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. than one update every 10 seconds.
ED-39 If the LIS has more than one location for an endpoint it MUST ED-39 If the LIS has more than one location for an endpoint it MUST
use the procedures in [I-D.ietf-geopriv-pdif-lo-profile] use the procedures in [RFC5491]
ED-40 If a UA has more than one location available to it, it MUST ED-40 If a UA has more than one location available to it, it MUST
choose one location to route the call towards the PSAP. If multiple choose one location to route the call towards the PSAP. If multiple
locations are in a single PIDF, the procedures in locations are in a single PIDF, the procedures in [RFC5491] MUST be
[I-D.ietf-geopriv-pdif-lo-profile] MUST be followed. If the UA has followed. If the UA has multiple PIDFs, and has no reasonable basis
multiple PIDFs, and has no reasonable basis to choose from among to choose from among them, a random choice is acceptable.
them, a random choice is acceptable.
ED-41 Location objects MUST contain information about the method by ED-41 Location objects MUST contain information about the method by
which the location was determined, such as GPS, manually entered, or which the location was determined, such as GPS, manually entered, or
based on access network topology included in a PIDF- LO "method" based on access network topology included in a PIDF- LO "method"
element. In addition, the source of the location information MUST be element. In addition, the source of the location information MUST be
included in a PIDF-LO "provided-by" element. included in a PIDF-LO "provided-by" element.
ED-42 The "used-for-routing" parameter MUST be set to the location ED-42 The "used-for-routing" parameter MUST be set to the location
that was chosen for routing. that was chosen for routing.
skipping to change at page 32, line 30 skipping to change at page 32, line 18
Geolocation header. If the device is unable to obtain a PSAP Geolocation header. If the device is unable to obtain a PSAP
URI for any reason it MUST NOT include "used-for-routing" on a URI for any reason it MUST NOT include "used-for-routing" on a
Geolocation URI, so that downstream entities know that LoST Geolocation URI, so that downstream entities know that LoST
routing has not been completed. routing has not been completed.
12. A SDP offer MUST be included in the INVITE. If voice is 12. A SDP offer MUST be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see supported the offer MUST include the G.711 codec, see
Section 14. Section 14.
13. If the device includes location-by-value, the UA MUST support 13. If the device includes location-by-value, the UA MUST support
multipart message bodies, since SDP will likely be also in the multipart message bodies, since SDP will likely be also in the
INVITE. INVITE.
14. A UAC SHOULD include a "inserted-by=endpoint" header parameter 14. A UAC SHOULD include a "inserted-by" header parameter with its
on all Geolocation headers. This informs downstream elements own hostname on all Geolocation headers. This informs
which device entered the location at this URI (either cid-URL or downstream elements which device entered the location at this
location-by-reference URI). URI (either cid-URL or location-by-reference URI).
15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the
PSAP should handle the call. For example, a language preference PSAP should handle the call. For example, a language preference
expressed in an Accept-Language header may be used as a hint to expressed in an Accept-Language header may be used as a hint to
cause the PSAP to route the call to a call taker who speaks the cause the PSAP to route the call to a call taker who speaks the
requested language. 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
skipping to change at page 36, line 32 skipping to change at page 36, line 20
"emergencyRouting" for the "responseTime" parameter and use the "emergencyRouting" for the "responseTime" parameter and use the
resulting location for routing. If a value for dispatch location resulting location for routing. If a value for dispatch location
will be sent, another request with the "responseTime" parameter set will be sent, another request with the "responseTime" parameter set
to "emergencyDispatch" must be completed, with the result sent for to "emergencyDispatch" must be completed, with the result sent for
dispatch purposes. dispatch purposes.
SP-15 Location sent between SIP elements MUST be conveyed using SP-15 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sip-location-conveyance]. [I-D.ietf-sip-location-conveyance].
SP-16 If the LIS has more than one location for an endpoint it MUST SP-16 If the LIS has more than one location for an endpoint it MUST
use the procedures in [I-D.ietf-geopriv-pdif-lo-profile] use the procedures in [RFC5491]
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. location to use to route the call towards the PSAP.
SP-18 If a proxy is attempting to insert location but the UA conveyed SP-18 If a proxy is attempting to insert location but the UA conveyed
a location to it, the proxy MUST use the UA's location for routing a location to it, the proxy MUST use the UA's location for routing
and MUST convey that location towards the PSAP. It MAY also include and MUST convey that location towards the PSAP. It MAY also include
what it believes the location to be in a separate Geolocation header. what it believes the location to be in a separate Geolocation header.
skipping to change at page 38, line 16 skipping to change at page 38, line 4
call MUST be retried 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
MUST be used because proxies must not insert bodies. MUST be used because proxies must not insert bodies.
* Include the Geolocation "inserted-by=server" and "used-for- * Include the Geolocation "inserted-by" and "used-for-routing"
routing" parameters. parameters with its own hostname (which should match the Via
it inserts) on the inserted-by.
* Map the location to a PSAP URI using LoST. * Map the location to a PSAP URI using LoST.
* Add a Route header with the PSAP URI. * Add a Route header with the PSAP URI.
* Replace the Request-URI (which was the dial string) with the * Replace the Request-URI (which was the dial string) with the
service URN appropriate for the emergency dial string. service URN appropriate for the emergency dial string.
* Route the call using normal SIP routing mechanisms. * Route the call using normal SIP routing mechanisms.
2. If the proxy recognizes the service URN in the Request URI, and 2. If the proxy recognizes the service URN in the Request URI, and
does not find a a Route header, it MUST query a LoST server. If does not find a a Route header, it MUST query a LoST server. If
multiple locations were provided, the proxy uses the location multiple locations were provided, the proxy uses the location
that has the "used-for-routing" marker set. If a location was that has the "used-for-routing" marker set. If a location was
provided (which should be the case), the proxy uses that location provided (which should be the case), the proxy uses that location
to query LoST. The proxy may have to dereference a location by to query LoST. The proxy may have to dereference a location by
reference to get a value. If a location is not present, and the reference to get a value. If a location is not present, and the
proxy can query a LIS which has the location of the UA it MUST do proxy can query a LIS which has the location of the UA it MUST do
so. If no location is present, and the proxy does not have so. If no location is present, and the proxy does not have
access to a LIS which could provide location, the proxy MUST access to a LIS which could provide location, the proxy MUST
supply a default location (See Section 6.11). The location (in supply a default location (See Section 6.11). The location (in
the signaling, obtained from a LIS, or default) MUST be used in a the signaling, obtained from a LIS, or default) MUST be used in a
query to LoST with the service URN received with the call. The query to LoST with the service URN received with the call. The
resulting URI MUST be placed in a Route header added to the call. resulting URI MUST be placed in a Route header added to the call.
3. The "inserted-by=" parameter in any Geolocation: header received 3. The "inserted-by" parameter in any Geolocation: header received
on the call MUST NOT be modified or deleted in transit. on the call MUST NOT be modified or deleted in transit.
4. The proxy SHOULD NOT modify any parameters in Geolocation headers 4. The proxy SHOULD NOT modify any parameters in Geolocation headers
received in the call. It MAY add a Geolocation header. Such an received in the call. It MAY add a Geolocation header. Such an
additional location SHOULD NOT be used for routing; the location additional location SHOULD NOT be used for routing; the location
provided by the UA should be used. provided by the UA should be used.
5. Either a P-Asserted-Identity [RFC3325] or an Identity header 5. Either a P-Asserted-Identity [RFC3325] or an Identity header
[RFC4474], or both, SHOULD be included to identify the sender. [RFC4474], or both, SHOULD be included to identify the sender.
For services which must support emergency calls from For services which must support emergency calls from
unauthenticated devices, valid identity may not be available. unauthenticated devices, valid identity may not be available.
 End of changes. 25 change blocks. 
50 lines changed or deleted 48 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/