ECRIT H. Tschofenig
Internet-Draft Nokia Siemens Networks
Intended status: Informational H. Schulzrinne
Expires: January 3, 2008 Columbia University
July 2, 2007
Emergency Services Architecture Overview: Sharing Responsibilities
draft-tschofenig-ecrit-architecture-overview-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the IETF emergency services architectures and
illustrates the architectural principles and responsibilities of
different parties. For comparison, we also describe the emergency
services architecture developed by 3GPP.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 1]
Internet-Draft Emergency Services Architecture Overview July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The IETF Emergency Services Architecture . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. The 3GPP Emergency Services Architecture . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 2]
Internet-Draft Emergency Services Architecture Overview July 2007
1. Introduction
Summoning police, the fire department or an ambulance in emergencies
is one of the fundamental and most-valued functions of the telephone.
As telephone functionality moves from circuit-switched telephony to
Internet telephony, its users rightfully expect that this core
functionality will continue to work at least as well as it has for
the older technology. New devices and services are being made
available that could be used to make a request for help, which are
not traditional telephones, and users are increasingly expecting them
to be used to place emergency calls.
Existing emergency call systems are organized nationally; there are
currently no international standards. However, the Internet does not
respect national boundaries, and thus international standards are
required. To further complicate matters, emergency services support
needs to be added to a huge Internet where VoIP endpoints are subject
to numerous access technologies and limitations, such as virtual
private networks (VPNs), mobility protocols, firewalls, Network
Address Translators (NATs), different IP versions including devices
that translate from one to another version, different Voice over IP
protocols, etc. In addition to these technical obstacles, different
business models exist where a Voice Server Provider (VSP) or an
Application Server Provider (ASP) are separate from the Internet
Service Provider (ISP) and the Internet Attachment Provider (IAP).
This document describes the IETF emergency services architectures and
illustrates the architectural principles and the responsibilities of
different parties.
The 3GPP emergency services architecture, summarized in Appendix A,
splits responsibilities somewhat differently.
2. Terminology
This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps]
and [I-D.ietf-ecrit-requirements]. To make this document self-
contained we copy-and-paste the relevant terms into this section:
Internet Access Provider (IAP):
An organization that provides physical and data link (layer 2)
network connectivity to its customers or users, e.g., through
digital subscriber lines, cable TV plants, Ethernet, leased lines
or radio frequencies. Examples of such organizations include
telecommunication carriers, municipal utilities, larger
enterprises with their own network infrastructure, and government
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 3]
Internet-Draft Emergency Services Architecture Overview July 2007
organizations such as the military.
Internet Service Provider (ISP):
An organization that provides IP network-layer services to its
customers or users. This entity may or may not provide the
physical-layer and data link (layer-2) connectivity, such as fiber
or Ethernet, i.e., it may or may not play the role of an IAP.
Application Service Provider (ASP):
The organization or entity that provides application-layer
services, which may include voice (see "Voice Service Provider").
This entity can be a private individual, an enterprise, a
government, or a service provider. An ASP is more general than a
Voice Service Provider, since emergency calls may use other media
beyond voice, including text and video. For a particular user,
the ASP may or may not be the same organization as his IAP or ISP.
Voice Service Provider (VSP):
A specific type of Application Service Provider which provides
voice related services based on IP, such as call routing, a SIP
URI, or PSTN termination. In this document, unless noted
otherwise, any reference to "Voice Service Provider" or "VSP" may
be used interchangeably with "Application/ Voice Service Provider"
or "ASP/VSP".
Emergency Service Routing Proxy (ESRP):
An ESRP is an emergency call routing support entity that invokes
the location-to-PSAP URI mapping function, to return an
appropriate PSAP URI, or the URI for another ESRP. Client mapping
requests could also be performed by a number of entities,
including entities that instantiate the SIP proxy role and the SIP
user agent client role.
Public Safety Answering Point (PSAP):
Physical location where emergency calls are received under the
responsibility of a public authority. (This terminology is used
by both ETSI, in ETSI SR 002 180, and NENA.) In the United
Kingdom, PSAPs are called Operator Assistance Centres, in New
Zealand, Communications Centres. Within this document, it is
assumed, unless stated otherwise, that PSAPs support the receipt
of emergency calls over IP, using appropriate application layer
protocols such as SIP for call signaling and RTP for media.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 4]
Internet-Draft Emergency Services Architecture Overview July 2007
Location Configuration Server (LCS):
The term LCS refers to an entity capable of determining the
location of an end point and of providing that location
information, a reference to it, or both) via the Location
Configuration Protocol (LCP) to the requesting party, in most
cases to the end point itself or to an entity that acts on behalf
of it.
(Emergency) service dial string:
The service dial string identifies the string of digits that a
caller must dial to reach a particular (emergency) service. In
devices directly connected to the PSTN, the service dial string is
the same as the service number and may thus depend on the location
of the caller. However, in private phone networks, such as in
PBXs, the service dial string consists of a dialing prefix to
reach an outside line, followed by the emergency number. For
example, in a hotel, the dial string for emergency services in the
United States might be 9911. Dial strings may contain indications
of pauses or wait-for-secondary- dial-tone indications.
(Emergency) service identifier:
The (emergency) service identifier describes the emergency
service, independent of the user interface mechanism, the
signaling protocol that is used to reach the service, or the
caller's geographic location. It is a protocol constant and used
within the mapping and signaling protocols. An example is the
service URN [I-D.ietf-ecrit-service-urn].
For the purpose of this document we assume that the ISP and the IAP
colaps into a single entity. We use the term ISP only. Furthermore,
unless noted otherwise, any reference to "Voice Service Provider" or
"VSP" may be used interchangeably with "Application/ Voice Service
Provider" or "ASP/VSP".
3. The IETF Emergency Services Architecture
The emergency services architecture developed in the IETF Emergency
Context Resolution with Internet Technology (ECRIT) working group,
see [I-D.ietf-ecrit-framework], describes an architecture where
location information is provided by the IAP/ISP to end points in
order to determine the correct dial string and a Uniform Resource
Identifier (URI) to route the call to a Public Safety Answering Point
(PSAP) via the user's VoIP provider. The Location-to-Service
Translation (LoST) protocol [I-D.ietf-ecrit-lost] allows to determine
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 5]
Internet-Draft Emergency Services Architecture Overview July 2007
the PSAP URI for a specific geographical location together with an
emergency service identifier, see [I-D.ietf-ecrit-service-urn]. The
basic architecture is shown in Figure 1. Detailed message flows are
illustrated in Figure 2 of [I-D.ietf-ecrit-framework].
The obligations for the different parties are summarized below. An
IETF draft [I-D.ietf-ecrit-phonebcp] describes these in much more
detail, including callback capabilities, support for certain codecs,
and SIP call handling behavior specific to emergency calls. The
distributed mapping database may be operated by the ISP/IAP, the VSP,
the PSAP operator, another independent entity or in parts by all
these different entities. A description of the mapping architecture
can be found in [I-D.ietf-ecrit-mapping-arch].
The obligations for the different parties are as follows:
End Host:
* An end host, through its VoIP applications, has three main
responsibilities: it has to obtain its own location, determine
the URI of the appropriate PSAP for that location, and
recognize when the user places an emergency call by examining
the dial string. The end host operating system may assist in
determining the device location.
The protocol interaction is shown as (A) in Figure 1. A number
of protocols have been developed to provide this capability, as
listed in Section 4.2 of [I-D.ietf-ecrit-phonebcp].
[I-D.ietf-ecrit-phonebcp] mandates support DHCP (see [RFC4776]
and [RFC3825]), HELD (see
[I-D.ietf-geopriv-http-location-delivery] and LLDP-MED (see
[LLDP-MED]).
* A VoIP application needs to support the Location-to-Service
Translation (LoST) protocol [I-D.ietf-ecrit-lost] in order to
determine the emergency service dial strings and the PSAP URI.
Additionally, the service identifiers, defined in
[I-D.ietf-ecrit-service-urn], need to be understood by the
device.
* In the current architecture, it is assumed that PSAPs can be
reached by SIP and RTP, but may support other signaling
protocols, either directly or through a protocol translation
gateway. The LoST retrieval results indicate whether other
VoIP signaling protocols are supported.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 6]
Internet-Draft Emergency Services Architecture Overview July 2007
IAP/ISP:
* The IAP/ISP has to make location information available to the
end point via one or more of the above-mentioned protocols,
namely DHCP (see [RFC4776] and [RFC3825]), HELD (see
[I-D.ietf-geopriv-http-location-delivery]) and LLDP-MED (see
[LLDP-MED]).
Emergency services need location information for two
different purposes, first for routing the emergency call to
the PSAP that is serving a specific geographical region for
the emergency service requested and to dispatch emergency
personnel to the scene of the accident, crime or other type
of incident. For the latter, the caller may be able to
deliver this information orally, but it is generally agreed
that emergency services protocols should deliver location
information that is automatically generated, to increase
accuracy and avoid dispatch delays when the caller is unable
to provide location information due to language barriers,
lack of familiarity with his or her surroundings or physical
or mental impairment.
The accuracy requirements for these two uses differ. For
call routing, city or county-level accuracy is often
sufficient, while dispatch benefits greatly from having
location that identifies a particular building or even room
for indoor locations, or a radius of at most a few hundred
feet for outdoor locations.
In some cases, Internet Access Providers (IAPs) and/or the
Internet Service Providers (ISPs) are afraid that allowing
users to access location information for non-emergency
purposes or prior to an emergency call will incur additional
server load and thus costs. Hence, they do not to disclose
precise location information (at the quality suitable for
dispatch emergency personnel by the PSAP operator) or not to
disclose any location information. The impact for the IETF
emergency services architecture to support this type of
functionality, referred as 'location hiding', is currently
under investigation (see
[I-D.schulzrinne-location-hiding-requirements]. It should
be noted that the concept of hiding location information
refers to call routing only. ISPs have no interest or legal
right to hide location information from emergency services
personnel.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 7]
Internet-Draft Emergency Services Architecture Overview July 2007
* The IAP/ISP may additionally operate a (caching) LoST server to
improve the robustness and the reliability of the architecture.
* The IAP/ISP must allow signaling and media protocols used for
emergency calls to traverse its network.
VSP:
* The IETF emergency services architecture does not require the
participation of a VSP as such. However, if a caller uses a
VSP, this VSP often forces all calls, emergency or not, to
traverse an outbound proxy operated by the VSP. Also, at least
initially, customer equipment may not be able to perform LoST
lookups and thus needs to rely on the VSP to recognize
emergency calls and route them to the correct PSAP.
* If the VSP uses a signaling or media protocol that is not
natively supported by the PSAP, it needs to offer protocol
translation and gateway services.
* VSPs can assist the PSAP by providing identity assurance for
emergency callers that are their customers. Such identity
assurance may assist with prosecuting prank callers. However,
identity assurance can only be effective if the VSP can
authenticate their customers, e.g., by having a verifiable
customer postal address. (Verification by credit card usage
fails when the credit card number has been stolen.)
PSAP:
* The IETF architecture does not standardize PSAP architecture
and only describes those aspects in [I-D.ietf-ecrit-phonebcp]
that are necessary for emergency calls to be processed by the
PSAP. To make the overall architecture work, PSAPs must accept
calls from any VSP/ASP in the world, as shown in protocol
interaction (D) in Figure 1. Since calls may come from
anywhere, PSAPs must develop mechanisms to reduce the number of
prank calls, particularly calls with spoofed location
information. [I-D.barnes-geopriv-lo-sec] discusses this
problem. The PSAP operator can expect to receive civic or
geodetic location information in the format known as PIDF-LO,
specified in [RFC4119], revised for civic location information
by [I-D.ietf-geopriv-revised-civic-lo]) and profiled for
geodetic information in [I-D.ietf-geopriv-pdif-lo-profile]).
The distributed mapping database may be operated by the ISP/IAP, the
VSP, the PSAP operator, another independent entity or in parts by all
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 8]
Internet-Draft Emergency Services Architecture Overview July 2007
these different entities. A description of the mapping architecture
can be found in [I-D.ietf-ecrit-mapping-arch].
+---------------------------+
| |
| Emergency Network |
| Infrastructure |
| |
| +----------+ +----------+ |
| | PSAP | | ESRP | |
| | | | | |
| +----------+ +----------+ |
+-------------^-------------+ (D)
+----------------------+
|
+--------------+ +-----+--------+
| | ---- | | |
| ISP/IAP | ///- -\\\ | | VSP |
| | / \\ | | |
| +----------+ | | Distributed | | +---+------+ |
| | LCS | | | Mapping | | | SIP | |
| | | | | Database | | | Proxy | |
| +----------+ | | | | +----------+ |
| ^ | \ // | ^ |
| | | \\\- -/// | | |
| | | ---- | | |
+-----+--------+ (B) ^ +-----+--------+
| +---------------------+ |
(A)| | |
| | +---------------------------------------+
| | | (C)
v v v
+----------+
| End |
| Host |
+----------+
Figure 1: Overview of the IETF Emergency Services Architecture
4. Security Considerations
This document does not describe the security aspects of the two
architectures. The protocol documents and the ECRIT security
requirements [I-D.ietf-ecrit-security-threats] describe potential
threats, and make protocol, implementation and operational
recommendations to minimize these threats.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 9]
Internet-Draft Emergency Services Architecture Overview July 2007
5. Acknowledgments
We would like to thank the ECRIT working group their work on the IETF
ECRIT emergency services architecture. Additionally, we would like
to thank the participants of various emergency services workshops,
meetings and phone conferences for sharing their view with us.
The authors would particularly like to thank Alain Van Gaever from
the European Commission for pushing us to write such a document.
Dirk Kroeselberg, Leopold Murhammer, Richard Barnes, and James
Winterbottom provided us review comments for the pre-00 version.
6. Open Issues
Currently, the IETF emergency services architecture does not describe
how to handle calls that are not authorized to access a network due
to lack of proper credentials or that are not configured with a
particular VSP.
There is currently no mechanism for prioritizing access to network
resources for emergency calls, e.g., during mass casualty event.
7. References
7.1. Normative References
[I-D.ietf-ecrit-lost]
Hardie, T., "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-05 (work in progress),
March 2007.
[I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Session Initiation Protocol
Location Conveyance",
draft-ietf-sip-location-conveyance-07 (work in progress),
February 2007.
[I-D.ietf-ecrit-service-urn]
Schulzrinne, H., "A Uniform Resource Name (URN) for
Services", draft-ietf-ecrit-service-urn-06 (work in
progress), March 2007.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 10]
Internet-Draft Emergency Services Architecture Overview July 2007
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[I-D.ietf-geopriv-pdif-lo-profile]
Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-07 (work in progress),
April 2007.
[I-D.ietf-geopriv-revised-civic-lo]
Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for PIDF-LO",
draft-ietf-geopriv-revised-civic-lo-05 (work in progress),
February 2007.
[LLDP-MED]
, ., "ANSI/TIA-1057, Link Layer Discovery Protocol for
Media Endpoint Devices (aka LLDP-MED)", April 2006.
7.2. Informative References
[I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in
progress), April 2007.
[I-D.ietf-ecrit-framework]
Rosen, B., "Framework for Emergency Calling in Internet
Multimedia", draft-ietf-ecrit-framework-01 (work in
progress), March 2007.
[I-D.marshall-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference
Mechanism used in Location Configuration and Conveyance",
draft-marshall-geopriv-lbyr-requirements-01 (work in
progress), March 2007.
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-00 (work in
progress), June 2007.
[I-D.ietf-ecrit-mapping-arch]
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 11]
Internet-Draft Emergency Services Architecture Overview July 2007
Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", draft-ietf-ecrit-mapping-arch-01 (work in
progress), December 2006.
[I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-01 (work in progress),
March 2007.
[I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress),
March 2007.
[I-D.ietf-ecrit-security-threats]
Taylor, T., "Security Threats and Requirements for
Emergency Call Marking and Mapping",
draft-ietf-ecrit-security-threats-04 (work in progress),
April 2007.
[I-D.schulzrinne-location-hiding-requirements]
Schulzrinne, H., "Location Hiding: Problem Statement and
Requirements", July 2007.
[I-D.barnes-geopriv-lo-sec]
Barnes, R., "GEOPRIV Security Requirements", July 2007.
[TS-24.229]
"TS 24.229, 3rd Generation Partnership Project; Internet
Protocol (IP) multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3, (Release 7)", June 2007.
[TS-23.167]
"TS 23.167, 3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; IP
Multimedia Subsystem (IMS) emergency sessions (Release
7)", June 2007.
Appendix A. The 3GPP Emergency Services Architecture
The description in this section re-uses terminology introduced in
this document rather than using native 3GPP introduced terminology.
The basic idea of the 3GPP emergency services architecture, based on
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 12]
Internet-Draft Emergency Services Architecture Overview July 2007
[TS-24.229]/[TS-23.167], is shown in Figure 2 and is characterized by
the difference that emergency services support is provided by the
ISP/IAP (or a closely associated entity). This has the following
consequences:
o A SIP-based signaling profile needs to be standardized for
interaction between the SIP UA and the SIP proxy in the ISP/IAP/
visited VSP/ASP. For the 3GPP emergency architecture IMS was
chosen as the profile, i.e., a flavor of IETF SIP. This exchange
is shown in (1).
o The SIP proxy responsible for emergency call routing needs to
determine location information of the end point. Since the SIP
proxy and the location server are both located in the ISP/IAP (or
in a closely associated entity) local information, such as IP
addresses, cell identifiers, MAC addresses or similar identifiers
are sufficient. Determining the address of the PSAP is also a
local matter since there is a relationship between the ISP/IAP and
the PSAP operator responsible for a specific geographic region.
This exchange is shown in (2).
o To provide identity information for the emergency call to the PSAP
operator it is necessary to interact with the user's home VSP/ASP
(in the roaming case). This is shown with the message interaction
in (3).
o The interaction between the ISP/IAP/visited VSP/ASP and the PSAP
operator is a national matter and is currently not specified.
The obligations for the different parties are as follows:
End Host:
* The end host needs to support the IMS-specific SIP profile.
The detailed steps are described in Section 6.1 of [TS-23.167].
End hosts that do not support this specific version of SIP
(including the specific authentication mechanisms) cannot be
supported.
* PIDF-LO [RFC4119] may need to be supported to allow the end
host to attach GPS available location information. Other
location protocols, such as the Secure User Plane Location
protocol (SUPL), may be needed in special cases. See Section
7.6 of [TS-23.167] for a detailed considerations on how to
retrieve location information.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 13]
Internet-Draft Emergency Services Architecture Overview July 2007
ISP/IAP/visited VSP/ASP:
* The SIP proxy in the access network needs to understand the
IMS-specific SIP profile and the protocols used for (2), (3)
and (4), whereby (4) is not specified. The detailed steps are
described in Section 6.2.1, Section 6.2.2, 6.2.3 of
[TS-23.167]. On a high-level basis, the responsibility is
mainly to understand the SIP protocol (and the corresponding
extensions), to determine the end host's location information,
to perform the necessary interaction for verifying the
emergency caller's identity via the interaction with the home
VSP and finally to route the emergency call to the correct
PSAP.
Home VSP/ASP:
* The home VSP/ASP needs to provide SIP call back functionality
and asserts the identity of the emergency caller. A roaming
agreement is assumed to be in place between the home and the
visted VSP/ASP. Note that the security mechanism used to
authenticate the end host to the Home VSP needs to prevent the
visited VSP from being able to later impersonate the user.
Note that this authentication procedure is likely be done
during the network access authentication procedure rather than
during the SIP signaling exchange.
PSAP:
* This protocol interaction is not specified but assumed to be
based on SIP.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 14]
Internet-Draft Emergency Services Architecture Overview July 2007
+---------------------------+
| |
| Emergency Network |
| Infrastructure |
| |
| +----------+ +----------+ |
| | PSAP | | ESRP | |
| | | | | |
| +----------+ +----------+ |
+-------------^-------------+
|
| (4)
+------------------------+-------+ +-----------------------+
| ISP/IAP | | | Home VSP/ASP |
| Visited VSP/ASP | | | |
|+----------+ v | | +----------+ |
|| LCS | (2) +----------+ | (3) | | Identity | |
|| |<--+-->| ESRP / |<+-----+-+--->| Provider | |
|+----------+ | | SIP Proxy| | | | +----------+ |
|+----------+ | +----------+ | | | +----------+ |
|| Mapping |<--+ ^ | | | | SIP | |
|| Database | | | +-+--->| Proxy | |
|+----------+ | | | +----------+ |
+------------------------+-------+ +-----------------------+
|
| (1)
|
|
v
+----------+
| End |
| Host |
+----------+
Figure 2: Overview of the 3GPP Emergency Services Architecture
Authors' Addresses
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 15]
Internet-Draft Emergency Services Architecture Overview July 2007
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 16]
Internet-Draft Emergency Services Architecture Overview July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 17]