Subject: [Sipping-emergency] Emergency Scenarios Document

From: Tom Taylor <[email-masked]>
Date: Tue, 20 May 2003 17:09:38 -0400

Well, I'm recovered from my surgery and back in action, and here at last is the 
deployment scenarios document for SIP phones working into legacy emergency call 
centres.  Let me know if you see desirable changes before I submit it for 
publication as an Internet Draft.

Tom Taylor
+1 613 736 0961

      Session Initiation Protocol Investigations                           
      Internet Draft                                            Tom Taylor 
      Document: draft-taylor-sipping-emerg-scen-00.txt     Nortel Networks 
      Expires: November 2003                                      May 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 
      centresin 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 analysis presented here is a 
      necessary step in defining the SIP specific requirements for invoking 
      emergency assistance and understanding the level of functionality 
      that can be provided by existing SIP devices and network elements and 
      that which requires further development. 

    
   Taylor                 Expires - November 2003               [Page 1] 
                     SIP Emergency Assistance Scenarios          May 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.3         Legacy System Operation...............................7 
      4           SIP Phones and Emergency Services.....................9 
      4.1         A General Look At The Problem.........................9 
      4.2         SIP Phone Deployment Scenarios........................9 
      4.2.1       The Local Scenario (1)................................9 
      4.2.2       The Regional Operator Scenario (2)...................10 
      4.2.3       The National Operator Scenario (3)...................11 
      4.2.4       The Visiting Phone Scenario (4)......................13 
      4.2.5       The VPN Scenario (5).................................14 
      4.3         System Requirements applied to SIP Phones............15 
      4.3.1       Identifying Emergency Calls..........................16 
      4.3.2       Call Processing Recognition and Routing Of Emergency 
                     Calls.............................................17 
      4.3.3       Calling Party Number As Key To The Location Database.18 
      4.3.4       Determining Caller Location..........................19 
      4.3.5       Retaining Access To The Caller.......................21 
      4.3.6       Minimum Delay In Call Setup..........................21 
      4.3.7       Caller Accountability................................22 
      4.4         Supportability of SIP Phone Deployment Scenarios.....22 
      4.4.1       The Local Scenario...................................22 
      4.4.2       The Regional Operator Scenario.......................22 
      4.4.3       The National Operator Scenario.......................23 
      4.4.4       The Visiting Phone Scenario..........................23 
      4.4.5       The VPN Scenario.....................................23 
      6           Security Considerations..............................24 
      7           References...........................................24 
      8           Acknowledgments......................................25 
      9           Contributors.........................................25 
      10          Author's Address.....................................26 
       
   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 

   Taylor                 Expires - November 2003               [Page 2] 
                     SIP Emergency Assistance Scenarios          May 2003 

      in the European Market 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 a device which plugs 
      into a wired network.  This can be a either a physical phone device 
      or a PC running a software based SIP client (often referred to as a 
      SIP softphone).  These devices can be stationary or nomadic. 

      Scenarios involving cellular phones using SIP signalling are not 
      necessarily considered, because the current expectation is that they 
      use the emergency service solutions devised for cellular phones in 
      general. However, it is anticipated that many aspects of a general 
      SIP signaling solution could apply to those scenarios.  The 
      requirements for Wi-Fi enabled devices (e.g. a SIP softphone with Wi-
      Fi access, a Wi-Fi phone etc.) using SIP signalling are considered 
      from the perspective that these devices can be represented as nomadic 
      SIP users and thus addressed by several of the scenarios described in 
      this document. 

      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 
      emergency calls, see Schulzrinne [4].  The following diagram 
      summarizes the relationship between the scenarios addressed by this 
      document and the other documents: 

                              ECC                  IECC 
          ---------------------------------------------- 
            Legacy PSTN       N/A                  [6] 
            phones 
       
            SIP (existing)   This document.        [6] 
       
            SIP (enhanced)   [4]                 [4],[6] 

   2  Definitions and Abbreviations  

      PSTN 
      Public Switched Telephone Network: the legacy circuit network. 

   Taylor                 Expires - November 2003               [Page 3] 
                     SIP Emergency Assistance Scenarios          May 2003 

      ECC 
      Emergency Call Centre -- a collection of operators 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. 

      ECC in jurisdiction 
      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. 

      IECC 
      Internet Protocol ECC -- an ECC that uses Internet protocols, such as 
      SIP for call signaling, RTP for media delivery, to receive emergency 
      calls.  Note: requirements related to IECC access are out of scope 
      for this document, but are considered in [6]. 

      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 - November 2003               [Page 4] 
                     SIP Emergency Assistance Scenarios          May 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 operators 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.  From the 
      point of view of this analysis, the system requirements and operation 
      are similar to those for voice-based emergency calling, except for 
      the difference in medium and the fact that a different number may be 
      dialed to initiate the call.  
       
   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, 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 appropriate ECC.  The ECC so reached must be 
          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 elsewhere, but this can be assumed to be the ECC's 
          task.) 

      (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 can be supplied to the mapping database. 
          Typically this is done in advance of the emergency call, but in 
          some cases it can be provided when the call is made.  In this 

   Taylor                 Expires - November 2003               [Page 5] 
                     SIP Emergency Assistance Scenarios          May 2003 

          case it must be provided at most a few tens of seconds after the 
          emergency call has started. 

      (5) The ECC operator can stay in touch with the caller, even though 
          the telephone set goes on hook for an intervening period.  An 
          example of when this is useful is if the caller, feeling unwell, 
          accidentally drops the telephone back onto its cradle, but then 
          is able to retrieve it. 

      (6) Emergency calls are given priority handling in call processing 
          and 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 

      In the legacy network, the public telephone system operator is 
      responsible for maintaining the mapping database.   

      For residential, business line, and centrex service, the main issue 
      is reassignment of telephone numbers to new circuits and new 
      locations due to subscriber movement.   

      For PBX operation, an additional issue is that telephone number 
      assignments are under control of the private network operator.  PBXs 
      without direct-inward-dialing (DID) introduce an additional 
      challenge.  Typically, the calling number is used as a unique 
      reference to identify the caller's location.  However, in the case of 
      a PBX without DID, each phone does not have a globally unique 
      telephone number that can provide this function, thus the default 
      behaviour would be to use the external number for the PBX to identify 
      the location.  Alternatively, various locations can be identified 
      within the business and assigned a pseudo directory number (DN), 
      which is a valid, unique E.164 number.  When an emergency call is 
      initiated, the PBX uses a pseudo-DN reflective of the calling party's 
      location to the ECC.  For either PBX scenario, administrative 
      arrangements are required to pass location data from the private 
      network to the public network operator. 

      A similar consideration governs calls from one public operator which 
      must be passed to another because the latter is responsible for 
      operation of the mapping database and ECC.  For the fixed line PSTN 
      network, location data acquisition occurs at configuration time, 
      rather than on a per-call basis.   

      An emergency call in the legacy system begins when the caller dials 
      the local emergency services number.  The switch serving the caller's 

   Taylor                 Expires - November 2003               [Page 6] 
                     SIP Emergency Assistance Scenarios          May 2003 

      line receives the dialed digits, identifies the call as an emergency 
      call, and determines the route to the ECC in jurisdiction through 
      configuration of telephony routing data.  Configuration also 
      associates a calling number with the caller's line.  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 operator, who may need it if the caller is 
      unable to provide the information.  

      A special arrangement at the switch serving the ECC allows the 
      emergency operator to hold open the voice path back to the caller as 
      long as necessary, even if the caller goes on-hook.  It should be 
      noted that this functionality is not supported for ISDN. Thus, the 
      operator can also ring the caller's line in this situation or others 
      where it might be necessary.  

   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 
      and a gateway -- 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, 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 - November 2003               [Page 7] 
                     SIP Emergency Assistance Scenarios          May 2003 

   4.2 SIP Phone Deployment Scenarios 

      This section identifies the SIP phone deployment scenarios to be 
      considered with regards to the fundamental requirements identified in 
      3.2.  The numbers in parenthesis associated with each scenario are 
      used to reference the scenarios during the detailed analysis 
      presented in section 4.3.  

   4.2.1 The Local Scenario (1) 

      This scenario features stationary SIP phones with known locations and 
      operating with a gateway local to the caller. This is the simplest 
      case, likely to be one that would be encountered in a corporate 
      network.  The following diagram highlights the fundamental 
      configuration and elements involved for this scenario:   

      +-------+                                              
      |  SIP  |  *Known Location                                       
      | Phone |                                         
      +-------+                                                                       
          |                                                                           
          |                                               
          |                                                                           
      +-------+        +------+      +-----+         +------+ 
      | SIP   |        | PSTN |      /      \        | ECC  | 
      | Proxy |--------| G/W  |-----/ PSTN   \-------|      | 
      +-------+        +------+     \        /       +------+ 
       * Known G/W                   \      /           | 
       to reach ECC                   +----+            | 
                                                        | 
                                                     +-----+ 
                                                     | Loc |           
                                                     |  DB | 
                                                     +-----+   

   4.2.2 The Regional Operator Scenario (2) 

      This case differs from the previous one only in that the SIP network 
      is more elaborate, with multiple gateways serving multiple emergency 
      service jurisdictions.  It is assumed that at least one gateway can 
      reach each ECC in the region.  The following diagram highlights the 
      fundamental configuration and elements involved for this scenario:   

      +-------+                                              
      |  SIP  | *Known Location (in DB1 or DB2)                                       
      | Phone |                                         
      +-------+                                                                       
          |                                                                           

   Taylor                 Expires - November 2003               [Page 8] 
                     SIP Emergency Assistance Scenarios          May 2003 

          |                                               
          |                                                                           
      +-------+        +------+      +-----+         +------+ 
      | SIP   |        | PSTN |      /      \        | ECC 1| 
      | Proxy |--------| G/W1 |-----/ PSTN   \-------|      | 
      +       +---+    +------+     \        /       +------+ 
      +-------+   |                  \      /           | 
          |       |                   +----+            | 
          |       |                                     | 
       +-----+    |                                  +-----+ 
       | Loc |    |                                  | Loc |           
       |  DB |    |                                  | DB1 | 
       +-----+    |                                  +-----+   
      *User's     +--------+   
      location maps        |          
      to GW                |        
                        +------+      +-----+         +------+ 
                        | PSTN |      /      \        | ECC 2| 
                        | G/W2 |-----/ PSTN   \-------|      | 
                        +------+     \        /       +------+ 
                                      \      /           | 
                                       +----+            | 
                                                      +-----+ 
                                                      | Loc |           
                                                      | DB2 | 
                                                      +-----+ 

   4.2.3 The National Operator Scenario (3) 

      This scenario features stationary or low-mobility phones sparsely 
      distributed across a relatively large geographical area and operating 
      with dynamically selected gateways from a single operator or 
      coalition of operators. This scenario introduces two key new factors: 

        . There is not necessarily an association between a user's 
           geographic location and the gateway associated with their PSTN 
           reach-ability. Thus, the E.164 number assigned to the user for 
           PSTN calls does not need to reflect their geographic location 
           and cannot be used for routing to an ECC or by the ECC to 
           determine the user's geographic location.    

        . It is possible that some users have no gateway local to them, 
           thus even if there were a mechanism whereby the user could 
           provide their location, the network may have no means of routing 
           to the appropriate ECC.   

      The following diagram highlights the fundamental configuration and 
      elements involved for this scenario:   

   Taylor                 Expires - November 2003               [Page 9] 
                     SIP Emergency Assistance Scenarios          May 2003 

      +-------+                                              
      |  SIP  | *Unknown Location (X)                                        
      | Phone |                                         
      +-------+                                                                       
          |                                                                           
          |                                               
          |                                                                           
      +-------+        +------+      +-----+         +------+ 
      | SIP   |        | PSTN |      /      \        | ECC 1| 
      | Proxy |--------| G/W1 |-----/ PSTN   \-------|      | 
      +       +---+    +------+     \        /       +------+ 
      +-------+   |                  \      /           | 
          |       |                   +----+            | 
          |       |                                     | 
       +-----+    |                                  +-----+ 
       | Loc |    |                                  | Loc |           
       |  DB |    |                                  | DB1 | 
       +-----+    |                                  +-----+   
      *Can't map  +--------+   
      to G/W related       |          
      to phones geoloc     |        
                        +------+      +-----+         +------+ 
                        | PSTN |      /      \        | ECC 2| 
                        | G/W2 |-----/ PSTN   \-------|      | 
                        +------+     \        /       +------+ 
                                      \      /           | 
                                       +----+            | 
                                                      +-----+ 
                                                      | Loc |           
                                                      | DB2 | 
                                                      +-----+ 

                                                      +------+ 
                                                      | ECC X|           
                                                      |      | 
                                                      +------+ 

   4.2.4 The Visiting Phone Scenario (4) 

      This scenario focuses on SIP phones which move about in a "friendly" 
      network, meaning that the user is known to that network and that the 
      network is able to route to a geographically significant ECC for all 
      its users. The new element introduced by this scenario is that 
      although the user is not typically geographically located with the 
      local entities, the user is known to that network and there are 
      gateways which route to the appropriate ECC.  Thus, the primary 
      difference between this scenario and Scenario 2 is that the 
      subscriber's location is dynamic, impacting both the mapping to the 

   Taylor                 Expires - November 2003              [Page 10] 
                     SIP Emergency Assistance Scenarios          May 2003 

      Gateway by the SIP Proxy and potentially the mapping at the database 
      used by the ECC.      

      The following diagram highlights the fundamental configuration and 
      elements involved for this scenario:   

      +-------+                                              
      |  SIP  | *Known Location (either in DB1 or DB2)                                
      | Phone |                                         
      +-------+                                                                       
          |                                                                           
          |                                               
          |                                                                           
      +-------+        +------+      +-----+         +------+ 
      | SIP   |        | PSTN |      /      \        | ECC 1| 
      | Proxy |--------| G/W1 |-----/ PSTN   \-------|      | 
      +       +---+    +------+     \        /       +------+ 
      +-------+   |                  \      /           | 
          |       |                   +----+            | 
          |       |                                     | 
       +-----+    |                                  +-----+ 
       | Loc |    |                                  | Loc |           
       |  DB |    |                                  | DB1 | 
       +-----+    |                                  +-----+   
      *User's     +--------+   
      location maps        |          
      to GW for            |        
      current location  +------+      +-----+         +------+ 
                        | PSTN |      /      \        | ECC 2| 
                        | G/W2 |-----/ PSTN   \-------|      | 
                        +------+     \        /       +------+ 
                                      \      /           | 
                                       +----+            | 
                                                      +-----+ 
                                                      | Loc |           
                                                      | DB2 | 
                                                      +-----+ 

   4.2.5 The VPN Scenario (5) 

      The final scenario deals with a nomadic SIP phone which attaches to 
      an IP sub-network remote from the SIP network where it is recognized. 
      This scenario would be typical of a remote office, such as 
      telecommuters or a satellite office.   

      Thus, this scenario introduces factors very similar to those in the 
      Regional Scenario (3): 

    
   Taylor                 Expires - November 2003              [Page 11] 
                     SIP Emergency Assistance Scenarios          May 2003 

        . Even if the user has an E.164 number assigned for PSTN 
           reachability, it likely does not reflect their geographic 
           location and cannot be used for routing to an ECC or by the ECC 
           to determine the user's geographic location.    

        . Users likely have no gateway local to them, thus even if there 
           were a mechanism whereby the user could provide their location, 
           the network may have no means of routing to the appropriate ECC.  

      The primary difference between this and the Regional Scenario (3) is 
      that no local support can be expected for calling number assignment 
      or for recognition of location, since the need for such would be 
      transparent and not the responsibility of the local network.    

      The following diagram highlights the fundamental configuration and 
      elements involved for this scenario:   

      +-------+                                              
      |  SIP  | *Unknown Location (X)                                        
      | Phone |                                         
      +-------+                                                                       
          |                                                                           
          |                                               
          |                                                                           
      +-------+        +------+      +-----+         +------+ 
      | SIP   |        | PSTN |      /      \        | ECC 1| 
      | Proxy |--------| G/W1 |-----/ PSTN   \-------|      | 
      +       +---+    +------+     \        /       +------+ 
      +-------+   |                  \      /           | 
          |       |                   +----+            | 
          |       |                                     | 
       +-----+    |                                  +-----+ 
       | Loc |    |                                  | Loc |           
       |  DB |    |                                  | DB1 | 
       +-----+    |                                  +-----+   
      *Can’t map  +--------+   
      to G/W related       |          
      to phones geoloc     |        
                        +------+      +-----+         +------+ 
                        | PSTN |      /      \        | ECC 2| 
                        | G/W2 |-----/ PSTN   \-------|      | 
                        +------+     \        /       +------+ 
                                      \      /           | 
                                       +----+            | 
                                                      +-----+ 
                                                      | Loc |           
                                                      | DB2 | 
                                                      +-----+ 

   Taylor                 Expires - November 2003              [Page 12] 
                     SIP Emergency Assistance Scenarios          May 2003 

                                                      +------+ 
                                                      | ECC X|           
                                                      |      | 
                                                      +------+ 

   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 five 
      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 could make emergency calls has been 
      described in [4].  The basic problem in SIP terms is how to formulate 
      the Request-URI.  The solution to this requirement should be the same 
      for all the scenarios.  

      One has to bear in mind that the process always starts with the user.  
      Depending on the user interface provided by the SIP phone the user 
      selects a directory entry, presses a special key, or dials the local 
      emergency number.  In this last case, the ready made solution is to 
      form the Request-URI directly from the user input.   

      Where the user does not enter the emergency number directly, possible 
      sources of the information needed to form an appropriate Request-URI 
      appear to be as follows: 

      -  the user at configuration time 
      -  the DHCP server, using a SIP-specific option 
      -  the SIP registrar, using an appropriate header field in its reply 
         to carry the information. 

      Because SIP phones can be taken from country to country, [4] sought a 
      solution that would operate globally, relieving the user of the need 
      to learn the local emergency number.  [4] offers another possibility 
      beyond DHCP or registrar configuration: use the reserved user 
      identifier "sos" in the Request-URI.  This allows the outgoing proxy 
      or even the gateway if there is no intervening proxy to recognize 
      that this is an emergency call, modify the signalling accordingly, 
      and route it to its proper destination. 

      There is still the problem of distinguishing between voice and text 
      emergency calls.  If the user enters an actual emergency number, that 

   Taylor                 Expires - November 2003              [Page 13] 
                     SIP Emergency Assistance Scenarios          May 2003 

      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.   

      Pre-configuration also applies if the "sos" solution in [4] is used, 
      and 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 gateway rather 
      than at a proxy.   One alternative is to provide the indication 
      somewhere in the SIP header, but this is probably wrong on principle. 
      Another alternative is to reserve a specific "sos" subaddress for 
      text services (e.g. sos.text) in the same way that subaddresses are 
      reserved 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".  In either case, to minimize 
      call processing delay, any SIP proxy handling the call and also the 
      gateway must probably be configured to recognize the emergency 
      indication. 

      Routing the call may present difficulties, because of the requirement 
      to route to the ECC in jurisdiction.  To achieve this, the routing 
      entity must generally have some notion of the caller's location.  
      Caller location is a separate requirement, discussed below, so for 
      purposes of the present discussion it is simply assumed that the 
      caller's location is available to any proxies and gateways handling 
      the call.  [This assumption may have to be revisited.] 

      There are two basic possibilities to consider.  In some countries, it 
      may be possible for a gateway to route an emergency call to a non-
      local ECC.  (At least one commercial service to enable this is 
      available in the USA.)  In these cases the selection of the gateway 
      is not critical, although it would be desirable to have one as close 
      as possible to the ECC in jurisdiction.  The gateway must have access 
      to a database relating caller locations to ECCs and providing 
      telephone-network-routable telephone numbers for the latter. 

      The second case, applicable to Scenarios 2 and 4, is one where it is 
      not possible for the gateway to route a call to any but the ECC local 
      to the gateway itself.  In this case, the burden lies on SIP proxies 
      along the call path to choose the right gateway.  The proxies must 
      have access to the database mapping caller locations to gateways for 
      emergency access.  If the "sos" URI scheme is used, the proxies also 

   Taylor                 Expires - November 2003              [Page 14] 
                     SIP Emergency Assistance Scenarios          May 2003 

      need to map "sos" to the applicable emergency number at the gateway.  
      (Alternatively, this mapping step could be left to the gateway.) 

      A third case is one where the gateway has circuits connecting to 
      telephone switches in multiple jurisdictions, and can determine from 
      caller location which outgoing circuit to use.  This is probably best 
      analyzed as a variation on the case presented in the previous 
      paragraph, since routing through the telephone network is still 
      essentially local to the gateway. 

      A fourth case is one where the telephone network itself is able to 
      process the calling party number to determine the ECC in 
      jurisdiction.  This reduces the criticality of gateway selection, but 
      is subject to the limitations of the telephone network (e.g. 
      limitations in geographic scope).  The procedure relies on the 
      association of an appropriate calling party number with the SIP 
      phone.  This is a requirement in any event, as discussed in the next 
      section.  This is really a variant of Scenario 1, since the basic 
      routing happens in the PSTN, independent of the SIP phone, Proxy and 
      Gateways.  

      The final case is the simple one where everything is local, and no 
      database is needed to determine the right gateway or the right ECC.  
      This applies to Scenario 1. 

   4.3.3 Calling Party Number As Key To The Location Database 

      A SIP phone may or may not be configured with a telephone number 
      which is usable as a key to the location database at the ECC in 
      jurisdiction.  This configuration may come at registration time or 
      possibly before that. 

      If the phone is configured with the required number, then it has to 
      pass this number in call signalling, presumably in the From header 
      field.  Correlation at the far end with location data is a separate 
      discussion, dealt with in the next section. 

      If the phone is not configured with a telephone number, it has to be 
      assigned one at the time of the call.  The assignment will be made at 
      a proxy or the gateway.  The assigning entity will have to retain the 
      mapping between the call and the assigned number for a suitable 
      period of time.  The assignment is made on the basis of the caller's 
      location, since that is why the number is being assigned.  The 
      mapping is retained to facilitate "call back" by the ECC if required 
      as discussed in section 4.3.5.  Determination of caller location is 
      discussed in the next section. 

      This requirement and potential solutions should apply equally to all 
      the scenarios.  

   Taylor                 Expires - November 2003              [Page 15] 
                     SIP Emergency Assistance Scenarios          May 2003 

   4.3.4 Determining Caller Location 

      Determining the caller’s location is one of the central problems for 
      emergency calls in a SIP environment.  The core problem is that IP 
      allows services to be accessed from anywhere, and it is therefore not 
      possible, in advance, to associate a given user with a specific 
      device, nor to associate either with a specific location.   

      How the caller's location is determined and the challenges faced is 
      very much a function of the scenario being considered.  Where the SIP 
      phone's location is stable and "managed" (Scenarios 1, 2 and 3), 
      everything can be configured in advance: the calling number in the 
      phone, and the calling number and location in the ECC's mapping 
      database.   

      When the SIP phone is not in a stable location (as in Scenarios 4 and 
      5), or is not "managed" (variations on Scenarios 1, 2 and 3, e.g. 
      based on WiFi access), the problem is more complicated, and simple 
      configuration is no longer adequate.  It is at this point that one 
      must consider the possible sources of information. 

      One possibility is that the SIP phone remains unaware of its 
      location.  Instead, the location information is linked with the SIP 
      phone's address of record (the one it will use in From header fields 
      when making emergency calls) in a local database.  For example, the 
      management system overseeing the LAN can determine when a port is 
      activated and what IP address is being used at that port.  A locally 
      configured mapping of LAN port to location can be correlated with the 
      SIP phone's IP address.  On the other side, if the registrar captures 
      the SIP phone's IP address as well as its address of record and 
      supplies this to the local database, the mapping between address of 
      record and location can be completed.  

      Another possibility is that the SIP phone itself is aware somehow of 
      its location and provides that information at registration time or in 
      call signalling.  The appropriate SIP entity would pass the location 
      information to the ECC's mapping database after the SIP phone has 
      been assigned a calling number.  The SIP phone could potentially know 
      its location because the user has configured it, because it contains 
      a Global Positioning System, or because DHCP (or some other external 
      system) has told it what its location is (for example, based on the 
      LAN port). For fixed scenarios 1, 2 and 3, this option would be 
      reasonable. However, for scenarios 4, 5 and many variations of 1, 2 
      and 3 involving phones with non-fixed access, this would require a 
      real-time interface to update the ECC's mapping database, and 
      protocol additions would likely be required to pass this location 
      information. 

    
   Taylor                 Expires - November 2003              [Page 16] 
                     SIP Emergency Assistance Scenarios          May 2003 

   4.3.5 Retaining Access To The Caller 

      In the PSTN, it is an optional feature for the emergency services 
      operator 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.  

      For the existing system, another optional requirement for scenarios 
      where keeping the line open is desired, but not possible, is to 
      require the emergency services operator to initiate a new call back 
      to the caller.   

      [4] recommends that the SIP phone itself take responsibility for call 
      maintenance, by providing special alerting to the user until the 
      latter re-establishes the call. 

      This requirement and potential solutions should apply equally to all 
      the scenarios, albeit it is perhaps easier to enforce and implement 
      in the fixed scenarios (1, 2 and 3).  

   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. 

      This requirement should be achievable for the majority of Scenarios 
      (1, 2, 3 and 4), whereby the network and the user connectivity are 
      managed and more fixed. Scenario 5 introduces the element of the 
      local network, which has no way to be aware of the need for this 
      support.  From one point of view, since there are no SIP elements 
      involved, there is no requirement on the local network.  This 
      requirement does, however, highlight the need for some guaranteed 
      level of service (in terms of call setup delay) from the SIP phone to 
      the first SIP proxy that recognizes this as an emergency 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 telephone network 
      trust the gateway.  Without this element of trust, the chain of 
      accountability stops at the gateway itself. 

   Taylor                 Expires - November 2003              [Page 17] 
                     SIP Emergency Assistance Scenarios          May 2003 

   4.4 Supportability of SIP Phone Deployment Scenarios 

      Based upon the analysis in section 4.3, this section summarizes the 
      supportability of the various SIP phone scenarios as identified in 
      section 4.2.  

   4.4.1  The Local Scenario 
    
      The various requirements for this scenario can all be met without 
      protocol enhancements. They would be met primarily by configuration: 
      configuration of the emergency Request-URI where the caller does not 
      dial the emergency number, configuration of emergency call routing in 
      the GW as applicable, permanent assignment of a telephone number to 
      the SIP phone, and pre-configuration of the location associated with 
      that number in the mapping database.   

   4.4.2 The Regional Operator Scenario 

      This scenario assumes that at least one gateway can reach each ECC in 
      the region.  Configuration still provides an adequate solution to all 
      of the requirements, but this has to include configuration of any SIP 
      proxies in the network to ensure that they route emergency calls to 
      the right gateways.  One possibility is that the SIP telephones are 
      assigned to outgoing proxies based on their location, with the result 
      that onward routing from the proxy is straightforward. 
       
   4.4.3 The National Operator Scenario 

      This scenario introduces the need to be able to route to an ECC based 
      upon the geographic location of the user, which may have no relation 
      to the E.164 number assigned to that user for PSTN reach-ability. 
      Even with an accurate geographic location determined as described in 
      4.3.4, this scenario introduces the possibility that some users have 
      no gateway local to them, so it is necessary for the gateway that 
      does receive the call to route it through the PSTN to the ECC in 
      jurisdiction based upon the geographic location of the user.  This is 
      one of the possibilities considered in section 4.3.2, and may not 
      work in all countries.    

    4.4.4  The Visiting Phone Scenario 

      As with scenario 2, this scenario assumes that at least one gateway 
      can reach each ECC in the region.  The primary additional 
      functionality required beyond that identified for scenario 2 is a 
      mechanism for determining the subscriber's location, with 
      possibilities discussed in section 4.3.4.  Assigning SIP telephones 
      to outgoing proxies based on their location would thus serve in this 
      scenario to ensure that the call is routed to the appropriate 
      gateway.  

   Taylor                 Expires - November 2003              [Page 18] 
                     SIP Emergency Assistance Scenarios          May 2003 

   4.4.5  The VPN Scenario 

      This scenario imposes strict limits on the possible outcomes.  In 
      particular, it is extremely difficult in this scenario to determine 
      the user's location without the help of the user or phone.  If the 
      user can configure his/her current location in the phone, or if the 
      phone has built-in GPS capability, and if a protocol solution exists 
      for carrying that location to the SIP network, it may be possible to 
      route the call appropriately as in the "national operator" scenario 
      3.  Otherwise, without imposing additional requirements and 
      functionality on the local network, all that can be done is to 
      connect the caller to an emergency call centre local to the SIP 
      network and hope that the person handling the call can determine 
      where to route it.  

   6  Security Considerations 

      Security requirements have been identified in the requirements 
      discussion throughout this document.  In particular, the need to 
      ensure the caller identity can be vouched for by trusted identities 
      has been identified.  This is to ensure the caller can be held 
      accountable for any misuse of the system. 
       
      In addition, in those scenarios where an external entity (e.g. DHCP) 
      communicates location information to the SIP phone, it must be 
      possible to ensure the confidentiality, integrity and authentication 
      of this information. 
       
      [Probably need further considerations re DOS, etc.] 

   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. 

      5. N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk, "User 
         Requirements for the Session Initiation Protocol (SIP) in Support 

   Taylor                 Expires - November 2003              [Page 19] 
                     SIP Emergency Assistance Scenarios          May 2003 

         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  Acknowledgments 

      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.  And of course, 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. 

   9  Contributors 

      Mary Barnes 
      Nortel Networks       
      2380 Performance Drive         
      Richardson, Texas 75082           
      Tel: +1 972 684 5432 
      Email:  [email-masked] 

      James McEachern 
      Nortel Networks 
      Ottawa, Ontario 
      Tel:  +1 613 765 2206 
      Email:  [email-masked] 

   10 Author's Address 

      Tom Taylor 
      Nortel Networks 
      1852 Lorraine Ave. 
      Ottawa, Ontario 
      Canada  K1H 6Z8 
      Tel: +1 613 736 0961 
      Email: [email-masked] 

   Taylor                 Expires - November 2003              [Page 20] 
                     SIP Emergency Assistance Scenarios          May 2003 

       
   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 
      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 - November 2003              [Page 21]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 May 2003 22:03:25 -0400

