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.