Session Initiation Protocol Investigations
   Internet Draft                                               Tom Taylor
   Document: draft-taylor-sipping-emerg-scen-01.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 that it is essential in a number
      of scenarios (and helpful for all) 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 Retaining Access To The Caller......................17
            4.3.7 Minimum Delay In Call Setup.........................18
            4.3.8 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
   
      With use of VoIP growing and the potential for existing
      implementations to result in problems and delays in organising
      responses for ECCs, there is now an urgency to arrive at emergency
      call standards.
   
      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.
   
   
   
   
   Taylor            Expires - February 2004          [Page 3]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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 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),
      either directly or by connection to a separate centre, in response
      to incoming calls.
   
      Target ECC
   
   
   
   Taylor            Expires - February 2004          [Page 4]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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.
   
      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
   
   
   Taylor            Expires - February 2004          [Page 5]


                SIP Emergency Assistance Scenarios October 2003
   
   
      -  the circuit connecting the telephone set to the telephone network
   
      -  the telephone network, consisting of switches and trunk circuits
   
      -  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 and Britain, a different number may be
      dialed to initiate the call to a text-based emergency call service.
      In other places such as North America, 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 either directly or by further onward
   
   
   Taylor            Expires - February 2004          [Page 6]


                SIP Emergency Assistance Scenarios October 2003
   
   
      connection to a service-specific despatching centre (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.)
   
      (3)   The telephone network should be supplied with, or enabled to
      supply, a calling party number or other unique geographic indicator,
      that can serve as a key to the mapping database.
   
      (4)   The caller's location needs to be supplied during call set-up,
      or by being keyed by calling party number or other unique
      identifier, 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.
   
      (6)   The telephone network should be supplied with, or enabled to
      supply, a number which enables the ECC to call back to the SIP phone
      that made the original emergency call.
   
      (7)   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.)
   
      (8)   The caller can be held accountable for the call, to dissuade
      callers from misuse of the system.  In particular callers should not
      be able to withold calling number or location information when using
      emergency codes.  Moreover, call records should be stored for at
      least the initial and final steps in the call path through each
      service provider's network.
   
   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 to speed-up
   
   
   Taylor            Expires - February 2004          [Page 7]


                SIP Emergency Assistance Scenarios October 2003
   
   
      call handling and response times on all calls, and to be of
      especially important assistance in cases where the caller is unable
      to provide the information. (This is now part of the regulatory
      regime for emergency calls in the US and European Community).
   
      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 to help
      establish if the call is genuine. Note that this functionality is
      not supported for ISDN.
   
      For further checks after call connection, and when it is not
      possible to hold the line, 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 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 routing
      information and Calling Party Number information by configuration of
      data in their switches based on knowing call's originating location.
      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
   
   
   Taylor            Expires - February 2004          [Page 8]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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.
   
   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 /      +------+     \        /       +------+
   
   
   Taylor            Expires - February 2004          [Page 9]


                SIP Emergency Assistance Scenarios October 2003
   
   
       \       /          |          \      /           |
        +-----+           |           +----+            |
          |               |                             |
      +------------+  +------------------+            +-------------+
      | 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:
      -  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 be
      provided with a callback 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
   
   
   
   Taylor            Expires - February 2004         [Page 10]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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 |
                                                   +-------------+
   
   
      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
   
   
   Taylor            Expires - February 2004         [Page 11]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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 |
      +------------+                                  +-------------+
   
   
      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 |\
      +-------+ \
   
   
   Taylor            Expires - February 2004         [Page 12]


                SIP Emergency Assistance Scenarios October 2003
   
   
          |      \
          |       \
        +-----+    \   +------+      +-----+         +------+
       /       \    \--| PSTN |      /      \   (1)  |Other |
      /  SIP    \------|  GW  |-----/ PSTN   \-------| ECC  |-+
      \ Network /      +------+     \        /       +------+ |
       \       /          |          \      / \         |     |
        +-----+           |           +----+   \    (1a)| (1b)|
                          |                  (2)\       |     |
               +-------------+                   \      |     |
               |  Routing DB |                    \  +------+ |
               +-------------+                     \-|Target| |
                                             /-------| ECC  | |
                                            /        +------+ |
                                +-------------+         |    /
                                | Mapping DB  |   +----------+
                                | CgPN ->     |   |  Local   |
                                |    location |   | Emergency|
                                +-------------+   | Services |
                                                  +----------+
   
   
      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
   
   
   
   Taylor            Expires - February 2004         [Page 13]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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.
   
   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.
   
   
   Taylor            Expires - February 2004         [Page 14]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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
      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
   
   
   
   Taylor            Expires - February 2004         [Page 15]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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.
   
      -  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 (based on information from the SIP
         network) 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
   
   
   Taylor            Expires - February 2004         [Page 16]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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.
   
      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.
   
   
   
   
   
   
   Taylor            Expires - February 2004         [Page 17]


                SIP Emergency Assistance Scenarios October 2003
   
   
   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.
   
   4.3.6 Enabling Call Back
   
      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
   
   
   
   Taylor            Expires - February 2004         [Page 18]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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.7 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.8 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.
   
   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 is helpful in all cases
      and essential in a number of scenarios.  The development of a
      suitable location header field should be given priority in the
      SIPPING and SIP Working Groups.  (Requirements for such a header
      field are documented in [11].)
   
      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.
   
   
   Taylor            Expires - February 2004         [Page 19]


                SIP Emergency Assistance Scenarios October 2003
   
   
   6  Security Considerations
   
      Potential threats specific to emergency calling scenarios include:
   
      -  abuse of the service (i.e., use to make non-emergency calls).
         This is of critical importance with hoax, false and accidental
         calls being more than half the emergency calls received in some
         countries.
   
      -  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.]
   
   
   
   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.
   
   
   
   
   Taylor            Expires - February 2004         [Page 20]


                SIP Emergency Assistance Scenarios October 2003
   
   
      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.
   
      11. James M. Polk, "Session Initiation Protocol Location
         Requirements", work in progress.
   
   
   
   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 <mbarnes@nortelnetworks.com> and Jim McEachern
      <jmce@nortelnetworks.com> helped to shape the text of the initial
      issue of this document.  Dick Knight <dick.rr.knight@bt.com> and
      Steve Norreys <steve.norreys@bt.com> helpfully contributed
      descriptions of emergency services operation in the UK and Patrick
      Emery <Patrick.Emery@aca.gov.au> did the same for Australia.  The
      present version of this Internet Draft has been strengthened by Dick
      Knight's comments on the previous version.
   
   
   
   
   
   
   
   Taylor            Expires - February 2004         [Page 21]


                SIP Emergency Assistance Scenarios October 2003
   
   
   9  Author's Address
   
      Tom Taylor
      Nortel Networks
      1852 Lorraine Ave.
      Ottawa, Ontario
      Canada  K1H 6Z8
      Tel:   +1 613 736 0961
      Email: taylor@nortelnetworks.com
   
   
   Full Copyright Statement
   
      Copyright (C) The Internet Society (2003).  All Rights Reserved.
   
      This document and translations of it may be copied and furnished to
      others, and derivative works that comment on or otherwise explain it
      or assist in its implementation may be prepared, copied, published
      and distributed, in whole or in part, without restriction of any
      kind, provided that the above copyright notice and this paragraph
      are included on all such copies and derivative works.  However, this
      document itself may not be modified in any way, such as by removing
      the copyright notice or references to the Internet Society or other
      Internet organizations, except as needed for the purpose of
      developing Internet standards in which case the procedures for
      copyrights defined in the Internet Standards process must be
      followed, or as required to translate it into languages other than
      English.  The limited permissions granted above are perpetual and
      will not be revoked by the Internet Society or its successors or
      assigns.  This document and the information contained herein is
      provided on an "AS IS" basis and THE INTERNET SOCIETY   AND THE
      INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,EXPRESS OR
      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]