Internet DRAFT - draft-hardie-emergency-call-routing

draft-hardie-emergency-call-routing



Network Working Group                                       T. Hardie
Internet-Draft                                              Qualcomm, Inc. Category: Informational                                       July 2004



      Concerns with URI-based call routing for emergency services
               draft-hardie-emergency-call-routing-00.txt


Status of this Memo



   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance
   with RFC 3668.


   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>.


    This Internet-Draft will expire in January 2005.


Copyright Notice


    Copyright (C) The Internet Society (2004).  All Rights Reserved.


Abstract


    This document discusses recent proposals that would introduce a
    common URI or set of URIs to identify and route calls intended to
    reach emergency services.



1. Introduction.


    In a number of areas the public switched telephone network (PSTN)
    has been configured to recognize a short, easily memorized number
    as a call for emergency services.  There may be a single such
    number which is undifferentiated as to service, or there may be
    multiple numbers associated with distinct emergency services.  The
    number assigned to this purpose varies according to region, though
    the regions for which each is valid tend to be large and aligned
    with a major political boundary.  (ES-URI) proposes the
    introduction of a set of global identifiers for emergency services
    which would augment and possibly supersede these emergency service
    numbers.


    The problem inherent in this approach is setting out the
    appropriate context for the resolution of the URI.  This document
    examines some aspects of that problem.


2. URI context and resolution.


    (URI) sets out that:


        URIs have a global scope and must be interpreted consistently
        regardless of context, though the result of that
        interpretation may be in relation to the end-user's context.
        For example, "http:// localhost/" has the same interpretation
        for every user of that reference, even though the network
        interface corresponding to "localhost" may be different for
        each end-user: interpretation is independent of access.
        However, an action made on the basis of that reference will
        take place in relation to the end-user's context, which
        implies that an action intended to refer to a single, globally
        unique thing must use a URI that distinguishes that resource
        from all other things.  URIs that identify in relation to the
        end-user's local context should only be used when the context
        itself is a defining aspect of the resource, such as when an
        on-line Linux manual refers to a file on the end-user's
        filesystem (e.g., "file:///etc/hosts").



    Clearly, a call for emergency services is not intended to refer to
    a single, globally unique resource.  Nor is it, however, something
    local to an individual user's context. It relates to an emergency
    service context which depends on a broad, regional configuration
    of service contact methods and a geographically constrained
    context of service delivery.


    The problem of associating that emergency service context, with
    its irregular geographic boundaries and variability in breadth, to
    a single set of URIs is formidable.  (ES-URI) proposes the use of
    a convention, in which a well-known string is used to construct a
    URI which is neither as local as file:///etc/hosts nor as global
    as http://www.example.com/file.txt. This string concatenates "sos"
    or a substring-augmented form like "sos.fire" with the domain of
    record for the caller to create a URI of the form
    "sip:sos@example.com".


    (ES-URI) provides the following rational for this choice:


        The domain-of-record was chosen since a SIP user agent may not
        be able to determine the local domain it is visiting. This
        also allows each user to test this facility, as the user can
        ensure that such services are operational in his home
        domain. An outbound proxy in the visited domain can handle the
        call if it believes to be in a position to provide appropriate
        emergency services.


     The difficulty here is that there is no existing relationship
     between the domain of record and the emergency service context.
     In addition, maintaining a relationship between the two when the
     calling device is mobile is quite challenging.


3. Call routing.


    In order for the method proposed in (ES-URI) to work, some network
    element must examine the SIP request URI and associate the request
    with an emergency service context appropriate for the user at her
    or his current location.  That network element must then either
    directly or indirectly route the call to the Emergency Call Center
    (ECC) appropriate to that context.  Without more granular
    geographic information, the location used must be assumed from
    network topology; given the prevalence of tunnels in modern IP
    networks, this can be very difficult and can produce incorrect
    results.


    There is no mechanism of which this author is aware for globally
    associating the data needed for geographically based resolution
    with domains of record; those devices which are capable of mapping
    a location to an ECC do so based on local databases whose form,
    scope, and granularity are currently all variable. (DNS-SOS)
    proposes using the DNS as a publication mechanism for this data,
    but notes that once published, data of local interest would have
    to be computed and locally stored to be usable by this system.
    Discovering what data is of local interest is an unsolved problem
    even under that proposal, and the DNS storage of location data is
    unrelated to the use of domains of record.


    While it is theoretically possible to maintain a local copy of a
    global mapping table of every possible ECC to its service area,
    this author believes that this will remain theoretical.  Further,
    maintaining even incomplete mapping tables at every SIP proxy is
    clearly onerous to the point of impossibility.  It may be possible
    to maintain them at specially designated route servers, to which
    SIP servers can forward requests for emergency service for onward
    call routing.  SIP servers would, in such a case, need to be
    configured with the appropriate route server, which would actually
    perform the mapping function and route the call.
   
