Subject: [Sipping-emergency] draft-taylor-sipping-emerg-scen-00.txt

From: Tom Taylor <[email-masked]>
Date: Wed, 01 Oct 2003 12:58:48 -0400

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
[email-masked]
Ph. +1 613 736 0961

   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 <[email-masked]> and Jim McEachern 
      <[email-masked]> helped to shape the text of the initial 
      issue of this document.  Steve Norreys <[email-masked]> and 
      Patrick Emery <[email-masked]> 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: [email-masked] 

   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]