One document matched: draft-taylor-sipping-emerg-scen-01.txt
Differences from draft-taylor-sipping-emerg-scen-00.txt
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] | PAFTECH AB 2003-2026 | 2026-04-24 10:36:13 |