4) An alternate role for configuration.


    Rather than using a constructed URI which must be recognized and
    interpreted by a network element which is already performing other
    functions, one alternative would be to automatically configure
    devices with an appropriate URI.  In some situations, this URI
    might be local PSTN emergency number encoded as a tel: URI.
    (ES-URI) describes the use of tel: URIs in emergency calls and
    notes that automatic configuration may be required to inform
    mobile devices of the local emergency service number.  In other
    situations, this might be an emergency services call routing
    server, as is mentioned in section 3 above.  Note that in this
    case, though, the intention would be to eliminate the initial
    connection and examination by the usual SIP proxy, and have the
    device talk directly to the emergency service call routing server,
    which would act as a SIP proxy for the emergency call.


    This configuration would, in essence, set the service context,
    thus making the URI resolution context clear and unambiguous.
    Even if the "sos" convention were retained for the left hand side
    of the URI (e.g. sos@local.call.routing.server.example.net), the
    need for intermediate elements to identify a device with
    appropriate local mapping tables is eliminated, and much of the
    complexity of the universal URI proposal reduced.


4.1) Barriers to the use of configuration.


    The use of configuration to set a service context would require
    that the common means of configuring devices would need to be
    extended to carry this data.  At a minimum, this would require
    both DHCP (DHCP) and DHCPv6 (DHCPv6) to set aside appropriate code
    points, and it might require other systems (such as over-the-air
    configuration) to do so as well.  Once the protocol mechanisms
    were in place, devices handling node configuration would have to
    be configured with this data and the data kept up to date.  Route
    servers capable of both associating the location of a caller with
    the appropriate ECC and of handling the SIP call flows would have
    to be deployed.  In cases where a mobile device receives no
    configuration data from a visited network, the home network would
    also have to maintain mapping tables sufficient for associating
    the device to an ECC.


4.2) Advantages to the use of configuration.


    The use of configuration for this level of call routing eliminates
    one network element from the emergency call flow, which should
    speed the call and eliminate a risk that other, non-emergency
    traffic may hinder call completion.  It also supports a relatively
    flexible set of route server deployments; a network may choose to
    provide a very complete set of mappings in one large-scale route
    server farm or may distribute the data around their network.
    Depending on the format of the configuration record, extensibility
    to non-SIP flows might be possible in the future.  For non-mobile
    devices, the configuration of this data should be relatively
    static and easily maintained over long periods of time.


5)  Presentation layer vs. call routing.


    One of the chief advantages of national or regional schemes for
    emergency service numbers is that the numbers selected are short,
    easily remembered, and easily dialed.  These are essentially
    presentation layer characteristics, though, and they mask the
    complexity of effort taken within the PSTN to route the call to
    the appropriate ECC.  Part of the (ES-URI) proposal is clearly
    aimed at the same presentation layer characteristics--having a
    short, mnemonic string to associate with emergency services.


    There is no need, however, for this presentation layer string to
    constrain the development of the protocol elements used to support
    the underlying call routing.  As a thought exercise, imagine every
    phone having an "emergency" button--the UI in this is clear,
    unambiguous, and easy for the end user to understand.  What
    happens when that button is pressed is not constrained by the
    label on the button, though, and a similar independence between
    user interface and call routing can be achieved in this case.
    Just as (ES-URI) notes that a device should recognize both local
    dialing plan and "home region" dialing plan emergency service
    numbers as calls for help, a presentation layer convention can be
    set without it affecting the underlying routing.



6. Security Considerations.


    Any system used to deliver emergency services must be robust,
    timely and protected against malicious interference.  The use of
    automatic configuration methods to derive some element of the
    emergency call routing will inherent any weaknesses of the
    configuration methods; in some instances, those might be severe.
    There is also risk that out of data information may cause
    emergency call information to be routed to route servers which are
    no longer available.  A fallback mechanism (probably to route such
    calls to the usual SIP proxy, which would then use its local
    configuration) is probably necessary.


    If an attacker can spoof or DoS the emergency call routing center,
    calls will not go through.



7. IANA Considerations.


  This document contains no instructions to IANA.


8. Normative References


Schulzrinne, H. "Emergency Services URI for the Session Initiation Protocol"
        draft-ietf-sipping-sos-00.txt (ES-URI)


Berners-Lee, T., Fielding, R., Masinter, L. "Uniform Resource Identifier (URI):
         Generic Syntax" draft-fielding-uri-rfc2396bis-05.txt (URI)


Rosen, B. "Emergency Call Information in the Domain Name System"
        draft-rosen-dns-sos-00.txt (DNS-SOS)


9. Non-Normative References


Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, March
       1997. (DHCP)


Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and
       M. Carney, "Dynamic Host Configuration Protocol for IPv6
       (DHCPv6)", RFC 3315, July 2003. (DHCPv6)


10.  Acknowledgements


    The author would like to acknowledge discussions with
    Randy Gellens, AC Mahendran, and Raymond Hsu.



11. Author's Address


    Ted Hardie
    Qualcomm, Inc.     675 Campbell Technology Parkway
    Campbell, CA U.S.A.


    EMail: hardie@qualcomm.com



Full Copyright Statement



    Copyright (C) The Internet Society (2004).  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.


Acknowledgement


    Funding for the RFC Editor function is currently provided by the
    Internet Society.