>       centresin the PSTN, the scenarios involving stationary or nomadic SIP 

spelling

>       in the European Market in general, or 000 in Australia.  (Globally 

I thought it was European Community?

>       SIP softphone).  These devices can be stationary or nomadic. 

Why a wired network? I think the issues for a PDA or laptop or even a 
phone (via an Ethernet-to-802.11 bridge) that connects via an 802.11 
hotspot are fairly similar.

>       SIP users and thus addressed by several of the scenarios described in 

I would not make the distinction up front.

>       "legacy" is used to refer to "Enhanced 911" functionality.) 

You mean 'basic 911'?

>       dialed to initiate the call.  

I think all single-number systems support TDD on the same number; that's 
at least true for 911, as far as I know.

>           possible to indicate whether this is a voice call or one to be 

I don't think so. I think the 911 destination listens for the TDD modem 
tone and then switches to a TDD. This is not by number.

>           accidentally drops the telephone back onto its cradle, but then 

As discussed previously, this is not a universal feature. This is more 
of an urban legend at this point :-)

>           connections is outside the scope of this document.) 

Again, I don't think this is generally true, at least in the US.

>           callers from misuse of the system. 

If you ignore pay phones :-)

>       responsible for maintaining the mapping database.   

This is imprecise - at least in the US, there is no 'the' telephone 
system operator. It is generally the ILEC, but I think it would be 
unhelpful to imply that we live in pre-1984/pre-1996 land.

