idnits 2.17.1 draft-taylor-sipping-emerg-scen-01.txt: -(818): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 182 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 2003) is 7492 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '4' on line 967 looks like a reference -- Missing reference section? '6' on line 968 looks like a reference -- Missing reference section? '8' on line 352 looks like a reference -- Missing reference section? '9' on line 353 looks like a reference -- Missing reference section? '10' on line 499 looks like a reference -- Missing reference section? '11' on line 885 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Session Initiation Protocol Investigations 3 Internet Draft Tom Taylor 4 Document: draft-taylor-sipping-emerg-scen-01.txt Nortel Networks 5 Expires: April 2004 October 2003 7 SIP Emergency Assistance Scenarios 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This document examines the scenarios within which SIP phones may be 37 used to contact emergency call centres. Beginning with an overview 38 of the high level system requirements for contacting emergency call 39 centres in the PSTN, the scenarios involving stationary or nomadic 40 SIP phones are described and then alternative strategies for 41 supporting the information flows for the scenarios needed to meet 42 these requirements are examined. The major finding from the point 43 of view of SIP standardization is that it is essential in a number 44 of scenarios (and helpful for all) if a location header field could 45 be added either by the SIP phone or by a proxy to indicate the 46 location of the phone in a machine-readable way. 48 Conventions used in this document 50 This document has no normative intent, hence the usual invocation of 51 interpretation according to RFC 2119 does not apply. 53 Table of Contents 55 1 Introduction..................................................3 57 2 Definitions and Abbreviations.................................4 59 3 Existing Emergency Call System Description....................5 60 3.1 System Components.........................................5 61 3.2 System Requirements.......................................6 62 3.3 Legacy System Operation...................................7 64 4 SIP Phones and Emergency Services.............................8 66 4.1 A General Look At The Problem.............................8 68 4.2 SIP Phone Deployment Scenarios............................9 69 4.2.1 The Stationary SIP Phone.............................9 70 4.2.2 Nomadic Phone Direct To PSTN Gateway................10 71 4.2.3 Nomadic SIP Phone To Intermediate SIP Entity........11 72 4.2.4 Target ECC Cannot Be Reached........................12 74 4.3 System Requirements applied to SIP Phones................13 75 4.3.1 Identifying Emergency Calls.........................14 76 4.3.2 Call Processing Recognition and Routing Of Emergency 77 Calls...............................................15 78 4.3.3 Calling Party Number As Key To The Location Database17 79 4.3.4 Determining Caller Location.........................17 80 4.3.5 Retaining Access To The Caller......................17 81 4.3.6 Retaining Access To The Caller......................17 82 4.3.7 Minimum Delay In Call Setup.........................18 83 4.3.8 Caller Accountability...............................18 85 5 Conclusions..................................................19 87 6 Security Considerations......................................19 89 7 References...................................................19 91 8 Acknowledgments..............................................20 93 9 Author's Address.............................................21 95 1 Introduction 97 With use of VoIP growing and the potential for existing 98 implementations to result in problems and delays in organising 99 responses for ECCs, there is now an urgency to arrive at emergency 100 call standards. 102 This draft is concerned with the use of SIP phones to obtain 103 emergency police, fire, or medical assistance through emergency call 104 centres (ECCs) reached through the PSTN. From a legacy telephone 105 set, these centres are typically reached by dialling a reserved 106 number such as 911 in North America, 999 historically in the UK, 112 107 in the European Community in general, or 000 in Australia. 108 (Globally there are about 60 different emergency services numbers in 109 use [4].) The existing system is designed with a number of 110 operating assumptions which fail to hold in the SIP context. This 111 document explores alternatives for allowing the emergency system to 112 continue to be effective under various scenarios involving the use 113 of a SIP phone. It identifies the major issues and discusses some 114 of the mechanisms that might be used to address these issues. 116 This document uses the term SIP phone to denote any device which 117 uses SIP signalling to establish and take down voice and/or text 118 calls. The analysis does not depend on the actual form of the 119 device (physical phone device, PC running a software based SIP 120 client, or whatever). 122 SIP phones can be used in stationary, nomadic, or mobile modes, an 123 important distinction resulting in different scenarios. In both 124 nomadic and mobile usage, the SIP phone changes its physical point 125 of attachment to the IP network. The difference between the two is 126 that in mobile usage the change can occur in mid-call. In nomadic 127 usage, the change occurs only between calls. 129 Wi-Fi introduces a grey area where the SIP phone can move about in 130 mid-call, but not change its point of network access. From the 131 point of view of emergency services, this may or may not matter. 132 Movement within a home is equivalent to stationary usage; movement 133 within a large airport terminal is more like mobile usage in terms 134 of the difficulty of determining the exact location of the 135 emergency, though in most ways it should be viewed as nomadic. 137 This document considers only stationary and nomadic usage scenarios. 138 Mobile usage has its own set of potential solutions which are being 139 developed separately, specifically in the context of cellular 140 service. 142 As a final point, this document is limited to cases where the ECC is 143 part of the legacy network. Two related documents deal with cases 144 that have some aspects in common with the scenarios discussed in 145 this document. For considerations of requirements when the ECC is 146 connected directly to the IP network, see Schulzrinne [6]. For a 147 description of a global, SIP-based mechanism for identifying 148 emergency calls, see Schulzrinne [4]. The following table 149 summarizes the relationship between the scenarios addressed by this 150 document and the other documents: 152 ECC IP-ECC 153 ---------------------------------------------- 154 Legacy PSTN N/A [6] 155 phones 157 SIP (existing) This document. [6] 159 SIP (enhanced) [4] [4],[6] 161 ECC: Emergency Call Centre in the PSTN 162 IP-ECC: IP-enabled Emergency Call Centre -- reached directly 163 through the internet. 165 2 Definitions and Abbreviations 167 CgPN 169 Calling Party Number, used at the ECC to map to a caller location. 170 Also termed "calling number" in this document. 172 Callback number 174 An additional number provided by the PSTN gateway under some 175 circumstances. The emergency call taker can complete a call back to 176 this number to reach the SIP phone from which the original emergency 177 call was placed. 179 ECC 181 Emergency Call Centre -- a collection of call takers and supporting 182 equipment connected to the PSTN, whose primary purpose is to 183 dispatch emergency services (police, fire department, medical aid), 184 either directly or by connection to a separate centre, in response 185 to incoming calls. 187 Target ECC 188 For a particular call, an Emergency Call Centre capable of 189 dispatching emergency service to the caller's location. ECCs 190 typically serve specific geographic regions and must hand off calls 191 where the emergency is outside that region. 193 IP-ECC 195 Internet Protocol ECC -- an ECC that uses Internet protocols, such 196 as SIP for call signaling, RTP for media delivery, to receive 197 emergency calls. Requirements related to IP-ECC access are out of 198 scope for this document, but are considered in [6]. 200 PSTN 202 Public Switched Telephone Network: the legacy circuit network. 204 PBX 206 Private Branch Exchange -- a call processing system serving a 207 private telephone network. 209 DID 211 Direct-Inward-Dialing, a PSTN service allowing callers from the PSTN 212 to dial individual extensions sitting behind a PBX using PSTN 213 telephone numbers. 215 ISDN 217 Integrated Services Digital Network. 219 3 Existing Emergency Call System Description 221 This section provides a description of the legacy emergency call 222 services system, the high level requirements for this system, a 223 discussion of how this system operates, and the challenges that must 224 be dealt with. This provides a starting point for the discussion of 225 how this system might deal with emergency calls initiated from a SIP 226 phone. 228 3.1 System Components 230 The legacy PSTN emergency assistance system typically consists of 231 the following components. (Note: in terms of North America, the 232 term "legacy" is used to refer to "Enhanced 911" functionality.) 234 - the telephone set used by the caller 235 - the circuit connecting the telephone set to the telephone network 237 - the telephone network, consisting of switches and trunk circuits 239 - the circuits connecting the ECC to the telephone network 241 - a mapping database, providing geographical location keyed on 242 calling number information supplied by the telephone network 244 - the ECC itself, staffed by call takers who take incoming calls, 245 dispatch them to the appropriate emergency services, and remain 246 in touch with the caller as required to coordinate the provision 247 of these services and provide immediate advice 249 - circuits leading to the emergency service organizations (police, 250 fire, etc.) 252 In addition to the components just listed, the legacy system 253 typically also provides a text-based emergency call service to serve 254 the deaf and those with a hearing or speech impediment. In some 255 countries, such as Australia and Britain, a different number may be 256 dialed to initiate the call to a text-based emergency call service. 257 In other places such as North America, all calls go to the same 258 number, and a tone detector is attached to each call incoming to the 259 ECC to detect the use of a text communications device automatically. 260 From the point of view of this analysis, the system requirements and 261 operation for text-based communications are similar to those for 262 voice-based emergency calling, except for the difference in medium. 264 3.2 System Requirements 266 The full requirements for emergency call services are country 267 specific, and include extensive technical detail. It is not the 268 intent to replicate those detailed requirements here. Rather, this 269 section is intended to identify the key principles that underlie 270 most emergency call services to provide the context for evaluating 271 the provision of these services from SIP phones. 273 The emergency services system is generally built around the 274 following requirements: 276 (1) The caller requires an easily-remembered, location-independent 277 means of identifying an emergency call. Moreover, in countries 278 where this is applicable it must be possible to indicate whether 279 this is a voice call or one to be directed to a text ECC. 281 (2) Call processing entities must recognize emergency calls and 282 route them to the target ECC either directly or by further onward 283 connection to a service-specific despatching centre (i.e., one which 284 can dispatch emergency service resources to the caller's location). 285 (Note that the system also needs to be able to handle the case where 286 a caller is reporting an emergency located somewhere else, but this 287 can be assumed to be the ECC's task.) 289 (3) The telephone network should be supplied with, or enabled to 290 supply, a calling party number or other unique geographic indicator, 291 that can serve as a key to the mapping database. 293 (4) The caller's location needs to be supplied during call set-up, 294 or by being keyed by calling party number or other unique 295 identifier, is available in the mapping database. In this document 296 this is assumed to happen as a configuration step in advance of the 297 call. 299 (5) At least in some jurisdictions, it is required that the ECC 300 call taker can stay in touch with the caller, even though the 301 telephone set goes on hook for an intervening period. 303 (6) The telephone network should be supplied with, or enabled to 304 supply, a number which enables the ECC to call back to the SIP phone 305 that made the original emergency call. 307 (7) Again depending on the jurisdiction, emergency calls may be 308 given priority handling in call processing and may also be given 309 high quality media connections. (The quality of media connections 310 is outside the scope of this document.) 312 (8) The caller can be held accountable for the call, to dissuade 313 callers from misuse of the system. In particular callers should not 314 be able to withold calling number or location information when using 315 emergency codes. Moreover, call records should be stored for at 316 least the initial and final steps in the call path through each 317 service provider's network. 319 3.3 Legacy System Operation 321 An emergency call in the legacy system begins when the caller dials 322 the local emergency services number. The switch serving the 323 caller's line receives the dialed digits, identifies the call as an 324 emergency call, and determines the route to the target ECC through 325 configuration of telephony routing data. Configuration also 326 associates a calling number with the caller's line or trunk. The 327 switch and succeeding telephone network route the call and pass the 328 calling number to the ECC. In the ECC, the calling number is 329 presented to the mapping database, which returns the caller's 330 location. This is presented to the emergency call taker to speed-up 331 call handling and response times on all calls, and to be of 332 especially important assistance in cases where the caller is unable 333 to provide the information. (This is now part of the regulatory 334 regime for emergency calls in the US and European Community). 336 A special arrangement at the switch serving the ECC may allow the 337 emergency call taker to hold open the voice path back to the caller 338 as long as necessary, even if the caller goes on-hook to help 339 establish if the call is genuine. Note that this functionality is 340 not supported for ISDN. 342 For further checks after call connection, and when it is not 343 possible to hold the line, the ECC call taker needs a number to call 344 back. For ordinary lines, this is the calling number. For PBXs, 345 except as noted below, all inward calls must go through the PBX main 346 number. It is up to the the party reached at that number to route 347 the call to the area of the emergency. The exception is when the 348 PBX has DID service and a special arrangement has been made with the 349 PSTN service provider(s) to whose network(s) the PBX connects. In 350 that case, the PBX can present the caller's extension number as a 351 callback number. The PSTN passes this on to the the emergency call 352 taker. Full signalling details are given in [8] section 2.1.2.3, to 353 which [9] provides background. 355 In the legacy network, PSTN service providers are responsible for 356 maintaining the ECC mapping database and, of course, the routing 357 information and Calling Party Number information by configuration of 358 data in their switches based on knowing call's originating location. 359 Updates are required every time the relationship between incoming 360 circuit, the calling number assigned to that circuit, and the 361 location of the terminal at the other end of that circuit changes. 362 It can typically take a day to put through a change in the ECC 363 mapping database, meaning that advance coordination is required to 364 ensure consistency between configuration and reality. 366 4 SIP Phones and Emergency Services 368 4.1 A General Look At The Problem 370 SIP phones introduce a number of new elements into the system and 371 change many of the underlying assumptions. 373 A primary consideration is that the SIP phone is configurable by the 374 user, has intelligence, and typically registers itself with elements 375 of the local network (DHCP server, SIP registrar) which can pass it 376 configuration data when it first comes into operation. Call 377 signalling passes through other intelligent elements -- SIP proxies 378 perhaps, and a PSTN gateway always -- before reaching the telephone 379 network. The SIP phone may or may not be associated with a 380 telephone number persisting beyond the duration of a single call. 382 At the transport level, the SIP phone's physical point of attachment 383 is to an IP subnetwork rather than a telephone line. This 384 introduces additional complexity for emergency call systems. A 385 telephone line has only a single physical appearance, but it is 386 possible to connect to an IP subnetwork from many different 387 locations. A management system may be able to detect activation of 388 the SIP device in a particular location, either directly or through 389 LAN equipment, but it is difficult for the management system to 390 unambiguously detect that the device is a SIP device unless it is 391 informed of this either by the SIP device or by the SIP registrar. 393 Both signalling and media may be subject to routing delays, 394 congestion, and the actions of middleboxes or encryption as they 395 pass through the IP network. 397 4.2 SIP Phone Deployment Scenarios 399 This section identifies the SIP phone deployment scenarios to be 400 considered with regard to the fundamental requirements identified in 401 section 3.2. Scenarios 4.2.1 through 4.2.3 assume that emergency 402 calls can be routed, directly or indirectly, from the SIP Phone to a 403 PSTN gateway that in turn has the routing information required to 404 reach the target ECC. Scenario 4.2.4 is the case where the target 405 ECC is not reachable from the caller's location. 407 4.2.1 The Stationary SIP Phone 409 This scenario features stationary SIP phones with fixed locations, 410 routing emergency calls either through other SIP entities or 411 directly to a PSTN gateway. This is the simplest case, one that 412 might be encountered in a corporate network. The following diagram 413 highlights the architecture involved for this scenario. 415 +-------+ 416 | SIP | *Fixed Location 417 | Phone | 418 +-------+ 419 | | * Known GW 420 | |----- to reach 421 | \ target ECC 422 +-----+ \ +------+ +-----+ +------+ 423 / \ \--| PSTN | / \ |Target| 424 / SIP \------| GW |-----/ PSTN \-------| ECC | 425 \ Network / +------+ \ / +------+ 426 \ / | \ / | 427 +-----+ | +----+ | 428 | | | 429 +------------+ +------------------+ +-------------+ 430 | Routing DB | | Routing DB | | Mapping DB | 431 | Info for GW| | Info for trunk | | CgPN -> | 432 | selection. | | selection, poss. | | location | 433 +------------+ | callback number | +-------------+ 434 +------------------+ 436 When an intermediate SIP entity is involved in routing the call, if 437 more than one PSTN gateway is available, the intermediate entity 438 needs to know which one is the appropriate one for this SIP phone. 439 Some sort of routing database is required, keyed by the contents of 440 selected header fields in the INVITE. The issues of which header 441 field to use and how to populate the routing database are considered 442 in section 4.3. 444 The PSTN gateway also needs to do routing. There are three steps: 445 - determination of the target ECC (if more than one can be reached) 446 - selection of a trunk group to a PSTN switch which will route to 447 that ECC 448 - possibly, selection of a specific trunk corresponding to the SIP 449 phone's location. 451 In the simplest case there are no choices and routing is 452 straightforward once it is recognized that this is an emergency 453 call. When choices do exist, a routing database is needed. As at 454 intermediate SIP entities, this is keyed on the contents of an 455 appropriate header field in the INVITE. The issues involved are 456 similar to those for routing at intermediate SIP entities. 458 Where the special arrangement exists that allows the PSTN gateway to 459 pass along a callback number, the PSTN gateway also needs to be 460 provided with a callback number to use. This is another issue 461 considered in section 5. 463 Because the SIP phone is stationary, it is feasible for the routing 464 databases to be maintained by configuration. This is the 465 distinctive feature of scenario 4.2.1. 467 4.2.2 Nomadic Phone Direct To PSTN Gateway 469 In this case, the SIP phone may be moved from one location to 470 another between calls. The SIP phone is configured to route 471 emergency calls directly to a PSTN gateway, which by hypothesis has 472 the routing information to reach the target ECC if it can identify 473 it from incoming call signalling. The architecture looks very 474 similar to that in scenario 4.2.1: 476 +-------+ 477 | SIP | * Visiting 478 | Phone | 479 +-------+ * Known GW 480 | to reach 481 | target ECC 482 | +------+ +-----+ +------+ 483 | | PSTN | / \ |Target| 484 +----------| GW |-----/ PSTN \-------| ECC | 485 +------+ \ / +------+ 486 | \ / | 487 +------------+ +----+ +-------------+ 488 | Routing DB | | Mapping DB | 489 +------------+ | CgPN -> | 490 | location | 491 +-------------+ 493 Because the SIP phone is nomadic, several aspects of this scenario 494 become open to question: 496 1. How does the SIP phone recognize emergency calls? 498 2. How does it know the address of the PSTN gateway? (One possible 499 answer is through use of the DHCP option defined in [10], 500 supported by suitable conventions.) 502 3. How is the routing database at the gateway updated to be 503 consistent with the current location of the SIP phone? 505 4. Alternatively, is it more workable for the SIP phone to signal 506 its location and for the gateway to use this as a key to the 507 routing database? If so, how does the SIP phone learn its 508 location and how can it signal that location in SIP? 510 5. If the SIP phone does not supply a callback number, where does it 511 come from? 513 Discussion of possible answers to these questions is found in 514 section 4.3. 516 4.2.3 Nomadic SIP Phone To Intermediate SIP Entity 518 In this scenario, the SIP phone is configured to route emergency 519 calls to a SIP network element other than the PSTN gateway. The SIP 520 network element selects the PSTN gateway which can reach the target 521 ECC. Again the architecture looks very much like that in scenario 522 4.2.1: 524 +-------+ 525 | SIP | * Visiting 526 | Phone | 527 +-------+ * Known GW 528 | to reach 529 | target ECC 530 +-----+ +------+ +-----+ +------+ 531 / \ | PSTN | / \ |Target| 532 / SIP \------| GW |-----/ PSTN \-------| ECC | 533 \ Network / +------+ \ / +------+ 534 \ / | \ / | 535 +-----+ | +----+ | 536 | | | 537 +------------+ +-------------+ +-------------+ 538 | Routing DB | | Routing DB | | Mapping DB | 539 | Info for GW| +-------------+ | CgPN -> | 540 | selection. | | location | 541 +------------+ +-------------+ 543 In this scenario, most of the questions raised for scenario 4.3.2 544 are still open. There is no longer the need for the SIP phone to 545 know which gateway to route to. However, the problem has simply 546 been put off a step: the questions now are how the SIP phone is 547 configured with the address of the next-hop SIP network element, and 548 how the latter knows the SIP phone's location so it can make a PSTN 549 gateway selection. This, too, is discussed section 4.3 below. 551 4.2.4 Target ECC Cannot Be Reached 553 In the previous scenarios, the SIP phone could reach a PSTN gateway 554 which in turn had the routing information to reach the target ECC 555 while preserving the emergency nature of the call. In scenario 556 4.2.4 the assumption is that the SIP network to which the SIP phone 557 is attached does not have this information. One example where this 558 might occur is that of a someone dialling in to a home network 559 remote from the caller's location. The architecture looks as 560 follows, with the two basic cases (from the point of view of the 561 PSTN gateway) marked as (1) and (2): 563 +-------+ 564 | SIP | 565 | Phone |\ 566 +-------+ \ 567 | \ 568 | \ 569 +-----+ \ +------+ +-----+ +------+ 570 / \ \--| PSTN | / \ (1) |Other | 571 / SIP \------| GW |-----/ PSTN \-------| ECC |-+ 572 \ Network / +------+ \ / +------+ | 573 \ / | \ / \ | | 574 +-----+ | +----+ \ (1a)| (1b)| 575 | (2)\ | | 576 +-------------+ \ | | 577 | Routing DB | \ +------+ | 578 +-------------+ \-|Target| | 579 /-------| ECC | | 580 / +------+ | 581 +-------------+ | / 582 | Mapping DB | +----------+ 583 | CgPN -> | | Local | 584 | location | | Emergency| 585 +-------------+ | Services | 586 +----------+ 588 The two basic possibilities in this scenario are these: 590 (1) Continuation as emergency call 592 In this case, the PSTN gateway continues the call as an emergency 593 call and routes it to an ECC local to the gateway. At that point, 594 it is up to the emergency call taker to determine directly from the 595 caller the location of the emergency. The emergency call taker then 596 transfers the call, possibly as an ordinary call, either to the 597 target ECC (case 1(a)) or to the required emergency service 598 organization in the locality of the caller (case 1(b)). 600 The distinction between 1(a) and 1(b) is beyond the scope of this 601 paper, since it comes about independently of the source of the 602 emergency call. A key point to recognize, however, is that while 603 case (1) (i.e., emergency reported to a non-local ECC) can happen in 604 the legacy network, the frequency with which it happens may be much 605 increased as nomadic SIP phones come into more common use. This 606 likelihood may cause emergency service planners to reconsider 607 existing solutions if they will not scale to higher call volumes. 609 (2) Continuation as ordinary call to ECC administrative number 611 This case assumes that the PSTN gateway has access to a database 612 keyed by caller location and listing ordinary telephone numbers by 613 means of which the target ECC can be reached. Such a database 614 exists as a service in the USA. 616 In this case, the PSTN gateway cannot signal the call to the PSTN as 617 an emergency call. However, it is able to direct it to the target 618 ECC without the double handling and consequent delay implied in case 619 (1). 621 The key SIP-side issue in this case is how the PSTN gateway can 622 determine the SIP phone's location so it can choose the target ECC. 623 Additionally, even for an ordinary call, call signalling to the ECC 624 will contain the calling party number and may contain a separate 625 callback number. The PSTN gateway provides the latter directly and, 626 depending on whether it is part of a public or private network, at 627 least indicates the calling party number through its choice of 628 outgoing trunk circuit. The next section discusses how the PSTN 629 gateway might obtain the necessary information to provide these 630 values. 632 4.3 System Requirements applied to SIP Phones 634 The mechanisms required for the SIP phone and the supporting IP 635 network to meet the system requirements may vary with the 636 circumstances under which the SIP phone is deployed. This section 637 takes a general look at the system requirements first identified in 638 section 3.2, discusses these requirements as they apply to the four 639 deployment scenarios described in section 4.2, and identifies 640 potential ways of meeting these requirements. 642 4.3.1 Identifying Emergency Calls 644 The problem of how SIP phones can identify emergency calls has been 645 described in [4]. The basic problem in SIP terms is how to 646 formulate the Request-URI. [4] argues for a universal emergency SIP 647 URI, sip: or sips:sos@domain, to relieve the user of the need to 648 learn the local emergency number and configure or dial it when he or 649 she is on the road. A corollary of this arrangement is that the 650 user interface to the SIP phone provides direct access to emergency 651 calling, as by a special button, predefined directory entry, or 652 dialled code. 654 Unless the user interface makes the way to do emergency calling 655 totally obvious, however, there is always the possibility that a 656 caller unfamiliar with the details of use of the SIP phone dials the 657 local emergency number directly. This means that PSTN gateways and 658 intermediate SIP entities must be prepared to recognize both the 659 universal emergency SIP URI and the local emergency number expressed 660 as a tel: or sip:/sips: URI. 662 There is another possibility: that the SIP phone is configured to 663 recognize the local emergency number when it is dialled and convert 664 it into the universal emergency SIP URI. This may be necessary if 665 it is concluded (from discussion below) that the SIP phone must 666 recognize when it is being used for an emergency call, so it can 667 include certain information in the INVITE. How does such 668 configuration come about? The possible sources of the information 669 appear to be: 671 - the user or installer at configuration time; 673 - the DHCP server, using a SIP-specific option; 675 - the SIP registrar, using a new header field or message body in 676 its reply to carry the information. 678 How practical are these alternatives? The probability of a SIP 679 phone being borrowed to make an emergency call is likely far smaller 680 if the phone travels a lot, since a much-travelled phone is likely a 681 personal device rather than one accessible to a casual user. That 682 means that explicit dialling of the local emergency number if there 683 is a short-cut alternative is most likely in scenario 4.2.1, and 684 unlikely in scenario 4.2.4. On that basis, any of these 685 alternatives is possible in the cases where one is needed. 687 There is still the problem of distinguishing between voice and text 688 emergency calls in countries where these are routed separately. If 689 the user enters an actual emergency number, that can be the one that 690 serves the user's needs. If the configuration is by DHCP or SIP 691 registrar, it may be that selection of the appropriate number is 692 based on pre-configuration of the SIP phone as voice or text based. 694 If the "sos" solution in [4] is used, consideration must be given to 695 how the protocol will indicate a routing to the text rather than 696 voice emergency service. This could be done based on the session 697 description in the request body, but that implies that the correct 698 routing is done at the PSTN gateway rather than at a proxy. The 699 most likely alternative is to provide the indication using caller 700 preferences to indicate a preference for text media. Another 701 alternative is to reserve a specific "sos" subaddress for text 702 services (e.g. sos.text) in the same way that [4] proposes to 703 reserve subaddresses for fire, police and other specific services. 705 4.3.2 Call Processing Recognition and Routing Of Emergency Calls 707 The previous sub-section has suggested that emergency calls will be 708 identifiable by the content of the Request-URI. The user part of 709 this URI will consist either of the appropriate telephone number or 710 of a global emergency identifier, "sos". 712 Depending on the scenario, the SIP phone itself, intermediate SIP 713 entities, and in all cases the PSTN gateway, must be able to 714 recognize emergency calls in order to handle them properly. The 715 responsibilities of each of these elements have been identified in 716 preceding discussion: 718 - As discussed in section 4.3.1, the SIP phone may be required in 719 any scenario to convert from a directly dialled local emergency 720 number to the universal emergency SIP URI. 722 - Except where it can rely on intermediate entities to do the 723 routing, the SIP phone must route emergency calls to a PSTN 724 gateway. In scenarios 4.2.1 and 4.2.2, the choice of gateway 725 depends on the caller's location. 727 - Similarly, intermediate SIP network elements must route emergency 728 calls to a PSTN gateway. In scenarios 4.2.1 and 4.2.3, the 729 choice of gateway depends on the caller's location. 731 - The PSTN gateway is responsible for generating a called party 732 number on the PSTN side (based on information from the SIP 733 network) and routing on the basis of that number and, possibly, 734 the caller's location. In scenarios other than 4.2.4 case (2), 735 the called party number for all emergency calls is set to the 736 local emergency number. In scenario 4.2.4 case (2), the called 737 party number is the administrative number for the target ECC as 738 determined from the caller's location. 740 A recurring theme in this list of responsibilities is that depending 741 on the particular network involved, the SIP phone, intermediate SIP 742 entities, and/or the PSTN gateway need to know the caller's 743 location. How this can be determined? 745 For intermediate elements and the PSTN gateway, the starting point 746 must be information carried in the SIP signalling. There are two 747 basic approaches, direct or indirect: 749 - the location may be presented directly, in a new SIP header 750 field. 752 - the location may be derived indirectly, by consulting a database 753 using the content of a suitable header field as a key. 755 The direct approach requires action in the SIPPING and SIP Working 756 Groups to define the new header field. It also requires that the 757 SIP phone have this information available in the first place. As 758 usual, there is more than one way for the SIP phone to learn its 759 location: 761 - from in-built hardware (i.e., GPS) -- not likely to be a general 762 solution because of its impact on size and cost, not to mention 763 the need to add GPS capability to general-purpose computers when 764 soft clients are loaded on to them; 766 - from DHCP, using a SIP-related or preferably a more general 767 extension. The DHCP server (or SNMP, or 802.11x) obtains the 768 physical point of access of the SIP phone and maps that to 769 geographical coordinates using a database set up for the purpose. 771 - by configuration. An installer (most likely just in scenario 772 4.2.1) may know geographical coordinates. An user is more likely 773 to know just an address, if the user can even be induced to enter 774 it. This is not going to be helpful for the SIP entities that 775 have to process it. 777 The indirect approach requires two things: identification of the SIP 778 phone (as opposed to the calling user) in the SIP INVITE header, and 779 a database which intermediate SIP entities and the PSTN gateway can 780 consult to relate this identification to a location. The Contact 781 header field is the likely candidate for SIP phone identification, 782 since it derives directly from the network context of the call. 784 Creating a database to relate the Contact header field value to 785 geographical location may be complicated, since it requires network 786 access information to be brought together with SIP-level 787 information. One way is to correlate data captured by layer 2 (DHCP 788 option 82, SNMP, or 802.11x) and by the SIP registrar, if the SIP 789 phone registers itself. 791 One variant of the indirect method, depending on the scenario, is 792 for the outgoing proxy to do its database lookup, then append a 793 location header field to the INVITE header. This saves succeeding 794 SIP entities from having to do the same, and the outgoing proxy may 795 be in a privileged position to determine the SIP phone's location. 797 Since a location header field may be useful even in the indirect 798 case, it seems desirable that SIP/SIPPING get to work on 799 standardizing it. This will provide flexibility for network design 800 to meet E911 requirements. 802 4.3.3 Calling Party Number As Key To The Location Database 804 The PSTN gateway determines calling party number in onward PSTN 805 signalling either directly (if it is trusted by a PSTN service 806 provider) or indirectly through trunk selection. In either case, 807 the number used should relate to the caller's location. The issues 808 have already been discussed in the preceding section. 810 4.3.4 Determining Caller Location 812 This topic has already been discussed in section 4.3.2. 814 4.3.5 Retaining Access To The Caller 816 In the PSTN, it is an optional feature for the emergency services 817 call taker to keep the caller's line open even if the caller goes 818 on-hook temporarily. However, this requirement doesn�t necessarily 819 translate to the SIP environment since the reachability and identity 820 of the user are not restricted to a single physical line. [4] 821 discusses features at a SIP phone which would contribute toward the 822 basic objective of maintaining contact, provided that the SIP phone 823 is able to recognize an emergency call. 825 4.3.6 Enabling Call Back 827 The system should provide a number the emergency services call taker 828 can use to call back to the SIP phone. The PSTN gateway is 829 generally responsible for inserting this number into PSTN 830 signalling. There are two basic alternatives for what number it 831 presents: 833 - it can get the number from a telephone number (public or private) 834 presented explicitly in the user part of the Contact header field 835 URI. If the number was part of a private numbering plan, the 836 PSTN gateway converts it to a public number. 838 - the PSTN gateway temporarily (for a period long enough to cover 839 the duration of an emergency) assigns an otherwise unused public 840 telephone number to the SIP phone, retaining a mapping between 841 the assigned number and the contact information presented by the 842 SIP phone. 844 One point to consider in the second case is that a return call does 845 not necessarily have to reach the original caller, although this is 846 clearly preferable. Depending on circumstances, it may be 847 sufficient that a callback number reach a designated emergency phone 848 in the emergency location. This is clearly workable only where the 849 PSTN gateway knows the location of the caller and has additional 850 information on the location of emergency phones. 852 The above discussion assumes that information in the Contact header 853 field remains valid for the duration of the emergency, even if the 854 original call terminates. Appropriate measures would be required to 855 achieve this in cases where it would not otherwise be true. This 856 may require the PSTN gateway, for instance, to send repeated 857 heartbeats in the form of OPTION requests to keep firewall or NAT 858 pinholes open. 860 4.3.7 Minimum Delay In Call Setup 862 This requirement is tied to the requirement that the SIP entities 863 along the call path be able to recognize an emergency call. If they 864 can do so, they can give priority to handling of the call. 866 4.3.8 Caller Accountability 868 Caller accountability requires in the first instance that the 869 mapping between calling number as presented at the ECC and the 870 address of record of the SIP phone be preserved for audit, an 871 administrative issue. Beyond this, depending on the scenario, 872 caller identity can be vouched for by trusted entities (RFC 3325) or 873 determined by other means (RFC 3323). Either way requires that the 874 telephone network trust the gateway. Without this element of trust, 875 the chain of accountability stops at the gateway itself. 877 5 Conclusions 879 It is clear from the above discussion that determining the location 880 of the SIP phone is a key element of the emergency calling service. 881 The ability to signal that location in SIP is helpful in all cases 882 and essential in a number of scenarios. The development of a 883 suitable location header field should be given priority in the 884 SIPPING and SIP Working Groups. (Requirements for such a header 885 field are documented in [11].) 887 Discussion also made clear that configuration of the SIP phone for 888 emergency calling, including setting of its location, may make use 889 of DHCP. This possibility should be further explored to determine 890 if further standardization is required. The resulting DHCP 891 capabilities should probably have applicability to other devices 892 besides SIP phones. 894 Finally, it is apparent that a variety of engineering solutions are 895 available for providing emergency calling service. Further 896 discussion may suggest which approaches are most effective. 898 6 Security Considerations 900 Potential threats specific to emergency calling scenarios include: 902 - abuse of the service (i.e., use to make non-emergency calls). 903 This is of critical importance with hoax, false and accidental 904 calls being more than half the emergency calls received in some 905 countries. 907 - denial of service attacks upon SIP entities or critical databases 908 done by taking specific advantage of emergency calling features; 910 - denial of service attacks aimed at the ECC; 912 - unauthorized disclosure of caller location; and 914 - attacks designed to mislead intermediate SIP elements into 915 routing emergency calls to hosts other than the target PSTN 916 gateway. 918 [Will be expanded further after people have had a look.] 920 7 References 922 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 923 9, RFC 2026, October 1996. 925 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 926 Levels", BCP 14, RFC 2119, March 1997. 928 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 929 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session 930 Initiation Protocol", RFC 3261, June 2002. 932 4. H. Schulzrinne, "Emergency Services for Internet Telephony based 933 on the Session Initiation Protocol (SIP)", draft-schulzrinne- 934 sipping-sos-04.txt, Work in Progress, January 2003 (expired). 936 5. N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk, "User 937 Requirements for the Session Initiation Protocol (SIP) in Support 938 of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 939 3351, August 2002. 941 6. H. Schulzrinne, "Requirements for Session Initiation Protocol 942 (SIP)-based Emergency Calls", draft-schulzrinne-sipping- 943 emergency-req-00.txt, Work in Progress, February 2003. 945 7. J. Polk, John Schnizlein, Marc Linsner, "DHC Location Object 946 within GEOPRIV", draft-ietf-geopriv-dhcp-lo-option-00.txt, Work 947 in Progress, January 2003. 949 8. ITU-T Recommendation Q.699, "Interworking between ISDN access and 950 non ISDN access over ISDN User Part of Signalling System No. 7", 951 September 1997. 953 9. ITU-T Recommendation Q.951.3, "Stage 3 description for number 954 identification supplementary services using DSS 1 : Calling line 955 identification presentation", March 1993. 957 10. H. Schulzrinne, "Dynamic Host Configuration Protocol (DHCP-for- 958 IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 959 3361, August 2002. 961 11. James M. Polk, "Session Initiation Protocol Location 962 Requirements", work in progress. 964 8 Acknowledgments 966 Henning Schulzrinne has been trying to get people to look at this 967 problem for many years, and has led the way with his drafts [4], 968 [6], and others before them. Henning's extensive comments on an 969 earlier version of this draft have led to a major re-write which is, 970 one hopes, much improved as a result. 972 Mary Barnes and Jim McEachern 973 helped to shape the text of the initial 974 issue of this document. Dick Knight and 975 Steve Norreys helpfully contributed 976 descriptions of emergency services operation in the UK and Patrick 977 Emery did the same for Australia. The 978 present version of this Internet Draft has been strengthened by Dick 979 Knight's comments on the previous version. 981 9 Author's Address 983 Tom Taylor 984 Nortel Networks 985 1852 Lorraine Ave. 986 Ottawa, Ontario 987 Canada K1H 6Z8 988 Tel: +1 613 736 0961 989 Email: taylor@nortelnetworks.com 991 Full Copyright Statement 993 Copyright (C) The Internet Society (2003). All Rights Reserved. 995 This document and translations of it may be copied and furnished to 996 others, and derivative works that comment on or otherwise explain it 997 or assist in its implementation may be prepared, copied, published 998 and distributed, in whole or in part, without restriction of any 999 kind, provided that the above copyright notice and this paragraph 1000 are included on all such copies and derivative works. However, this 1001 document itself may not be modified in any way, such as by removing 1002 the copyright notice or references to the Internet Society or other 1003 Internet organizations, except as needed for the purpose of 1004 developing Internet standards in which case the procedures for 1005 copyrights defined in the Internet Standards process must be 1006 followed, or as required to translate it into languages other than 1007 English. The limited permissions granted above are perpetual and 1008 will not be revoked by the Internet Society or its successors or 1009 assigns. This document and the information contained herein is 1010 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1011 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,EXPRESS OR 1012 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1013 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1014 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."