idnits 2.17.00 (12 Aug 2021) /tmp/idnits31367/draft-tschofenig-ecrit-architecture-overview-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2007) is 5430 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sip-location-conveyance' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'I-D.marshall-geopriv-lbyr-requirements' is defined on line 473, but no explicit reference was found in the text == Outdated reference: draft-ietf-ecrit-lost has been published as RFC 5222 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-07 == Outdated reference: draft-ietf-ecrit-service-urn has been published as RFC 5031 ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) == Outdated reference: draft-ietf-geopriv-pdif-lo-profile has been published as RFC 5491 == Outdated reference: draft-ietf-geopriv-revised-civic-lo has been published as RFC 5139 == Outdated reference: draft-ietf-geopriv-l7-lcp-ps has been published as RFC 5687 == Outdated reference: draft-ietf-ecrit-framework has been published as RFC 6443 == Outdated reference: A later version (-02) exists of draft-marshall-geopriv-lbyr-requirements-01 == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 == Outdated reference: draft-ietf-ecrit-mapping-arch has been published as RFC 5582 == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: draft-ietf-ecrit-requirements has been published as RFC 5012 == Outdated reference: draft-ietf-ecrit-security-threats has been published as RFC 5069 -- No information found for draft-schulzrinne-location-hiding-requirements - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational H. Schulzrinne 5 Expires: January 3, 2008 Columbia University 6 July 2, 2007 8 Emergency Services Architecture Overview: Sharing Responsibilities 9 draft-tschofenig-ecrit-architecture-overview-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 3, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes the IETF emergency services architectures and 43 illustrates the architectural principles and responsibilities of 44 different parties. For comparison, we also describe the emergency 45 services architecture developed by 3GPP. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. The IETF Emergency Services Architecture . . . . . . . . . . . 5 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 53 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 54 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 57 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 58 Appendix A. The 3GPP Emergency Services Architecture . . . . . . 12 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 60 Intellectual Property and Copyright Statements . . . . . . . . . . 17 62 1. Introduction 64 Summoning police, the fire department or an ambulance in emergencies 65 is one of the fundamental and most-valued functions of the telephone. 66 As telephone functionality moves from circuit-switched telephony to 67 Internet telephony, its users rightfully expect that this core 68 functionality will continue to work at least as well as it has for 69 the older technology. New devices and services are being made 70 available that could be used to make a request for help, which are 71 not traditional telephones, and users are increasingly expecting them 72 to be used to place emergency calls. 74 Existing emergency call systems are organized nationally; there are 75 currently no international standards. However, the Internet does not 76 respect national boundaries, and thus international standards are 77 required. To further complicate matters, emergency services support 78 needs to be added to a huge Internet where VoIP endpoints are subject 79 to numerous access technologies and limitations, such as virtual 80 private networks (VPNs), mobility protocols, firewalls, Network 81 Address Translators (NATs), different IP versions including devices 82 that translate from one to another version, different Voice over IP 83 protocols, etc. In addition to these technical obstacles, different 84 business models exist where a Voice Server Provider (VSP) or an 85 Application Server Provider (ASP) are separate from the Internet 86 Service Provider (ISP) and the Internet Attachment Provider (IAP). 88 This document describes the IETF emergency services architectures and 89 illustrates the architectural principles and the responsibilities of 90 different parties. 92 The 3GPP emergency services architecture, summarized in Appendix A, 93 splits responsibilities somewhat differently. 95 2. Terminology 97 This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps] 98 and [I-D.ietf-ecrit-requirements]. To make this document self- 99 contained we copy-and-paste the relevant terms into this section: 101 Internet Access Provider (IAP): 103 An organization that provides physical and data link (layer 2) 104 network connectivity to its customers or users, e.g., through 105 digital subscriber lines, cable TV plants, Ethernet, leased lines 106 or radio frequencies. Examples of such organizations include 107 telecommunication carriers, municipal utilities, larger 108 enterprises with their own network infrastructure, and government 109 organizations such as the military. 111 Internet Service Provider (ISP): 113 An organization that provides IP network-layer services to its 114 customers or users. This entity may or may not provide the 115 physical-layer and data link (layer-2) connectivity, such as fiber 116 or Ethernet, i.e., it may or may not play the role of an IAP. 118 Application Service Provider (ASP): 120 The organization or entity that provides application-layer 121 services, which may include voice (see "Voice Service Provider"). 122 This entity can be a private individual, an enterprise, a 123 government, or a service provider. An ASP is more general than a 124 Voice Service Provider, since emergency calls may use other media 125 beyond voice, including text and video. For a particular user, 126 the ASP may or may not be the same organization as his IAP or ISP. 128 Voice Service Provider (VSP): 130 A specific type of Application Service Provider which provides 131 voice related services based on IP, such as call routing, a SIP 132 URI, or PSTN termination. In this document, unless noted 133 otherwise, any reference to "Voice Service Provider" or "VSP" may 134 be used interchangeably with "Application/ Voice Service Provider" 135 or "ASP/VSP". 137 Emergency Service Routing Proxy (ESRP): 139 An ESRP is an emergency call routing support entity that invokes 140 the location-to-PSAP URI mapping function, to return an 141 appropriate PSAP URI, or the URI for another ESRP. Client mapping 142 requests could also be performed by a number of entities, 143 including entities that instantiate the SIP proxy role and the SIP 144 user agent client role. 146 Public Safety Answering Point (PSAP): 148 Physical location where emergency calls are received under the 149 responsibility of a public authority. (This terminology is used 150 by both ETSI, in ETSI SR 002 180, and NENA.) In the United 151 Kingdom, PSAPs are called Operator Assistance Centres, in New 152 Zealand, Communications Centres. Within this document, it is 153 assumed, unless stated otherwise, that PSAPs support the receipt 154 of emergency calls over IP, using appropriate application layer 155 protocols such as SIP for call signaling and RTP for media. 157 Location Configuration Server (LCS): 159 The term LCS refers to an entity capable of determining the 160 location of an end point and of providing that location 161 information, a reference to it, or both) via the Location 162 Configuration Protocol (LCP) to the requesting party, in most 163 cases to the end point itself or to an entity that acts on behalf 164 of it. 166 (Emergency) service dial string: 168 The service dial string identifies the string of digits that a 169 caller must dial to reach a particular (emergency) service. In 170 devices directly connected to the PSTN, the service dial string is 171 the same as the service number and may thus depend on the location 172 of the caller. However, in private phone networks, such as in 173 PBXs, the service dial string consists of a dialing prefix to 174 reach an outside line, followed by the emergency number. For 175 example, in a hotel, the dial string for emergency services in the 176 United States might be 9911. Dial strings may contain indications 177 of pauses or wait-for-secondary- dial-tone indications. 179 (Emergency) service identifier: 181 The (emergency) service identifier describes the emergency 182 service, independent of the user interface mechanism, the 183 signaling protocol that is used to reach the service, or the 184 caller's geographic location. It is a protocol constant and used 185 within the mapping and signaling protocols. An example is the 186 service URN [I-D.ietf-ecrit-service-urn]. 188 For the purpose of this document we assume that the ISP and the IAP 189 colaps into a single entity. We use the term ISP only. Furthermore, 190 unless noted otherwise, any reference to "Voice Service Provider" or 191 "VSP" may be used interchangeably with "Application/ Voice Service 192 Provider" or "ASP/VSP". 194 3. The IETF Emergency Services Architecture 196 The emergency services architecture developed in the IETF Emergency 197 Context Resolution with Internet Technology (ECRIT) working group, 198 see [I-D.ietf-ecrit-framework], describes an architecture where 199 location information is provided by the IAP/ISP to end points in 200 order to determine the correct dial string and a Uniform Resource 201 Identifier (URI) to route the call to a Public Safety Answering Point 202 (PSAP) via the user's VoIP provider. The Location-to-Service 203 Translation (LoST) protocol [I-D.ietf-ecrit-lost] allows to determine 204 the PSAP URI for a specific geographical location together with an 205 emergency service identifier, see [I-D.ietf-ecrit-service-urn]. The 206 basic architecture is shown in Figure 1. Detailed message flows are 207 illustrated in Figure 2 of [I-D.ietf-ecrit-framework]. 209 The obligations for the different parties are summarized below. An 210 IETF draft [I-D.ietf-ecrit-phonebcp] describes these in much more 211 detail, including callback capabilities, support for certain codecs, 212 and SIP call handling behavior specific to emergency calls. The 213 distributed mapping database may be operated by the ISP/IAP, the VSP, 214 the PSAP operator, another independent entity or in parts by all 215 these different entities. A description of the mapping architecture 216 can be found in [I-D.ietf-ecrit-mapping-arch]. 218 The obligations for the different parties are as follows: 220 End Host: 222 * An end host, through its VoIP applications, has three main 223 responsibilities: it has to obtain its own location, determine 224 the URI of the appropriate PSAP for that location, and 225 recognize when the user places an emergency call by examining 226 the dial string. The end host operating system may assist in 227 determining the device location. 229 The protocol interaction is shown as (A) in Figure 1. A number 230 of protocols have been developed to provide this capability, as 231 listed in Section 4.2 of [I-D.ietf-ecrit-phonebcp]. 232 [I-D.ietf-ecrit-phonebcp] mandates support DHCP (see [RFC4776] 233 and [RFC3825]), HELD (see 234 [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED (see 235 [LLDP-MED]). 237 * A VoIP application needs to support the Location-to-Service 238 Translation (LoST) protocol [I-D.ietf-ecrit-lost] in order to 239 determine the emergency service dial strings and the PSAP URI. 240 Additionally, the service identifiers, defined in 241 [I-D.ietf-ecrit-service-urn], need to be understood by the 242 device. 244 * In the current architecture, it is assumed that PSAPs can be 245 reached by SIP and RTP, but may support other signaling 246 protocols, either directly or through a protocol translation 247 gateway. The LoST retrieval results indicate whether other 248 VoIP signaling protocols are supported. 250 IAP/ISP: 252 * The IAP/ISP has to make location information available to the 253 end point via one or more of the above-mentioned protocols, 254 namely DHCP (see [RFC4776] and [RFC3825]), HELD (see 255 [I-D.ietf-geopriv-http-location-delivery]) and LLDP-MED (see 256 [LLDP-MED]). 258 Emergency services need location information for two 259 different purposes, first for routing the emergency call to 260 the PSAP that is serving a specific geographical region for 261 the emergency service requested and to dispatch emergency 262 personnel to the scene of the accident, crime or other type 263 of incident. For the latter, the caller may be able to 264 deliver this information orally, but it is generally agreed 265 that emergency services protocols should deliver location 266 information that is automatically generated, to increase 267 accuracy and avoid dispatch delays when the caller is unable 268 to provide location information due to language barriers, 269 lack of familiarity with his or her surroundings or physical 270 or mental impairment. 272 The accuracy requirements for these two uses differ. For 273 call routing, city or county-level accuracy is often 274 sufficient, while dispatch benefits greatly from having 275 location that identifies a particular building or even room 276 for indoor locations, or a radius of at most a few hundred 277 feet for outdoor locations. 279 In some cases, Internet Access Providers (IAPs) and/or the 280 Internet Service Providers (ISPs) are afraid that allowing 281 users to access location information for non-emergency 282 purposes or prior to an emergency call will incur additional 283 server load and thus costs. Hence, they do not to disclose 284 precise location information (at the quality suitable for 285 dispatch emergency personnel by the PSAP operator) or not to 286 disclose any location information. The impact for the IETF 287 emergency services architecture to support this type of 288 functionality, referred as 'location hiding', is currently 289 under investigation (see 290 [I-D.schulzrinne-location-hiding-requirements]. It should 291 be noted that the concept of hiding location information 292 refers to call routing only. ISPs have no interest or legal 293 right to hide location information from emergency services 294 personnel. 296 * The IAP/ISP may additionally operate a (caching) LoST server to 297 improve the robustness and the reliability of the architecture. 299 * The IAP/ISP must allow signaling and media protocols used for 300 emergency calls to traverse its network. 302 VSP: 304 * The IETF emergency services architecture does not require the 305 participation of a VSP as such. However, if a caller uses a 306 VSP, this VSP often forces all calls, emergency or not, to 307 traverse an outbound proxy operated by the VSP. Also, at least 308 initially, customer equipment may not be able to perform LoST 309 lookups and thus needs to rely on the VSP to recognize 310 emergency calls and route them to the correct PSAP. 312 * If the VSP uses a signaling or media protocol that is not 313 natively supported by the PSAP, it needs to offer protocol 314 translation and gateway services. 316 * VSPs can assist the PSAP by providing identity assurance for 317 emergency callers that are their customers. Such identity 318 assurance may assist with prosecuting prank callers. However, 319 identity assurance can only be effective if the VSP can 320 authenticate their customers, e.g., by having a verifiable 321 customer postal address. (Verification by credit card usage 322 fails when the credit card number has been stolen.) 324 PSAP: 326 * The IETF architecture does not standardize PSAP architecture 327 and only describes those aspects in [I-D.ietf-ecrit-phonebcp] 328 that are necessary for emergency calls to be processed by the 329 PSAP. To make the overall architecture work, PSAPs must accept 330 calls from any VSP/ASP in the world, as shown in protocol 331 interaction (D) in Figure 1. Since calls may come from 332 anywhere, PSAPs must develop mechanisms to reduce the number of 333 prank calls, particularly calls with spoofed location 334 information. [I-D.barnes-geopriv-lo-sec] discusses this 335 problem. The PSAP operator can expect to receive civic or 336 geodetic location information in the format known as PIDF-LO, 337 specified in [RFC4119], revised for civic location information 338 by [I-D.ietf-geopriv-revised-civic-lo]) and profiled for 339 geodetic information in [I-D.ietf-geopriv-pdif-lo-profile]). 341 The distributed mapping database may be operated by the ISP/IAP, the 342 VSP, the PSAP operator, another independent entity or in parts by all 343 these different entities. A description of the mapping architecture 344 can be found in [I-D.ietf-ecrit-mapping-arch]. 346 +---------------------------+ 347 | | 348 | Emergency Network | 349 | Infrastructure | 350 | | 351 | +----------+ +----------+ | 352 | | PSAP | | ESRP | | 353 | | | | | | 354 | +----------+ +----------+ | 355 +-------------^-------------+ (D) 356 +----------------------+ 357 | 358 +--------------+ +-----+--------+ 359 | | ---- | | | 360 | ISP/IAP | ///- -\\\ | | VSP | 361 | | / \\ | | | 362 | +----------+ | | Distributed | | +---+------+ | 363 | | LCS | | | Mapping | | | SIP | | 364 | | | | | Database | | | Proxy | | 365 | +----------+ | | | | +----------+ | 366 | ^ | \ // | ^ | 367 | | | \\\- -/// | | | 368 | | | ---- | | | 369 +-----+--------+ (B) ^ +-----+--------+ 370 | +---------------------+ | 371 (A)| | | 372 | | +---------------------------------------+ 373 | | | (C) 374 v v v 375 +----------+ 376 | End | 377 | Host | 378 +----------+ 380 Figure 1: Overview of the IETF Emergency Services Architecture 382 4. Security Considerations 384 This document does not describe the security aspects of the two 385 architectures. The protocol documents and the ECRIT security 386 requirements [I-D.ietf-ecrit-security-threats] describe potential 387 threats, and make protocol, implementation and operational 388 recommendations to minimize these threats. 390 5. Acknowledgments 392 We would like to thank the ECRIT working group their work on the IETF 393 ECRIT emergency services architecture. Additionally, we would like 394 to thank the participants of various emergency services workshops, 395 meetings and phone conferences for sharing their view with us. 397 The authors would particularly like to thank Alain Van Gaever from 398 the European Commission for pushing us to write such a document. 400 Dirk Kroeselberg, Leopold Murhammer, Richard Barnes, and James 401 Winterbottom provided us review comments for the pre-00 version. 403 6. Open Issues 405 Currently, the IETF emergency services architecture does not describe 406 how to handle calls that are not authorized to access a network due 407 to lack of proper credentials or that are not configured with a 408 particular VSP. 410 There is currently no mechanism for prioritizing access to network 411 resources for emergency calls, e.g., during mass casualty event. 413 7. References 415 7.1. Normative References 417 [I-D.ietf-ecrit-lost] 418 Hardie, T., "LoST: A Location-to-Service Translation 419 Protocol", draft-ietf-ecrit-lost-05 (work in progress), 420 March 2007. 422 [I-D.ietf-sip-location-conveyance] 423 Polk, J. and B. Rosen, "Session Initiation Protocol 424 Location Conveyance", 425 draft-ietf-sip-location-conveyance-07 (work in progress), 426 February 2007. 428 [I-D.ietf-ecrit-service-urn] 429 Schulzrinne, H., "A Uniform Resource Name (URN) for 430 Services", draft-ietf-ecrit-service-urn-06 (work in 431 progress), March 2007. 433 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 434 (DHCPv4 and DHCPv6) Option for Civic Addresses 435 Configuration Information", RFC 4776, November 2006. 437 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 438 Configuration Protocol Option for Coordinate-based 439 Location Configuration Information", RFC 3825, July 2004. 441 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 442 Format", RFC 4119, December 2005. 444 [I-D.ietf-geopriv-pdif-lo-profile] 445 Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 446 Considerations and Recommendations", 447 draft-ietf-geopriv-pdif-lo-profile-07 (work in progress), 448 April 2007. 450 [I-D.ietf-geopriv-revised-civic-lo] 451 Thomson, M. and J. Winterbottom, "Revised Civic Location 452 Format for PIDF-LO", 453 draft-ietf-geopriv-revised-civic-lo-05 (work in progress), 454 February 2007. 456 [LLDP-MED] 457 , ., "ANSI/TIA-1057, Link Layer Discovery Protocol for 458 Media Endpoint Devices (aka LLDP-MED)", April 2006. 460 7.2. Informative References 462 [I-D.ietf-geopriv-l7-lcp-ps] 463 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 464 Location Configuration Protocol; Problem Statement and 465 Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in 466 progress), April 2007. 468 [I-D.ietf-ecrit-framework] 469 Rosen, B., "Framework for Emergency Calling in Internet 470 Multimedia", draft-ietf-ecrit-framework-01 (work in 471 progress), March 2007. 473 [I-D.marshall-geopriv-lbyr-requirements] 474 Marshall, R., "Requirements for a Location-by-Reference 475 Mechanism used in Location Configuration and Conveyance", 476 draft-marshall-geopriv-lbyr-requirements-01 (work in 477 progress), March 2007. 479 [I-D.ietf-geopriv-http-location-delivery] 480 Barnes, M., "HTTP Enabled Location Delivery (HELD)", 481 draft-ietf-geopriv-http-location-delivery-00 (work in 482 progress), June 2007. 484 [I-D.ietf-ecrit-mapping-arch] 485 Schulzrinne, H., "Location-to-URL Mapping Architecture and 486 Framework", draft-ietf-ecrit-mapping-arch-01 (work in 487 progress), December 2006. 489 [I-D.ietf-ecrit-phonebcp] 490 Rosen, B. and J. Polk, "Best Current Practice for 491 Communications Services in support of Emergency Calling", 492 draft-ietf-ecrit-phonebcp-01 (work in progress), 493 March 2007. 495 [I-D.ietf-ecrit-requirements] 496 Schulzrinne, H. and R. Marshall, "Requirements for 497 Emergency Context Resolution with Internet Technologies", 498 draft-ietf-ecrit-requirements-13 (work in progress), 499 March 2007. 501 [I-D.ietf-ecrit-security-threats] 502 Taylor, T., "Security Threats and Requirements for 503 Emergency Call Marking and Mapping", 504 draft-ietf-ecrit-security-threats-04 (work in progress), 505 April 2007. 507 [I-D.schulzrinne-location-hiding-requirements] 508 Schulzrinne, H., "Location Hiding: Problem Statement and 509 Requirements", July 2007. 511 [I-D.barnes-geopriv-lo-sec] 512 Barnes, R., "GEOPRIV Security Requirements", July 2007. 514 [TS-24.229] 515 "TS 24.229, 3rd Generation Partnership Project; Internet 516 Protocol (IP) multimedia call control protocol based on 517 Session Initiation Protocol (SIP) and Session Description 518 Protocol (SDP); Stage 3, (Release 7)", June 2007. 520 [TS-23.167] 521 "TS 23.167, 3rd Generation Partnership Project; Technical 522 Specification Group Services and System Aspects; IP 523 Multimedia Subsystem (IMS) emergency sessions (Release 524 7)", June 2007. 526 Appendix A. The 3GPP Emergency Services Architecture 528 The description in this section re-uses terminology introduced in 529 this document rather than using native 3GPP introduced terminology. 531 The basic idea of the 3GPP emergency services architecture, based on 533 [TS-24.229]/[TS-23.167], is shown in Figure 2 and is characterized by 534 the difference that emergency services support is provided by the 535 ISP/IAP (or a closely associated entity). This has the following 536 consequences: 538 o A SIP-based signaling profile needs to be standardized for 539 interaction between the SIP UA and the SIP proxy in the ISP/IAP/ 540 visited VSP/ASP. For the 3GPP emergency architecture IMS was 541 chosen as the profile, i.e., a flavor of IETF SIP. This exchange 542 is shown in (1). 544 o The SIP proxy responsible for emergency call routing needs to 545 determine location information of the end point. Since the SIP 546 proxy and the location server are both located in the ISP/IAP (or 547 in a closely associated entity) local information, such as IP 548 addresses, cell identifiers, MAC addresses or similar identifiers 549 are sufficient. Determining the address of the PSAP is also a 550 local matter since there is a relationship between the ISP/IAP and 551 the PSAP operator responsible for a specific geographic region. 552 This exchange is shown in (2). 554 o To provide identity information for the emergency call to the PSAP 555 operator it is necessary to interact with the user's home VSP/ASP 556 (in the roaming case). This is shown with the message interaction 557 in (3). 559 o The interaction between the ISP/IAP/visited VSP/ASP and the PSAP 560 operator is a national matter and is currently not specified. 562 The obligations for the different parties are as follows: 563 End Host: 565 * The end host needs to support the IMS-specific SIP profile. 566 The detailed steps are described in Section 6.1 of [TS-23.167]. 567 End hosts that do not support this specific version of SIP 568 (including the specific authentication mechanisms) cannot be 569 supported. 571 * PIDF-LO [RFC4119] may need to be supported to allow the end 572 host to attach GPS available location information. Other 573 location protocols, such as the Secure User Plane Location 574 protocol (SUPL), may be needed in special cases. See Section 575 7.6 of [TS-23.167] for a detailed considerations on how to 576 retrieve location information. 578 ISP/IAP/visited VSP/ASP: 580 * The SIP proxy in the access network needs to understand the 581 IMS-specific SIP profile and the protocols used for (2), (3) 582 and (4), whereby (4) is not specified. The detailed steps are 583 described in Section 6.2.1, Section 6.2.2, 6.2.3 of 584 [TS-23.167]. On a high-level basis, the responsibility is 585 mainly to understand the SIP protocol (and the corresponding 586 extensions), to determine the end host's location information, 587 to perform the necessary interaction for verifying the 588 emergency caller's identity via the interaction with the home 589 VSP and finally to route the emergency call to the correct 590 PSAP. 592 Home VSP/ASP: 594 * The home VSP/ASP needs to provide SIP call back functionality 595 and asserts the identity of the emergency caller. A roaming 596 agreement is assumed to be in place between the home and the 597 visted VSP/ASP. Note that the security mechanism used to 598 authenticate the end host to the Home VSP needs to prevent the 599 visited VSP from being able to later impersonate the user. 600 Note that this authentication procedure is likely be done 601 during the network access authentication procedure rather than 602 during the SIP signaling exchange. 604 PSAP: 606 * This protocol interaction is not specified but assumed to be 607 based on SIP. 609 +---------------------------+ 610 | | 611 | Emergency Network | 612 | Infrastructure | 613 | | 614 | +----------+ +----------+ | 615 | | PSAP | | ESRP | | 616 | | | | | | 617 | +----------+ +----------+ | 618 +-------------^-------------+ 619 | 620 | (4) 621 +------------------------+-------+ +-----------------------+ 622 | ISP/IAP | | | Home VSP/ASP | 623 | Visited VSP/ASP | | | | 624 |+----------+ v | | +----------+ | 625 || LCS | (2) +----------+ | (3) | | Identity | | 626 || |<--+-->| ESRP / |<+-----+-+--->| Provider | | 627 |+----------+ | | SIP Proxy| | | | +----------+ | 628 |+----------+ | +----------+ | | | +----------+ | 629 || Mapping |<--+ ^ | | | | SIP | | 630 || Database | | | +-+--->| Proxy | | 631 |+----------+ | | | +----------+ | 632 +------------------------+-------+ +-----------------------+ 633 | 634 | (1) 635 | 636 | 637 v 638 +----------+ 639 | End | 640 | Host | 641 +----------+ 643 Figure 2: Overview of the 3GPP Emergency Services Architecture 645 Authors' Addresses 647 Hannes Tschofenig 648 Nokia Siemens Networks 649 Otto-Hahn-Ring 6 650 Munich, Bavaria 81739 651 Germany 653 Email: Hannes.Tschofenig@nsn.com 654 URI: http://www.tschofenig.com 655 Henning Schulzrinne 656 Columbia University 657 Department of Computer Science 658 450 Computer Science Building 659 New York, NY 10027 660 US 662 Phone: +1 212 939 7004 663 Email: hgs+ecrit@cs.columbia.edu 664 URI: http://www.cs.columbia.edu 666 Full Copyright Statement 668 Copyright (C) The IETF Trust (2007). 670 This document is subject to the rights, licenses and restrictions 671 contained in BCP 78, and except as set forth therein, the authors 672 retain all their rights. 674 This document and the information contained herein are provided on an 675 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 676 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 677 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 678 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 679 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 680 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 682 Intellectual Property 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed to 686 pertain to the implementation or use of the technology described in 687 this document or the extent to which any license under such rights 688 might or might not be available; nor does it represent that it has 689 made any independent effort to identify any such rights. Information 690 on the procedures with respect to rights in RFC documents can be 691 found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of an 695 attempt made to obtain a general license or permission for the use of 696 such proprietary rights by implementers or users of this 697 specification can be obtained from the IETF on-line IPR repository at 698 http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at 704 ietf-ipr@ietf.org. 706 Acknowledgment 708 Funding for the RFC Editor function is provided by the IETF 709 Administrative Support Activity (IASA).