>       within the business and assigned a pseudo directory number (DN), 

Even for phones with DID, extensions are usually not visible to the 
outside. (I've tried it - all of our extensions show up as 7000. We have 
DID in 7000 to 7199.)

>       where it might be necessary.  

I would qualify this as "In analog switches, ....". Most switches today 
are effectively ISDN (or equivalent), so this feature is likely only 
available to a tiny fraction of end systems.

>    4.1   A General Look At The Problem 

at the

>       and a gateway -- before reaching the telephone network.  The SIP 

A SIP proxy isn't mandatory.

[More in next message.]

_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 May 2003 22:34:18 -0400

>       3.2.  The numbers in parenthesis associated with each scenario are 

Section 3.2

>       presented in section 4.3.  

Section 4.3

>       network.  The following diagram highlights the fundamental 

without VPNs and dial-in

>       | Phone |                                         

Not just known, but fixed location. The location of lots of things are 
known to the user...

>       an IP sub-network remote from the SIP network where it is recognized. 

geographically remote

>       telecommuters or a satellite office.   

Or somebody traveling and connecting via VPN to the home office - that's 
probably the most difficult scenario. After all, satellite offices are 
probably fairly stationary (unless they are true earth-orbiting 
satellites...) and I could just assign a block of IP addresses to that 
office.

>       form the Request-URI directly from the user input.   

How? This always requires a dialplan since you can't just do

INVITE 911 SIP/2.0

>          to carry the information. 

Or other SIP configuration information.

>       number is based on pre-configuration of the SIP phone as voice or 

Unless I'm really off my rocker, the number is the same for TDD calls. 
See http://www.nena.org/PR_Pubs/9-1-1QandA.htm for evidence.

>       reserved for fire, police and other specific services.  

Caller preferences is the right solution here. It fits the application 
perfectly, as it allows media selection. Since the routing (terminating 
gateway) is always exactly the same, there is no need for a distinction. 
Now, there is the problem that the gateway has to either be able to 
transparently convey 300 baud TTY (I think that survives even G.729...) 
or translate some text chat into TTY. I think this topic requires far 
more attention, since both solutions are viable:

- Old-style TTY connected via analog line interface (Cisco ATA 186, say) 
to gateway. Result: in-band 'tone' signaling (maybe even 2833...). No 
difference as far as the gateway is concerned.

- SIMPLE text chat.

>       the call.  [This assumption may have to be revisited.] 

A more precise formulation is needed here. For routing, only rather 
crude location information is needed - in some cases, county or 
large-chunk-of-state will get you to the right place. (In New Jersey, 
every town is its own fiefdom, but NJ is not typical - I hope). For the 
call taker, knowing the county isn't particularly helpful in dispatching 
service.

