From exim@www1.ietf.org Thu Oct 2 01:40:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20887 for ; Thu, 2 Oct 2003 01:40:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4wC6-0005uT-Qv for sipping-emergency-archive@odin.ietf.org; Thu, 02 Oct 2003 01:40:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h925e69N022710 for sipping-emergency-archive@odin.ietf.org; Thu, 2 Oct 2003 01:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4wC5-0005ti-1G for sipping-emergency-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 01:40:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20878 for ; Thu, 2 Oct 2003 01:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4wC1-000339-00 for sipping-emergency-web-archive@ietf.org; Thu, 02 Oct 2003 01:40:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4wC1-000332-00 for sipping-emergency-web-archive@ietf.org; Thu, 02 Oct 2003 01:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4wC3-0005tR-6E; Thu, 02 Oct 2003 01:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kKo-0005or-QK for sipping-emergency@optimus.ietf.org; Wed, 01 Oct 2003 13:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23533; Wed, 1 Oct 2003 13:00:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kKm-0002Bp-00; Wed, 01 Oct 2003 13:00:16 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1A4kKl-0002AU-00; Wed, 01 Oct 2003 13:00:15 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h91GwpA04712; Wed, 1 Oct 2003 12:58:51 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZXH80B4; Wed, 1 Oct 2003 12:58:51 -0400 Received: from nortelnetworks.com (acart1e6.ca.nortel.com [47.129.129.115]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5M06S; Wed, 1 Oct 2003 12:58:50 -0400 Message-ID: <3F7B07C8.40000@nortelnetworks.com> Date: Wed, 01 Oct 2003 12:58:48 -0400 X-Sybari-Trust: 416d1b0f aee23e9e 87716673 00000104 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: internet-drafts@ietf.org CC: sipping-emergency@ietf.org, Patrick.Emery@aca.gov.au, dick.rr.knight@bt.com, steve.norreys@bt.com, James McEachern Content-Type: multipart/mixed; boundary="------------040300010008090801030102" Subject: [Sipping-emergency] draft-taylor-sipping-emerg-scen-00.txt Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------040300010008090801030102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please find file draft-taylor-sipping-emerg-scen-00.txt attached. Title: SIP Emergency Assistance Scenarios Abstract: This document examines the scenarios within which SIP phones may be used to contact emergency call centres. Beginning with an overview of the high level system requirements for contacting emergency call centres in the PSTN, the scenarios involving stationary or nomadic SIP phones are described and then alternative strategies for supporting the information flows for the scenarios needed to meet these requirements are examined. The major finding from the point of view of SIP standardization is it would be helpful in a number of scenarios if a location header field could be added either by the SIP phone or by a proxy to indicate the location of the phone in a machine-readable way. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 --------------040300010008090801030102 Content-Type: text/plain; name="draft-taylor-sipping-emerg-scen-00.txt" Content-Disposition: inline; filename="draft-taylor-sipping-emerg-scen-00.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04e.nortelnetworks.com id h91GwpA04712 Content-Transfer-Encoding: quoted-printable Session Initiation Protocol Investigations =20 Internet Draft Tom Taylo= r=20 Document: draft-taylor-sipping-emerg-scen-00.txt Nortel Network= s=20 Expires: April 2004 October 200= 3=20 =20 =20 SIP Emergency Assistance Scenarios=20 =20 Status of this Memo=20 This document is an Internet-Draft and is subject to all provisions= =20 of Section 10 of RFC2026. =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that = =20 other groups may also distribute working documents as Internet- Drafts.=20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other document= s=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress.= "=20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 Copyright Notice=20 Copyright (C) The Internet Society (2003). All Rights Reserved.= =20 Abstract=20 This document examines the scenarios within which SIP phones may be= =20 used to contact emergency call centres. Beginning with an overview= =20 of the high level system requirements for contacting emergency call= =20 centres in the PSTN, the scenarios involving stationary or nomadic=20 SIP phones are described and then alternative strategies for=20 supporting the information flows for the scenarios needed to meet=20 these requirements are examined. The major finding from the point=20 of view of SIP standardization is it would be helpful in a number o= f=20 scenarios if a location header field could be added either by the=20 SIP phone or by a proxy to indicate the location of the phone in a=20 machine-readable way.=20 =20 =20 Taylor Expires - April 2004 [Page 1]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 Conventions used in this document=20 This document has no normative intent, hence the usual invocation o= f=20 interpretation according to RFC 2119 does not apply.=20 =20 Table of Contents=20 1 Introduction..................................................3=20 =20 2 Definitions and Abbreviations.................................4=20 =20 3 Existing Emergency Call System Description....................5=20 3.1 System Components.........................................5=20 3.2 System Requirements.......................................6=20 3.3 Legacy System Operation...................................7=20 =20 4 SIP Phones and Emergency Services.............................8=20 =20 4.1 A General Look At The Problem.............................8=20 =20 4.2 SIP Phone Deployment Scenarios............................9=20 4.2.1 The Stationary SIP Phone.............................9=20 4.2.2 Nomadic Phone Direct To PSTN Gateway................10=20 4.2.3 Nomadic SIP Phone To Intermediate SIP Entity........11=20 4.2.4 Target ECC Cannot Be Reached........................12=20 =20 4.3 System Requirements applied to SIP Phones................13=20 4.3.1 Identifying Emergency Calls.........................14=20 4.3.2 Call Processing Recognition and Routing Of Emergency=20 Calls...............................................15=20 4.3.3 Calling Party Number As Key To The Location Database17=20 4.3.4 Determining Caller Location.........................17=20 4.3.5 Retaining Access To The Caller......................17=20 4.3.6 Minimum Delay In Call Setup.........................18=20 4.3.7 Caller Accountability...............................18=20 =20 5 Conclusions..................................................19=20 =20 6 Security Considerations......................................19=20 =20 7 References...................................................19=20 =20 8 Acknowledgments..............................................20=20 =20 9 Author's Address.............................................21=20 =20 =20 =20 Taylor Expires - February 2004 [Page 2]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 1 Introduction=20 This draft is concerned with the use of SIP phones to obtain=20 emergency police, fire, or medical assistance through emergency cal= l=20 centres (ECCs) reached through the PSTN. From a legacy telephone=20 set, these centres are typically reached by dialling a reserved=20 number such as 911 in North America, 999 historically in the UK, 11= 2=20 in the European Community in general, or 000 in Australia. =20 (Globally there are about 60 different emergency services numbers i= n=20 use [4].) The existing system is designed with a number of=20 operating assumptions which fail to hold in the SIP context. This=20 document explores alternatives for allowing the emergency system to= =20 continue to be effective under various scenarios involving the use=20 of a SIP phone. It identifies the major issues and discusses some=20 of the mechanisms that might be used to address these issues.=20 This document uses the term SIP phone to denote any device which=20 uses SIP signalling to establish and take down voice and/or text=20 calls. The analysis does not depend on the actual form of the=20 device (physical phone device, PC running a software based SIP=20 client, or whatever).=20 SIP phones can be used in stationary, nomadic, or mobile modes, an=20 important distinction resulting in different scenarios. In both=20 nomadic and mobile usage, the SIP phone changes its physical point=20 of attachment to the IP network. The difference between the two is= =20 that in mobile usage the change can occur in mid-call. In nomadic=20 usage, the change occurs only between calls.=20 Wi-Fi introduces a grey area where the SIP phone can move about in=20 mid-call, but not change its point of network access. From the=20 point of view of emergency services, this may or may not matter. =20 Movement within a home is equivalent to stationary usage; movement=20 within a large airport terminal is more like mobile usage in terms=20 of the difficulty of determining the exact location of the=20 emergency, though in most ways it should be viewed as nomadic.=20 This document considers only stationary and nomadic usage scenarios= . =20 Mobile usage has its own set of potential solutions which are being= =20 developed separately, specifically in the context of cellular=20 service. =20 As a final point, this document is limited to cases where the ECC i= s=20 part of the legacy network. Two related documents deal with cases=20 that have some aspects in common with the scenarios discussed in=20 this document. For considerations of requirements when the ECC is=20 connected directly to the IP network, see Schulzrinne [6]. For a=20 description of a global, SIP-based mechanism for identifying=20 =20 =20 Taylor Expires - February 2004 [Page 3]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 emergency calls, see Schulzrinne [4]. The following table=20 summarizes the relationship between the scenarios addressed by this= =20 document and the other documents:=20 ECC IP-ECC=20 ----------------------------------------------=20 Legacy PSTN N/A [6]=20 phones=20 =20 SIP (existing) This document. [6]=20 =20 SIP (enhanced) [4] [4],[6]=20 =20 ECC: Emergency Call Centre in the PSTN=20 IP-ECC: IP-enabled Emergency Call Centre -- reached directly=20 through the internet.=20 =20 2 Definitions and Abbreviations =20 CgPN=20 Calling Party Number, used at the ECC to map to a caller location. = =20 Also termed "calling number" in this document.=20 Callback number=20 An additional number provided by the PSTN gateway under some=20 circumstances. The emergency call taker can complete a call back t= o=20 this number to reach the SIP phone from which the original emergenc= y=20 call was placed.=20 ECC=20 Emergency Call Centre -- a collection of call takers and supporting= =20 equipment connected to the PSTN, whose primary purpose is to=20 dispatch emergency services (police, fire department, medical aid)=20 in response to incoming calls.=20 Target ECC=20 For a particular call, an Emergency Call Centre capable of=20 dispatching emergency service to the caller's location. ECCs=20 typically serve specific geographic regions and must hand off calls= =20 where the emergency is outside that region.=20 =20 =20 Taylor Expires - February 2004 [Page 4]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 IP-ECC=20 Internet Protocol ECC -- an ECC that uses Internet protocols, such=20 as SIP for call signaling, RTP for media delivery, to receive=20 emergency calls. Requirements related to IP-ECC access are out of=20 scope for this document, but are considered in [6].=20 PSTN=20 Public Switched Telephone Network: the legacy circuit network.=20 PBX=20 Private Branch Exchange -- a call processing system serving a=20 private telephone network.=20 DID=20 Direct-Inward-Dialing, a PSTN service allowing callers from the PST= N=20 to dial individual extensions sitting behind a PBX using PSTN=20 telephone numbers.=20 ISDN=20 Integrated Services Digital Network.=20 =20 3 Existing Emergency Call System Description=20 This section provides a description of the legacy emergency call=20 services system, the high level requirements for this system, a=20 discussion of how this system operates, and the challenges that mus= t=20 be dealt with. This provides a starting point for the discussion o= f=20 how this system might deal with emergency calls initiated from a SI= P=20 phone.=20 3.1 System Components=20 The legacy PSTN emergency assistance system typically consists of=20 the following components. (Note: in terms of North America, the=20 term "legacy" is used to refer to "Enhanced 911" functionality.)=20 - the telephone set used by the caller=20 - the circuit connecting the telephone set to the telephone networ= k=20 - the telephone network, consisting of switches and trunk circuits= =20 =20 =20 Taylor Expires - February 2004 [Page 5]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 - the circuits connecting the ECC to the telephone network=20 - a mapping database, providing geographical location keyed on=20 calling number information supplied by the telephone network=20 - the ECC itself, staffed by call takers who take incoming calls,=20 dispatch them to the appropriate emergency services, and remain=20 in touch with the caller as required to coordinate the provision= =20 of these services and provide immediate advice=20 - circuits leading to the emergency service organizations (police,= =20 fire, etc.)=20 In addition to the components just listed, the legacy system=20 typically also provides a text-based emergency call service to serv= e=20 the deaf and those with a hearing or speech impediment. In some=20 countries, such as Australia, a different number may be dialed to=20 initiate the call to a text-based emergency call service. In other= =20 places, such as North America and Britain, all calls go to the same= =20 number, and a tone detector is attached to each call incoming to th= e=20 ECC to detect the use of a text communications device automatically= . =20 From the point of view of this analysis, the system requirements an= d=20 operation for text-based communications are similar to those for=20 voice-based emergency calling, except for the difference in medium.= =20 3.2 System Requirements=20 The full requirements for emergency call services are country=20 specific, and include extensive technical detail. It is not the=20 intent to replicate those detailed requirements here. Rather, this= =20 section is intended to identify the key principles that underlie=20 most emergency call services to provide the context for evaluating=20 the provision of these services from SIP phones. =20 The emergency services system is generally built around the=20 following requirements:=20 (1) The caller requires an easily-remembered, location-independen= t=20 means of identifying an emergency call. Moreover, in countries=20 where this is applicable it must be possible to indicate whether=20 this is a voice call or one to be directed to a text ECC.=20 (2) Call processing entities must recognize emergency calls and=20 route them to the target ECC (i.e., one which can dispatch emergenc= y=20 service resources to the caller's location). (Note that the system= =20 also needs to be able to handle the case where a caller is reportin= g=20 an emergency located somewhere else, but this can be assumed to be=20 the ECC's task.)=20 =20 =20 Taylor Expires - February 2004 [Page 6]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 (3) The telephone network can supply a calling party number that=20 can serve as a key to the mapping database.=20 (4) The caller's location, keyed by calling party number, is=20 available in the mapping database. In this document this is assume= d=20 to happen as a configuration step in advance of the call.=20 (5) At least in some jurisdictions, it is required that the ECC=20 call taker can stay in touch with the caller, even though the=20 telephone set goes on hook for an intervening period. Alternativel= y=20 the ECC call taker must be given a callback number -- one which can= =20 be dialled to reach the original caller.=20 (6) Again depending on the jurisdiction, emergency calls may be=20 given priority handling in call processing and may also be given=20 high quality media connections. (The quality of media connections=20 is outside the scope of this document.)=20 (7) The caller can be held accountable for the call, to dissuade=20 callers from misuse of the system.=20 3.3 Legacy System Operation=20 An emergency call in the legacy system begins when the caller dials= =20 the local emergency services number. The switch serving the=20 caller's line receives the dialed digits, identifies the call as an= =20 emergency call, and determines the route to the target ECC through=20 configuration of telephony routing data. Configuration also=20 associates a calling number with the caller's line or trunk. The=20 switch and succeeding telephone network route the call and pass the= =20 calling number to the ECC. In the ECC, the calling number is=20 presented to the mapping database, which returns the caller's=20 location. This is presented to the emergency call taker, who may=20 need it if the caller is unable to provide the information. =20 A special arrangement at the switch serving the ECC may allow the=20 emergency call taker to hold open the voice path back to the caller= =20 as long as necessary, even if the caller goes on-hook. The call=20 taker can thus ring the caller's line in the on-hook or other=20 situations where it might be necessary. Note that this=20 functionality is not supported for ISDN.=20 Where this arrangement does not apply, the ECC call taker needs a=20 number to call back. For ordinary lines, this is the calling=20 number. For PBXs, except as noted below, all inward calls must go=20 through the PBX main number. It is up to the the party reached at=20 that number to route the call to the area of the emergency. The=20 exception is when the PBX has DID service and a special arrangement= =20 =20 =20 Taylor Expires - February 2004 [Page 7]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 has been made with the PSTN service provider(s) to whose network(s)= =20 the PBX connects. In that case, the PBX can present the caller's=20 extension number as a callback number. The PSTN passes this on to=20 the the emergency call taker. Full signalling details are given in= =20 [8] section 2.1.2.3, to which [9] provides background. =20 In the legacy network, PSTN service providers are responsible for=20 maintaining the ECC mapping database and, of course, the=20 configuration data in their switches. Updates are required every=20 time the relationship between incoming circuit, the calling number=20 assigned to that circuit, and the location of the terminal at the=20 other end of that circuit changes. It can typically take a day to=20 put through a change in the ECC mapping database, meaning that=20 advance coordination is required to ensure consistency between=20 configuration and reality. =20 =20 4 SIP Phones and Emergency Services=20 4.1 A General Look At The Problem=20 SIP phones introduce a number of new elements into the system and=20 change many of the underlying assumptions. =20 A primary consideration is that the SIP phone is configurable by th= e=20 user, has intelligence, and typically registers itself with element= s=20 of the local network (DHCP server, SIP registrar) which can pass it= =20 configuration data when it first comes into operation. Call=20 signalling passes through other intelligent elements -- SIP proxies= =20 perhaps, and a PSTN gateway always -- before reaching the telephone= =20 network. The SIP phone may or may not be associated with a=20 telephone number persisting beyond the duration of a single call.=20 At the transport level, the SIP phone's physical point of attachmen= t=20 is to an IP subnetwork rather than a telephone line. This=20 introduces additional complexity for emergency call systems. A=20 telephone line has only a single physical appearance, but it is=20 possible to connect to an IP subnetwork from many different=20 locations. A management system may be able to detect activation of= =20 the SIP device in a particular location, either directly or through= =20 LAN equipment, but it is difficult for the management system to=20 unambiguously detect that the device is a SIP device unless it is=20 informed of this either by the SIP device or by the SIP registrar.=20 Both signalling and media may be subject to routing delays,=20 congestion, and the actions of middleboxes or encryption as they=20 pass through the IP network.=20 =20 =20 Taylor Expires - February 2004 [Page 8]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 4.2 SIP Phone Deployment Scenarios=20 This section identifies the SIP phone deployment scenarios to be=20 considered with regard to the fundamental requirements identified i= n=20 section 3.2. Scenarios 4.2.1 through 4.2.3 assume that emergency=20 calls can be routed, directly or indirectly, from the SIP Phone to = a=20 PSTN gateway that in turn has the routing information required to=20 reach the target ECC. Scenario 4.2.4 is the case where the target=20 ECC is not reachable from the caller's location.=20 4.2.1 The Stationary SIP Phone=20 This scenario features stationary SIP phones with fixed locations,=20 routing emergency calls either through other SIP entities or=20 directly to a PSTN gateway. This is the simplest case, one that=20 might be encountered in a corporate network. The following diagram= =20 highlights the architecture involved for this scenario. =20 +-------+ =20 | SIP | *Fixed Location =20 | Phone | =20 +-------+ =20 | | * Known GW =20 | |----- to reach=20 | \ target ECC =20 +-----+ \ +------+ +-----+ +------+=20 / \ \--| PSTN | / \ |Target|=20 / SIP \------| GW |-----/ PSTN \-------| ECC |=20 \ Network / +------+ \ / +------+=20 \ / | \ / |=20 +-----+ | +----+ |=20 | | |=20 +------------+ +------------------+ +-------------+=20 | Routing DB | | Routing DB | | Mapping DB |=20 | Info for GW| | Info for trunk | | CgPN -> |=20 | selection. | | selection, poss. | | location |=20 +------------+ | callback number | +-------------+=20 +------------------+=20 =20 When an intermediate SIP entity is involved in routing the call, if= =20 more than one PSTN gateway is available, the intermediate entity=20 needs to know which one is the appropriate one for this SIP phone. = =20 Some sort of routing database is required, keyed by the contents of= =20 selected header fields in the INVITE. The issues of which header=20 field to use and how to populate the routing database are considere= d=20 in section 4.3.=20 The PSTN gateway also needs to do routing. There are three steps:=20 =20 =20 Taylor Expires - February 2004 [Page 9]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 - determination of the target ECC (if more than one can be reached= )=20 - selection of a trunk group to a PSTN switch which will route to=20 that ECC=20 - possibly, selection of a specific trunk corresponding to the SIP= =20 phone's location.=20 In the simplest case there are no choices and routing is=20 straightforward once it is recognized that this is an emergency=20 call. When choices do exist, a routing database is needed. As at=20 intermediate SIP entities, this is keyed on the contents of an=20 appropriate header field in the INVITE. The issues involved are=20 similar to those for routing at intermediate SIP entities.=20 Where the special arrangement exists that allows the PSTN gateway t= o=20 pass along a callback number, the PSTN gateway also needs to know=20 what number to use. This is another issue considered in section 5.= =20 Because the SIP phone is stationary, it is feasible for the routing= =20 databases to be maintained by configuration. This is the=20 distinctive feature of scenario 4.2.1.=20 4.2.2 Nomadic Phone Direct To PSTN Gateway=20 In this case, the SIP phone may be moved from one location to=20 another between calls. The SIP phone is configured to route=20 emergency calls directly to a PSTN gateway, which by hypothesis has= =20 the routing information to reach the target ECC if it can identify=20 it from incoming call signalling. The architecture looks very=20 similar to that in scenario 4.2.1: =20 +-------+ =20 | SIP | * Visiting =20 | Phone | =20 +-------+ * Known GW = =20 | to reach=20 | target ECC=20 | +------+ +-----+ +------+=20 | | PSTN | / \ |Target|=20 +----------| GW |-----/ PSTN \-------| ECC |=20 +------+ \ / +------+=20 | \ / |=20 +------------+ +----+ +-------------+=20 | Routing DB | | Mapping DB |=20 +------------+ | CgPN -> |=20 | location |=20 +-------------+ = =20 =20 =20 =20 =20 Taylor Expires - February 2004 [Page 10]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 Because the SIP phone is nomadic, several aspects of this scenario=20 become open to question:=20 1. How does the SIP phone recognize emergency calls?=20 2. How does it know the address of the PSTN gateway? (One possible= =20 answer is through use of the DHCP option defined in [10],=20 supported by suitable conventions.)=20 3. How is the routing database at the gateway updated to be=20 consistent with the current location of the SIP phone?=20 4. Alternatively, is it more workable for the SIP phone to signal=20 its location and for the gateway to use this as a key to the=20 routing database? If so, how does the SIP phone learn its=20 location and how can it signal that location in SIP?=20 5. If the SIP phone does not supply a callback number, where does i= t=20 come from?=20 Discussion of possible answers to these questions is found in=20 section 4.3.=20 4.2.3 Nomadic SIP Phone To Intermediate SIP Entity=20 In this scenario, the SIP phone is configured to route emergency=20 calls to a SIP network element other than the PSTN gateway. The SI= P=20 network element selects the PSTN gateway which can reach the target= =20 ECC. Again the architecture looks very much like that in scenario=20 4.2.1:=20 +-------+ =20 | SIP | * Visiting =20 | Phone | =20 +-------+ * Known GW = =20 | to reach =20 | target ECC =20 +-----+ +------+ +-----+ +------+=20 / \ | PSTN | / \ |Target|=20 / SIP \------| GW |-----/ PSTN \-------| ECC |=20 \ Network / +------+ \ / +------+=20 \ / | \ / |=20 +-----+ | +----+ |=20 | | |=20 +------------+ +-------------+ +-------------+=20 | Routing DB | | Routing DB | | Mapping DB |=20 | Info for GW| +-------------+ | CgPN -> |=20 | selection. | | location |=20 =20 =20 Taylor Expires - February 2004 [Page 11]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 +------------+ +-------------+ = =20 =20 =20 In this scenario, most of the questions raised for scenario 4.3.2=20 are still open. There is no longer the need for the SIP phone to=20 know which gateway to route to. However, the problem has simply=20 been put off a step: the questions now are how the SIP phone is=20 configured with the address of the next-hop SIP network element, an= d=20 how the latter knows the SIP phone's location so it can make a PSTN= =20 gateway selection. This, too, is discussed section 4.3 below.=20 4.2.4 Target ECC Cannot Be Reached=20 In the previous scenarios, the SIP phone could reach a PSTN gateway= =20 which in turn had the routing information to reach the target ECC=20 while preserving the emergency nature of the call. In scenario=20 4.2.4 the assumption is that the SIP network to which the SIP phone= =20 is attached does not have this information. One example where this= =20 might occur is that of a someone dialling in to a home network=20 remote from the caller's location. The architecture looks as=20 follows, with the two basic cases (from the point of view of the=20 PSTN gateway) marked as (1) and (2):=20 +-------+ =20 | SIP | =20 | Phone |\ =20 +-------+ \=20 | \ =20 | \ =20 +-----+ \ +------+ +-----+ +------+=20 / \ \--| PSTN | / \ (1) |Other |=20 / SIP \------| GW |-----/ PSTN \-------| ECC |-+=20 \ Network / +------+ \ / +------+ |=20 \ / | \ / \ | |=20 +-----+ | +----+ \ (1a)| (1b)|=20 | (2)\ | |=20 +-------------+ \ | |=20 | Routing DB | \ +------+ | =20 +-------------+ \-|Target| | =20 /-------| ECC | | =20 / +------+ | =20 +-------------+ | /=20 | Mapping DB | +----------+=20 | CgPN -> | | Local |=20 | location | | Emergency|=20 +-------------+ | Services |=20 +----------+=20 =20 =20 =20 Taylor Expires - February 2004 [Page 12]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 =20 The two basic possibilities in this scenario are these:=20 (1) Continuation as emergency call=20 In this case, the PSTN gateway continues the call as an emergency=20 call and routes it to an ECC local to the gateway. At that point,=20 it is up to the emergency call taker to determine directly from the= =20 caller the location of the emergency. The emergency call taker the= n=20 transfers the call, possibly as an ordinary call, either to the=20 target ECC (case 1(a)) or to the required emergency service=20 organization in the locality of the caller (case 1(b)).=20 The distinction between 1(a) and 1(b) is beyond the scope of this=20 paper, since it comes about independently of the source of the=20 emergency call. A key point to recognize, however, is that while=20 case (1) (i.e., emergency reported to a non-local ECC) can happen i= n=20 the legacy network, the frequency with which it happens may be much= =20 increased as nomadic SIP phones come into more common use. This=20 likelihood may cause emergency service planners to reconsider=20 existing solutions if they will not scale to higher call volumes.=20 (2) Continuation as ordinary call to ECC administrative number=20 This case assumes that the PSTN gateway has access to a database=20 keyed by caller location and listing ordinary telephone numbers by=20 means of which the target ECC can be reached. Such a database=20 exists as a service in the USA.=20 In this case, the PSTN gateway cannot signal the call to the PSTN a= s=20 an emergency call. However, it is able to direct it to the target=20 ECC without the double handling and consequent delay implied in cas= e=20 (1).=20 The key SIP-side issue in this case is how the PSTN gateway can=20 determine the SIP phone's location so it can choose the target ECC.= =20 Additionally, even for an ordinary call, call signalling to the ECC= =20 will contain the calling party number and may contain a separate=20 callback number. The PSTN gateway provides the latter directly and= ,=20 depending on whether it is part of a public or private network, at=20 least indicates the calling party number through its choice of=20 outgoing trunk circuit. The next section discusses how the PSTN=20 gateway might obtain the necessary information to provide these=20 values.=20 =20 =20 Taylor Expires - February 2004 [Page 13]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 4.3 System Requirements applied to SIP Phones =20 The mechanisms required for the SIP phone and the supporting IP=20 network to meet the system requirements may vary with the=20 circumstances under which the SIP phone is deployed. This section=20 takes a general look at the system requirements first identified in= =20 section 3.2, discusses these requirements as they apply to the four= =20 deployment scenarios described in section 4.2, and identifies=20 potential ways of meeting these requirements.=20 4.3.1 Identifying Emergency Calls=20 The problem of how SIP phones can identify emergency calls has been= =20 described in [4]. The basic problem in SIP terms is how to=20 formulate the Request-URI. [4] argues for a universal emergency SI= P=20 URI, sip: or sips:sos@domain, to relieve the user of the need to=20 learn the local emergency number and configure or dial it when he o= r=20 she is on the road. A corollary of this arrangement is that the=20 user interface to the SIP phone provides direct access to emergency= =20 calling, as by a special button, predefined directory entry, or=20 dialled code. =20 Unless the user interface makes the way to do emergency calling=20 totally obvious, however, there is always the possibility that a=20 caller unfamiliar with the details of use of the SIP phone dials th= e=20 local emergency number directly. This means that PSTN gateways and= =20 intermediate SIP entities must be prepared to recognize both the=20 universal emergency SIP URI and the local emergency number expresse= d=20 as a tel: or sip:/sips: URI. =20 There is another possibility: that the SIP phone is configured to=20 recognize the local emergency number when it is dialled and convert= =20 it into the universal emergency SIP URI. This may be necessary if=20 it is concluded (from discussion below) that the SIP phone must=20 recognize when it is being used for an emergency call, so it can=20 include certain information in the INVITE. How does such=20 configuration come about? The possible sources of the information=20 appear to be:=20 - the user or installer at configuration time;=20 - the DHCP server, using a SIP-specific option;=20 - the SIP registrar, using a new header field or message body in=20 its reply to carry the information.=20 How practical are these alternatives? The probability of a SIP=20 phone being borrowed to make an emergency call is likely far smalle= r=20 =20 =20 Taylor Expires - February 2004 [Page 14]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 if the phone travels a lot, since a much-travelled phone is likely = a=20 personal device rather than one accessible to a casual user. That=20 means that explicit dialling of the local emergency number if there= =20 is a short-cut alternative is most likely in scenario 4.2.1, and=20 unlikely in scenario 4.2.4. On that basis, any of these=20 alternatives is possible in the cases where one is needed.=20 There is still the problem of distinguishing between voice and text= =20 emergency calls in countries where these are routed separately. If= =20 the user enters an actual emergency number, that can be the one tha= t=20 serves the user's needs. If the configuration is by DHCP or SIP=20 registrar, it may be that selection of the appropriate number is=20 based on pre-configuration of the SIP phone as voice or text based.= =20 If the "sos" solution in [4] is used, consideration must be given t= o=20 how the protocol will indicate a routing to the text rather than=20 voice emergency service. This could be done based on the session=20 description in the request body, but that implies that the correct=20 routing is done at the PSTN gateway rather than at a proxy. The=20 most likely alternative is to provide the indication using caller=20 preferences to indicate a preference for text media. Another=20 alternative is to reserve a specific "sos" subaddress for text=20 services (e.g. sos.text) in the same way that [4] proposes to=20 reserve subaddresses for fire, police and other specific services.=20 4.3.2 Call Processing Recognition and Routing Of Emergency Calls=20 The previous sub-section has suggested that emergency calls will be= =20 identifiable by the content of the Request-URI. The user part of=20 this URI will consist either of the appropriate telephone number or= =20 of a global emergency identifier, "sos".=20 Depending on the scenario, the SIP phone itself, intermediate SIP=20 entities, and in all cases the PSTN gateway, must be able to=20 recognize emergency calls in order to handle them properly. The=20 responsibilities of each of these elements have been identified in=20 preceding discussion: =20 - As discussed in section 4.3.1, the SIP phone may be required in=20 any scenario to convert from a directly dialled local emergency=20 number to the universal emergency SIP URI.=20 - Except where it can rely on intermediate entities to do the=20 routing, the SIP phone must route emergency calls to a PSTN=20 gateway. In scenarios 4.2.1 and 4.2.2, the choice of gateway=20 depends on the caller's location.=20 =20 =20 Taylor Expires - February 2004 [Page 15]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 - Similarly, intermediate SIP network elements must route emergenc= y=20 calls to a PSTN gateway. In scenarios 4.2.1 and 4.2.3, the=20 choice of gateway depends on the caller's location.=20 - The PSTN gateway is responsible for generating a called party=20 number on the PSTN side and routing on the basis of that number=20 and, possibly, the caller's location. In scenarios other than=20 4.2.4 case (2), the called party number for all emergency calls=20 is set to the local emergency number. In scenario 4.2.4 case=20 (2), the called party number is the administrative number for th= e=20 target ECC as determined from the caller's location.=20 A recurring theme in this list of responsibilities is that dependin= g=20 on the particular network involved, the SIP phone, intermediate SIP= =20 entities, and/or the PSTN gateway need to know the caller's=20 location. How this can be determined?=20 For intermediate elements and the PSTN gateway, the starting point=20 must be information carried in the SIP signalling. There are two=20 basic approaches, direct or indirect:=20 - the location may be presented directly, in a new SIP header=20 field.=20 - the location may be derived indirectly, by consulting a database= =20 using the content of a suitable header field as a key.=20 The direct approach requires action in the SIPPING and SIP Working=20 Groups to define the new header field. It also requires that the=20 SIP phone have this information available in the first place. As=20 usual, there is more than one way for the SIP phone to learn its=20 location:=20 - from in-built hardware (i.e., GPS) -- not likely to be a general= =20 solution because of its impact on size and cost, not to mention=20 the need to add GPS capability to general-purpose computers when= =20 soft clients are loaded on to them;=20 - from DHCP, using a SIP-related or preferably a more general=20 extension. The DHCP server (or SNMP, or 802.11x) obtains the=20 physical point of access of the SIP phone and maps that to=20 geographical coordinates using a database set up for the purpose= .=20 - by configuration. An installer (most likely just in scenario=20 4.2.1) may know geographical coordinates. An user is more likel= y=20 to know just an address, if the user can even be induced to ente= r=20 it. This is not going to be helpful for the SIP entities that=20 have to process it.=20 =20 =20 Taylor Expires - February 2004 [Page 16]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 The indirect approach requires two things: identification of the SI= P=20 phone (as opposed to the calling user) in the SIP INVITE header, an= d=20 a database which intermediate SIP entities and the PSTN gateway can= =20 consult to relate this identification to a location. The Contact=20 header field is the likely candidate for SIP phone identification,=20 since it derives directly from the network context of the call.=20 Creating a database to relate the Contact header field value to=20 geographical location may be complicated, since it requires network= =20 access information to be brought together with SIP-level=20 information. One way is to correlate data captured by layer 2 (DHC= P=20 option 82, SNMP, or 802.11x) and by the SIP registrar, if the SIP=20 phone registers itself.=20 One variant of the indirect method, depending on the scenario, is=20 for the outgoing proxy to do its database lookup, then append a=20 location header field to the INVITE header. This saves succeeding=20 SIP entities from having to do the same, and the outgoing proxy may= =20 be in a privileged position to determine the SIP phone's location.=20 Since a location header field may be useful even in the indirect=20 case, it seems desirable that SIP/SIPPING get to work on=20 standardizing it. This will provide flexibility for network design= =20 to meet E911 requirements. =20 4.3.3 Calling Party Number As Key To The Location Database=20 The PSTN gateway determines calling party number in onward PSTN=20 signalling either directly (if it is trusted by a PSTN service=20 provider) or indirectly through trunk selection. In either case,=20 the number used should relate to the caller's location. The issues= =20 have already been discussed in the preceding section.=20 4.3.4 Determining Caller Location=20 This topic has already been discussed in section 4.3.2.=20 4.3.5 Retaining Access To The Caller=20 In the PSTN, it is an optional feature for the emergency services=20 call taker to keep the caller's line open even if the caller goes=20 on-hook temporarily. However, this requirement doesn=92t necessari= ly=20 translate to the SIP environment since the reachability and identit= y=20 of the user are not restricted to a single physical line. [4]=20 discusses features at a SIP phone which would contribute toward the= =20 basic objective of maintaining contact, provided that the SIP phone= =20 is able to recognize an emergency call.=20 =20 =20 Taylor Expires - February 2004 [Page 17]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 As an alternative, or in addition to other features, the system=20 should provide a number the emergency services call taker can use t= o=20 call back to the SIP phone. The PSTN gateway is generally=20 responsible for inserting this number into PSTN signalling. There=20 are two basic alternatives for what number it presents:=20 - it can get the number from a telephone number (public or private= )=20 presented explicitly in the user part of the Contact header fiel= d=20 URI. If the number was part of a private numbering plan, the=20 PSTN gateway converts it to a public number.=20 - the PSTN gateway temporarily (for a period long enough to cover=20 the duration of an emergency) assigns an otherwise unused public= =20 telephone number to the SIP phone, retaining a mapping between=20 the assigned number and the contact information presented by the= =20 SIP phone.=20 One point to consider in the second case is that a return call does= =20 not necessarily have to reach the original caller, although this is= =20 clearly preferable. Depending on circumstances, it may be=20 sufficient that a callback number reach a designated emergency phon= e=20 in the emergency location. This is clearly workable only where the= =20 PSTN gateway knows the location of the caller and has additional=20 information on the location of emergency phones.=20 The above discussion assumes that information in the Contact header= =20 field remains valid for the duration of the emergency, even if the=20 original call terminates. Appropriate measures would be required t= o=20 achieve this in cases where it would not otherwise be true. This=20 may require the PSTN gateway, for instance, to send repeated=20 heartbeats in the form of OPTION requests to keep firewall or NAT=20 pinholes open. =20 4.3.6 Minimum Delay In Call Setup=20 This requirement is tied to the requirement that the SIP entities=20 along the call path be able to recognize an emergency call. If the= y=20 can do so, they can give priority to handling of the call.=20 4.3.7 Caller Accountability=20 Caller accountability requires in the first instance that the=20 mapping between calling number as presented at the ECC and the=20 address of record of the SIP phone be preserved for audit, an=20 administrative issue. Beyond this, depending on the scenario,=20 caller identity can be vouched for by trusted entities (RFC 3325) o= r=20 determined by other means (RFC 3323). Either way requires that the= =20 =20 =20 Taylor Expires - February 2004 [Page 18]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 telephone network trust the gateway. Without this element of trust= ,=20 the chain of accountability stops at the gateway itself.=20 5 Conclusions=20 It is clear from the above discussion that determining the location= =20 of the SIP phone is a key element of the emergency calling service.= =20 The ability to signal that location in SIP would be helpful in a=20 number of scenarios. The development of a suitable location header= =20 field should be given priority in the SIPPING and SIP Working=20 Groups.=20 Discussion also made clear that configuration of the SIP phone for=20 emergency calling, including setting of its location, may make use=20 of DHCP. This possibility should be further explored to determine=20 if further standardization is required. The resulting DHCP=20 capabilities should probably have applicability to other devices=20 besides SIP phones.=20 Finally, it is apparent that a variety of engineering solutions are= =20 available for providing emergency calling service. Further=20 discussion may suggest which approaches are most effective. =20 6 Security Considerations=20 Potential threats specific to emergency calling scenarios include: = =20 - abuse of the service (i.e., use to make non-emergency calls);=20 - denial of service attacks upon SIP entities or critical database= s=20 done by taking specific advantage of emergency calling features;= =20 - denial of service attacks aimed at the ECC;=20 - unauthorized disclosure of caller location; and=20 - attacks designed to mislead intermediate SIP elements into=20 routing emergency calls to hosts other than the target PSTN=20 gateway.=20 =20 [Will be expanded further after people have had a look.]=20 =20 =20 =20 Taylor Expires - February 2004 [Page 19]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 7 References=20 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP= =20 9, RFC 2026, October 1996.=20 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement=20 Levels", BCP 14, RFC 2119, March 1997.=20 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.=20 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session=20 Initiation Protocol", RFC 3261, June 2002.=20 4. H. Schulzrinne, "Emergency Services for Internet Telephony based= =20 on the Session Initiation Protocol (SIP)", draft-schulzrinne- sipping-sos-04.txt, Work in Progress, January 2003 (expired).=20 5. N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk, "Use= r=20 Requirements for the Session Initiation Protocol (SIP) in Suppor= t=20 of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC=20 3351, August 2002.=20 6. H. Schulzrinne, "Requirements for Session Initiation Protocol=20 (SIP)-based Emergency Calls", draft-schulzrinne-sipping- emergency-req-00.txt, Work in Progress, February 2003.=20 7. J. Polk, John Schnizlein, Marc Linsner, "DHC Location Object=20 within GEOPRIV", draft-ietf-geopriv-dhcp-lo-option-00.txt, Work=20 in Progress, January 2003.=20 =20 8. ITU-T Recommendation Q.699, "Interworking between ISDN access an= d=20 non ISDN access over ISDN User Part of Signalling System No. 7",= =20 September 1997.=20 =20 9. ITU-T Recommendation Q.951.3, "Stage 3 description for number=20 identification supplementary services using DSS 1 : Calling line= =20 identification presentation", March 1993.=20 10. H. Schulzrinne, "Dynamic Host Configuration Protocol (DHCP-for- IPv4)Option for Session Initiation Protocol (SIP) Servers", RFC=20 3361, August 2002.=20 =20 =20 =20 Taylor Expires - February 2004 [Page 20]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 8 Acknowledgments=20 Henning Schulzrinne has been trying to get people to look at this=20 problem for many years, and has led the way with his drafts [4],=20 [6], and others before them. Henning's extensive comments on an=20 earlier version of this draft have led to a major re-write which is= ,=20 one hopes, much improved as a result.=20 Mary Barnes and Jim McEachern=20 helped to shape the text of the initial=20 issue of this document. Steve Norreys and=20 Patrick Emery helpfully contributed=20 descriptions of emergency services operation in the UK and=20 Australia, respectively. =20 =20 9 Author's Address=20 Tom Taylor=20 Nortel Networks=20 1852 Lorraine Ave.=20 Ottawa, Ontario=20 Canada K1H 6Z8=20 Tel: +1 613 736 0961=20 Email: taylor@nortelnetworks.com=20 =20 =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2003). All Rights Reserved.=20 This document and translations of it may be copied and furnished to= =20 others, and derivative works that comment on or otherwise explain i= t=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, thi= s=20 document itself may not be modified in any way, such as by removing= =20 the copyright notice or references to the Internet Society or other= =20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English. The limited permissions granted above are perpetual and=20 will not be revoked by the Internet Society or its successors or=20 assigns. This document and the information contained herein is=20 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE=20 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,EXPRESS OR= =20 =20 =20 Taylor Expires - February 2004 [Page 21]=20 =0C SIP Emergency Assistance Scenarios October 2003=20 =20 =20 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=20 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."= =20 =20 =20 Taylor Expires - February 2004 [Page 22] =0C --------------040300010008090801030102-- _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency