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