>       as possible to the ECC in jurisdiction.  The gateway must have access 

Why? Is there an advantage to having the correct state or county? (I 
think so, but this should be stated. My reasoning is that somebody in 
the same county or state is probably familiar with the general geography 
and less likely to confuse Lexington, MA and Lexington, KY.)

>       is subject to the limitations of the telephone network (e.g. 

e.g. is always followed by a comma. See 
http://www.cs.columbia.edu/~hgs/etc/writing-bugs.html

>       discussion, dealt with in the next section. 

Not necessarily. Phones might use a SIP URI like [email-masked]. 
Should they be required to use the phone number when dialing an 
emergency number? (This assumes that they can always recognize such a 
number.)

>       system) has told it what its location is (for example, based on the 

Cite James Polk and my DHCP drafts here.

>       the first SIP proxy that recognizes this as an emergency call.    

You could cite the R-P work :-)

>       dial the emergency number, configuration of emergency call routing in 

See above. Numbers always have to be translated somehow - there is no 
'raw' number to SIP translation. Among other things, you need to choose 
whether dialing 911 becomes tel:911;phone-context=... or 
sip:911@somewhere;user=phone, and provide either the context or the 
'somewhere'.

>       that onward routing from the proxy is straightforward. 

How assigned?

>       accountable for any misuse of the system. 

The converse is: How can the user be sure that they have been connected 
to an ECC number instead of having the proxy translate tel:911 to the 
local number run by the friendly call taker impersonator from the 
Sopranos? (I think if somebody wanted to prevent me from placing an 
emergency call and has access to the signaling or media path, there are 
more effective and less likely to be discovered ways of doing this, but 
this issue has come up repeatedly.)

>       In addition, in those scenarios where an external entity (e.g. DHCP) 

e.g.,