< draft-ietf-ecrit-framework-11.txt   draft-ietf-ecrit-framework-12.txt >
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: January 14, 2011 Columbia U. Expires: April 28, 2011 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
July 13, 2010 October 25, 2010
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-11 draft-ietf-ecrit-framework-12
Abstract Abstract
The IETF has standardized various aspects of placing emergency calls. The IETF has standardized various aspects of placing emergency calls.
This document describes how all of those component parts are used to This document describes how all of those component parts are used to
support emergency calls from citizens and visitors to authorities. support emergency calls from citizens and visitors to authorities.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
6.2.3. End-system measured location information . . . . . . . 18 6.2.3. End-system measured location information . . . . . . . 18
6.2.4. Network measured location information . . . . . . . . 19 6.2.4. Network measured location information . . . . . . . . 19
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19
6.4. Location and references to location . . . . . . . . . . . 20 6.4. Location and references to location . . . . . . . . . . . 20
6.5. End system location configuration . . . . . . . . . . . . 20 6.5. End system location configuration . . . . . . . . . . . . 20
6.6. When location should be configured . . . . . . . . . . . . 22 6.6. When location should be configured . . . . . . . . . . . . 22
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 23 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 23
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 24 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 24
6.10. Location validation . . . . . . . . . . . . . . . . . . . 25 6.10. Location validation . . . . . . . . . . . . . . . . . . . 25
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 26 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25
6.12. Location format conversion . . . . . . . . . . . . . . . . 26 6.12. Location format conversion . . . . . . . . . . . . . . . . 26
7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 26 7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 26
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. SIP signaling requirements for User Agents . . . . . . . . 29 9.2. SIP signaling requirements for User Agents . . . . . . . . 29
9.3. SIP signaling requirements for proxy servers . . . . . . . 29 9.3. SIP signaling requirements for proxy servers . . . . . . . 29
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 31 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 31 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 31
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 31 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 31
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
19. Informative References . . . . . . . . . . . . . . . . . . . . 33 19. Informative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Terminology 1. Terminology
This document uses terms from [RFC3261], [RFC5222] and [RFC5012]. In This document uses terms from [RFC3261], [RFC5222] and [RFC5012]. In
addition the following terms are used: addition the following terms are used:
Access network: The access network supplies IP packet service to an Access network: The access network supplies IP packet service to an
endpoint. Examples of access networks include digital subscriber endpoint. Examples of access networks include digital subscriber
lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local
area networks and cellular data networks. area networks and cellular data networks.
Confidence: Confidence is an estimate indicating how sure the Confidence: Confidence is an estimate indicating how sure the
skipping to change at page 8, line 8 skipping to change at page 8, line 8
proxy for a group of PSAPs. The call arrives at the PSAP with the proxy for a group of PSAPs. The call arrives at the PSAP with the
location included in the INVITE request. location included in the INVITE request.
The following is a quick overview for a typical Ethernet connected The following is a quick overview for a typical Ethernet connected
telephone using SIP signaling. It illustrates one set of choices for telephone using SIP signaling. It illustrates one set of choices for
various options presented later in this document. various options presented later in this document.
o The phone "boots" and connects to its access network. o The phone "boots" and connects to its access network.
o The phone gets location via a Location Configuration Protocol o The phone gets location via a Location Configuration Protocol
(LCP), for example from the DHCP server in civic [RFC4776] and/or (LCP), for example from the DHCP server in civic [RFC4776] and/or
geo [RFC3825] forms, a HELD server geo [RFC3825] forms, a HELD server [RFC5985] or the first level
[I-D.ietf-geopriv-http-location-delivery] or the first level
switch's LLDP server [LLDP]. switch's LLDP server [LLDP].
o The phone obtains the local emergency dial string(s) from the LoST o The phone obtains the local emergency dial string(s) from the LoST
[RFC5222] server for its current location. It also receives and [RFC5222] server for its current location. It also receives and
caches the PSAP URI obtained from the LoST server. caches the PSAP URI obtained from the LoST server.
o Some time later, the user places an emergency call. The phone o Some time later, the user places an emergency call. The phone
recognizes an emergency call from the dial strings and uses the recognizes an emergency call from the dial strings and uses the
"urn:service:sos" [RFC5031] URN to mark an emergency call. "urn:service:sos" [RFC5031] URN to mark an emergency call.
o It refreshes its location via DHCP and updates the PSAP's URI by o It refreshes its location via DHCP and updates the PSAP's URI by
querying the LoST mapping server with its location. querying the LoST mapping server with its location.
o It puts its location in the SIP INVITE request in a Geolocation o It puts its location in the SIP INVITE request in a Geolocation
skipping to change at page 13, line 35 skipping to change at page 13, line 35
This may be difficult in situations where the user can roam or be This may be difficult in situations where the user can roam or be
nomadic. Endpoint recognition of emergency dial strings is therefore nomadic. Endpoint recognition of emergency dial strings is therefore
preferred. If a service provider is unable to guarantee that it can preferred. If a service provider is unable to guarantee that it can
correctly determine local emergency dialstrings, wherever its correctly determine local emergency dialstrings, wherever its
subscribers may be, then it is required that the endpoint do the subscribers may be, then it is required that the endpoint do the
recognition. recognition.
Note: The emergency call practitioners consider it undesirable to Note: The emergency call practitioners consider it undesirable to
have a single button emergency call user interface element. These have a single button emergency call user interface element. These
mechanisms tend to result in a very high rate of false or accidental mechanisms tend to result in a very high rate of false or accidental
emergency calls. In order to minimize this rate, practitioners emergency calls. In order to minimize this issue, practitioners
recommend that device should only initiate emergency calls based on recommend that device should only initiate emergency calls based on
entry of specific emergency call dial strings. Speed dial mechanisms entry of specific emergency call dial strings. Speed dial mechanisms
may effectively create single button emergency call invocation and may effectively create single button emergency call invocation and
practitioners recommend they not be permitted. practitioners recommend they not be permitted.
6. Location and its role in an emergency call 6. Location and its role in an emergency call
Location is central to the operation of emergency services. Location Location is central to the operation of emergency services. Location
is used for two purposes in emergency call handling: routing of the is used for two purposes in emergency call handling: routing of the
call and dispatch of responders. It is frequently the case that the call and dispatch of responders. It is frequently the case that the
skipping to change at page 20, line 43 skipping to change at page 20, line 43
6.5. End system location configuration 6.5. End system location configuration
Unless a user agent has access to provisioned or locally measured Unless a user agent has access to provisioned or locally measured
location information, it must obtain it from the access network. location information, it must obtain it from the access network.
There are several location configuration protocols (LCPs) that can be There are several location configuration protocols (LCPs) that can be
used for this purpose including DHCP, HELD and LLDP: used for this purpose including DHCP, HELD and LLDP:
DHCP can deliver civic [RFC4776] or geospatial [RFC3825] DHCP can deliver civic [RFC4776] or geospatial [RFC3825]
information. User agents need to support both formats. Note that information. User agents need to support both formats. Note that
a user agent can use DHCP, via the DHCP REQUEST or INFORM a user agent can use DHCP, via the DHCP REQUEST or INFORM
messages, even if it uses other means to acquire its IP address. messages, even if it uses other means to acquire its IP address.
HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a civic HELD [RFC5985] can deliver a civic or geo location object, by value
or geo location object, by value or by reference, via a layer 7 or by reference, via a layer 7 protocol. The query typically uses
protocol. The query typically uses the IP address of the the IP address of the requester as an identifier and returns the
requester as an identifier and returns the location value or location value or reference associated with that identifier. HELD
reference associated with that identifier. HELD is typically is typically carried in HTTP.
carried in HTTP.
Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device
extensions [LLDP-MED] can be used to deliver location information extensions [LLDP-MED] can be used to deliver location information
directly from the Layer 2 network infrastructure, and also directly from the Layer 2 network infrastructure, and also
supports both civic and geo formats identical in format to DHCP supports both civic and geo formats identical in format to DHCP
methods. methods.
Each LCP has limitations in the kinds of networks that can reasonably Each LCP has limitations in the kinds of networks that can reasonably
support it. For this reason, it is not possible to choose a single support it. For this reason, it is not possible to choose a single
mandatory-to-deploy LCP. For endpoints with common network mandatory-to-deploy LCP. For endpoints with common network
skipping to change at page 24, line 35 skipping to change at page 24, line 35
as such (per [I-D.ietf-sip-location-conveyance], and send it as well as such (per [I-D.ietf-sip-location-conveyance], and send it as well
as any others it has. as any others it has.
The UA or proxy should have the ability to understand how and from The UA or proxy should have the ability to understand how and from
whom it learned its location, and should include this information in whom it learned its location, and should include this information in
the location objects that are sent to the PSAP. That labeling the location objects that are sent to the PSAP. That labeling
provides the call-taker with information to make decisions upon, as provides the call-taker with information to make decisions upon, as
well as guidance for what to ask the caller and what to tell the well as guidance for what to ask the caller and what to tell the
responders. responders.
The call must indicate the location information that has been used
for routing, so that the same location information is used for all
call routing decisions. The location conveyance mechanism
[I-D.ietf-sip-location-conveyance] contains a parameter for this
purpose.
Endpoints or proxies may be tempted to send multiple versions of the Endpoints or proxies may be tempted to send multiple versions of the
same location. For example a database may be used to "geocode" or same location. For example a database may be used to "geocode" or
"reverse geocode", that is, convert from civic to geo or vice versa. "reverse geocode", that is, convert from civic to geo or vice versa.
It is very problematic to use derived locations in emergency calls. It is very problematic to use derived locations in emergency calls.
The PSAP and the responders have very accurate databases which they The PSAP and the responders have very accurate databases which they
use to convert, most commonly from a reported geo to a civic suitable use to convert, most commonly from a reported geo to a civic suitable
for dispatching responders. If one database is used to convert from, for dispatching responders. If one database is used to convert from,
say, civic to geo, and another converts from geo to civic, errors say, civic to geo, and another converts from geo to civic, errors
will often occur where the databases are slightly different. "Off by will often occur where the databases are slightly different. "Off by
one" errors are serious when responders go to the wrong location. one" errors are serious when responders go to the wrong location.
skipping to change at page 26, line 27 skipping to change at page 26, line 19
6.12. Location format conversion 6.12. Location format conversion
The endpoint is responsible for mapping any form of location it The endpoint is responsible for mapping any form of location it
receives from an LCP into PIDF-LO form if the LCP did not directly receives from an LCP into PIDF-LO form if the LCP did not directly
return a PIDF-LO. return a PIDF-LO.
7. LIS and LoST discovery 7. LIS and LoST discovery
Endpoints must be able to discover a LIS if the HELD protocol is Endpoints must be able to discover a LIS if the HELD protocol is
used, and a LoST server. DHCP options are defined for this purpose, used, and a LoST server. DHCP options are defined for this purpose,
namely [I-D.ietf-geopriv-lis-discovery] and [RFC5223]. namely [RFC5986] and [RFC5223].
Until such DHCP records are widely available, it may be necessary for Until such DHCP records are widely available, it may be necessary for
the service provider to provision a LoST server address in the the service provider to provision a LoST server address in the
device. The endpoint can also do a DNS SRV query to find a LoST device. The endpoint can also do a DNS SRV query to find a LoST
server. In any environment, more than one of these mechanisms may server. In any environment, more than one of these mechanisms may
yield a LoST server, and they may be different. The recommended yield a LoST server, and they may be different. The recommended
priority is DHCP first, provisioned value second, and DNS SRV query priority is DHCP first, provisioned value second, and DNS SRV query
in the SIP domain third. in the SIP domain third.
8. Routing the call to the PSAP 8. Routing the call to the PSAP
skipping to change at page 29, line 10 skipping to change at page 28, line 49
in [RFC3693] for emergency calls. For example, local policy may in [RFC3693] for emergency calls. For example, local policy may
dictate that location is sent with an emergency call even if the dictate that location is sent with an emergency call even if the
user's policy would otherwise prohibit that. Nevertheless, user's policy would otherwise prohibit that. Nevertheless,
protection from eavesdropping of location by encryption should be protection from eavesdropping of location by encryption should be
provided. provided.
It is unacceptable to have an emergency call fail to complete because It is unacceptable to have an emergency call fail to complete because
a TLS connection was not created for any reason. Thus, the call a TLS connection was not created for any reason. Thus, the call
should be attempted with TLS, but if the TLS session establishment should be attempted with TLS, but if the TLS session establishment
fails, the call should be automatically retried without TLS. fails, the call should be automatically retried without TLS.
[I-D.ietf-sip-sips] recommends that to achieve this effect the target [RFC5630] recommends that to achieve this effect the target specifies
specifies a sip URI, but use TLS on the outbound connection. An a sip URI, but use TLS on the outbound connection. An element that
element that receives a request over a TLS connection should attempt receives a request over a TLS connection should attempt to create a
to create a TLS connection to the next hop. TLS connection to the next hop.
In many cases, persistent TLS connections can be maintained between In many cases, persistent TLS connections can be maintained between
elements to minimize the time needed to establish them elements to minimize the time needed to establish them [RFC5626]. In
[I-D.ietf-sip-outbound]. In other circumstances, use of session other circumstances, use of session resumption [RFC5077] is
resumption [RFC5077] is recommended. IPsec [RFC4301] is an recommended. IPsec [RFC4301] is an acceptable alternative to TLS
acceptable alternative to TLS when used with an equivalent crypto when used with an equivalent crypto suite.
suite.
Location may be used for routing by multiple proxy servers on the Location may be used for routing by multiple proxy servers on the
path. Confidentiality mechanisms such as S/MIME encryption of SIP path. Confidentiality mechanisms such as S/MIME encryption of SIP
signaling [RFC3261] cannot be used because they obscure location. signaling [RFC3261] cannot be used because they obscure location.
Only hop-by-hop mechanisms such as TLS should be used. Implementing Only hop-by-hop mechanisms such as TLS should be used. Implementing
location conveyance in SIP mandates inclusion of TLS support. location conveyance in SIP mandates inclusion of TLS support.
9.2. SIP signaling requirements for User Agents 9.2. SIP signaling requirements for User Agents
SIP UAs that recognize local dial strings, insert location, and SIP UAs that recognize local dial strings, insert location, and
skipping to change at page 30, line 29 skipping to change at page 30, line 20
The call-taker must be able to reach the emergency caller if the The call-taker must be able to reach the emergency caller if the
original call is disconnected. In traditional emergency calls, original call is disconnected. In traditional emergency calls,
wireline and wireless emergency calls include a callback identifier wireline and wireless emergency calls include a callback identifier
for this purpose. There are two kinds of call backs. When a call is for this purpose. There are two kinds of call backs. When a call is
dropped, or the call taker realizes that some important information dropped, or the call taker realizes that some important information
is needed that it doesn't have, it must call back the device that is needed that it doesn't have, it must call back the device that
placed the emergency call. The PSAP, or a responder, may need to placed the emergency call. The PSAP, or a responder, may need to
call back the caller much later, and for that purpose, it wants a call back the caller much later, and for that purpose, it wants a
normal SIP Address of Record. In SIP systems, the caller must normal SIP Address of Record. In SIP systems, the caller must
include a Contact header field in an emergency call containing a include a Contact header field in an emergency call containing a
globally routable URI, possibly a GRUU [I-D.ietf-sip-gruu]. This globally routable URI, possibly a GRUU [RFC5627]. This identifier
identifier would be used to initiate call-backs immediately by the would be used to initiate call-backs immediately by the call-taker
call-taker if, for example, the call is prematurely dropped. A if, for example, the call is prematurely dropped. A concern arises
concern arises with B2BUAs that manipulate Contact headers. Such with B2BUAs that manipulate Contact headers. Such B2BUAs should
B2BUAs should always include a Contact header that routes to the same always include a Contact header that routes to the same device.
device being available for call backs.
In addition, a call-back identifier as an Address of Record (AoR) In addition, a call-back identifier as an Address of Record (AoR)
must be included either as the URI in the From header field [RFC3261] must be included either as the URI in the From header field [RFC3261]
verified by SIP Identity [RFC4474] or as a network asserted URI verified by SIP Identity [RFC4474] or as a network asserted URI
[RFC3325]. If the latter, the PSAP will need to establish a suitable [RFC3325]. If the latter, the PSAP will need to establish a suitable
spec(t) with the proxies that send it emergency calls. This spec(t) with the proxies that send it emergency calls. This
identifier would be used to initiate a call-back at a later time and identifier would be used to initiate a call-back at a later time and
may reach the caller, not necessarily on the same device (and at the may reach the caller, not necessarily on the same device (and at the
same location) as the original emergency call as per normal SIP same location) as the original emergency call as per normal SIP
rules. It is often a regulatory matter whether calls normally marked rules. It is often a regulatory matter whether calls normally marked
skipping to change at page 32, line 16 skipping to change at page 32, line 4
to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs
should accept G.711 A-law (and mu-law in North America) encoded voice should accept G.711 A-law (and mu-law in North America) encoded voice
as described in [RFC3551]. Newer text forms are rapidly appearing, as described in [RFC3551]. Newer text forms are rapidly appearing,
with instant messaging now very common, PSAPs should accept IM with with instant messaging now very common, PSAPs should accept IM with
at least "pager-mode" MESSAGE request [RFC3428] as well as Message at least "pager-mode" MESSAGE request [RFC3428] as well as Message
Session Relay Protocol [RFC4975]. Video may be important to support Session Relay Protocol [RFC4975]. Video may be important to support
Video Relay Service (sign language interpretation) as well as modern Video Relay Service (sign language interpretation) as well as modern
video phones. video phones.
It is desirable for media to be kept secure by the use of Secure RTP It is desirable for media to be kept secure by the use of Secure RTP
[RFC3711], using SDES [RFC4568] for keying.
[RFC3711], using DTLS [RFC5764] for keying.
15. Testing 15. Testing
Since the emergency calling architecture consists of a number of Since the emergency calling architecture consists of a number of
pieces operated by independent entities, it is important to be able pieces operated by independent entities, it is important to be able
to test whether an emergency call is likely to succeed without to test whether an emergency call is likely to succeed without
actually occupying the human resources at a PSAP. Both signaling and actually occupying the human resources at a PSAP. Both signaling and
media paths need to be tested since NATs and firewalls may allow the media paths need to be tested since NATs and firewalls may allow the
session setup request to reach the PSAP, while preventing the session setup request to reach the PSAP, while preventing the
exchange of media. exchange of media.
skipping to change at page 32, line 47 skipping to change at page 32, line 36
There is a concern associated with testing during a so-called There is a concern associated with testing during a so-called
"avalanche-restart" event where, for example a large power outage "avalanche-restart" event where, for example a large power outage
affects a large number of endpoints, that, when power is restored, affects a large number of endpoints, that, when power is restored,
all attempt to reboot and, possibly, test. Devices need to randomize all attempt to reboot and, possibly, test. Devices need to randomize
their initiation of a boot time test to avoid the problem. their initiation of a boot time test to avoid the problem.
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.barnes-geopriv-lo-sec]. [RFC5069] and [I-D.ietf-geopriv-arch].
17. IANA Considerations 17. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
18. Acknowledgments 18. Acknowledgments
This draft was created from a This draft was created from a
draft-schulzrinne-sipping-emergency-arch-02 together with sections draft-schulzrinne-sipping-emergency-arch-02 together with sections
from draft-polk-newton-ecrit-arch-considerations-02. from draft-polk-newton-ecrit-arch-considerations-02.
Design Team members participating in this draft creation include Design Team members participating in this draft creation include
Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall, Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall,
Shida Schubert, Tom Taylor and Hannes Tschofenig,. Further comments Shida Schubert, Tom Taylor and Hannes Tschofenig,. Further comments
and input were provided by Richard Barnes, Barbara Stark and James and input were provided by Richard Barnes, Barbara Stark and James
Winterbottom. Winterbottom.
19. Informative References 19. Informative References
[I-D.barnes-geopriv-lo-sec]
Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
draft-barnes-geopriv-lo-sec-05 (work in progress),
March 2009.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-14 (work in progress), draft-ietf-ecrit-phonebcp-15 (work in progress),
January 2010. July 2010.
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009.
[I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-15 (work in progress),
March 2010.
[I-D.ietf-sip-gruu] [I-D.ietf-geopriv-arch]
Rosenberg, J., "Obtaining and Using Globally Routable User Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Tschofenig, H., and H. Schulzrinne, "An Architecture for
(SIP)", draft-ietf-sip-gruu-15 (work in progress), Location and Location Privacy in Internet Applications",
October 2007. draft-ietf-geopriv-arch-03 (work in progress),
October 2010.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009. March 2009.
[I-D.ietf-sip-outbound]
Jennings, C., "Managing Client Initiated Connections in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-20 (work in progress), June 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.
[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".
[NENAi3TRD] [NENAi3TRD]
NENA, "08-751 NENA i3 Technical Requirements for", 2006. NENA, "08-751 NENA i3 Technical Requirements for", 2006.
skipping to change at page 36, line 9 skipping to change at page 35, line 17
Internet Protocol", RFC 4301, December 2005. 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.
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
Device Requirements and Configuration", RFC 4504, Device Requirements and Configuration", RFC 4504,
May 2006. May 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 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.
[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.
skipping to change at page 37, line 14 skipping to change at page 36, line 19
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service K. Summers, "Session Initiation Protocol Service
Examples", BCP 144, RFC 5359, October 2008. Examples", BCP 144, RFC 5359, October 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986,
September 2010.
[WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of [WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of
Defense World Geodetic System 1984, Its Definition and Defense World Geodetic System 1984, Its Definition and
Relationships With Local Geodetic Systems, Third Edition", Relationships With Local Geodetic Systems, Third Edition",
July 1997. July 1997.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
 End of changes. 24 change blocks. 
82 lines changed or deleted 63 lines changed or added

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