A Routing Request Extension for the HELD ProtocolWinterb Consulting ServicesGwynnevilleNSW2500AU+61 448 266004a.james.winterbottom@gmail.comHalls in Tirol6060AustriaHannes.Tschofenig@gmx.nethttp://www.tschofenig.priv.atDeutsche Telekom NetworksDeutsche Telekom Allee 7DarmstadtHessen64295GermanyL.Liess@telekom.dehttp://www.telekom.de
RAI
ECRITInternet-DraftEmergencyCallRoutingLocationHELDIn many circumstances public LoST servers or a distributed network of forest guides
linking public LoST servers is not available. The general
ECRIT calling models breakdown without publically accessible LoST servers.
Sometimes location servers may have access to emergency routing information.
This document defines an extension to the HELD protocol
so a location request can include a request for routing information
and allowing the subsequent location response to include routing information.
The general ECRIT calling models described in
and require a local LoST server or network of
forest guides in order to determine the address of the PSAP in the best
position to handle a call. Networks of forest guides have not eventuated
and while PSAPs are moving towards IP networks, LoST server deployment is
not ubiquitous. Some regions and countries have expressed reluctance to
deploy LoST servers making aspects of the current ECRIT architecture hard to
realize.
Evolving architectures in Europe to address regulatory requirements, such as
, couple location and routing information in the access
network whilst using a softswitch-centric approach to emergency call processing.
This document describes adding an extension to the HELD protocol
so that a location
information server can provide emergency routing information in the absence
of a LoST server or network of forest guides.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
The terms LIS, ESRP, VSP and PSAP are used as defined in .The term "Access Network Provider" is used as defined in and incompasses both the Internet Access Provider (IAP) and Internet Service Provider (ISP).The Internet emergency calling architecture specified in
describes two main models for emergency call processing. The first is a
device-centric model, where a device obtains location information using a location
configuration protocol, such a HELD ,
and then proceeds to determine the address of the next hop closer to the local PSAP
using LoST .
shows this model in a simplified form.
The second approach is a softswitch-centric model, where a device
initiates and emergency call and the serving softswitch detects that the call is an
emergency and initiates retrieving the caller's location from a Location
Information Server (LIS) using HELD with identity
extensions and then determining
the route to the local PSAP using LoST .
shows the high-level protocol interactions.
In the softswitch-centric model when a VSP receives an emergency call it performs two tasks.
The first task is to determine the correct LIS to ask for location information, this is
done using a combination of reverse DNS lookup described in to
acquire the serving domain name and then using to determine the
LIS URI. Once the location is obtained from the LIS, the VSP determines the LoST server
associated with the domain serving the caller and queries it for the correct PSAP address.LoST server discovery is a domain based activity, similar to the LIS discovery
technique. However, unlike the LIS that is a domain bound service, a LoST server is a
geographically bound service. This means that for a domain that spans multiple geographic
regions the LoST server determined may not be able to provide a route to the necessary PSAP.
When this occurs, the contacted LoST server invokes the help of other LoST servers and
this requires the deployment of forest guides.
At the time of writing, several countries have expressed a reluctance to
deploy public LoST servers. In countries amenable to the use of LoST and forest guides no public
forest guides have been deployed. There appears little interest from the public sector
in establishing a global forest guide network. These issues pose threats to both the
device-centric and the softswitch-centric calling approaches in terms of them operating
everywhere.
The device-centric and softswitch-centric calling models both involve the notion of a
LIS bound to the serving access network. In many cases the LIS already knows the
destination PSAP URI for any given location. In for example,
the LIS validates civic locations using a location validation procedure based on the
LoST protocol .
The LoST validation request is similar to a LoST routing request and provides the LIS
with the same PSAP routing information that a routing request would.
In other cases, the LIS knows the correct PSAP for a given
location at provisioning time, or the access network might always route to the same
emergency provider. Irrespective of the way in which the LIS learns the PSAP URI
for a location, the LIS will, in a great many cases, already have this information.
This document specifies an extension to the HELD protocol so that emergency
routing information can be requested from the LIS at the same time that location
information is requested. The document updates by requiring
devices and softswitches that understand this specification to always request routing
information to avoid the risk of query failure where no LoST server or forest guide
network is deployed.
The mechanism consists of adding an element to the HELD locationRequest and an element
to the locationResponse.
The request element indicates that the requestor wants the LIS to provide routing
information based on the location of the end-device.
If the routing request is sent with no attribute then URIs for urn:service:sos
are returned.
If the requestor wants routing information for a specific service then
they may include an optional service URN. If a service is specified, and the
LIS does not understand the requested service then URIs for urn:service:sos are returned.
If the LIS understands the routing request and has routing information for the location
then it includes the information in a routingInformation element returned in the
locationResponse. How the LIS obtains this information is left to implementation,
one possible option is that the LIS acquires it from a LoST server, other possibilities
are described in .
A LIS that does not understand the routing request element ignores it and returns
location as normal.
A LIS that does support the routing request element SHALL support returning URIs for
urn:service:sos
A LIS that does understand the routing request element but can’t obtain any
routing information for the end-device's location SHALL only return location
information.
A LIS that understands the routing request element but not the specified
service URN, returns the routing URIs for the urn:service:sos service.
The routing information in the location response consists of a service
element identified by a service name. The service name is a urn and might contain
a general emergency service urn such as urn:service:sos or might contain a specific
service urn depending on what was requested and what the LIS is able to provide.
A list of one or more service destinations is provided for the service name.
Each destination is expressed as a URI and each URI scheme should only
appear once in this list. The routing URIs are intended to be used at the time they are
received. To avoid any risks of using stale routing URIs the values MUST NOT be
cached by the receiving entity.
The LoST Protocol defines a <mapping> element that
describes a service region and associated service URLs. Reusing this element from
LoST to provide the routing URIs was considered. However, this would have meant that
several of the mandatory components in the <mapping> element would have had to
contain ambiguous or misleading values. Specifically, the "source"
attribute is required to contain a LoST application unique string for the authoritative server. However, in the situations
described in this specification there may not be an authoritative LoST server, so any
value put into this attribute would be misleading. In addition to this, routing information
received in the manner described in this specification should not be cached by the receiver,
so detailing when the routing information expires or was last updated is irrelevant.
This section describes the schema extension to HELD. illustrates a <locationRequest> example that contains IP flow information in the request. illustrates the <locationResponse> message
containing two location URIs: a HTTPS and a SIP URI. Additionally,
the response contains routing information.This document makes no changes that require privacy considerations beyond those
already described in and .This document imposes no additional security considerations beyond those
already described in and .This document calls for IANA to register a new XML namespace, as per the guidelines in .
urn:ietf:params:xml:ns:geopriv:held:riIETF, ECRIT working group (ecrit@ietf.org),
James Winterbottom (a.james.winterbottom@gmail.com).This section registers an XML schema as per the procedures in .
urn:ietf:params:xml:schema:geopriv:held:riIETF, ECRIT working group, (ecrit@ietf.org),
James Winterbottom (a.james.winterbottom@gmail.com).The XML for this schema can be found as the entirety of of this document.
We would like to thank Wilfried Lange for sharing his views with us.
We would also like to thank Bruno Chatras for his early review comments and
Bernd Henschel for his support. Thanks to Roger Marshall and Randy Gellens
for their helpful suggestions.Functional architecture to support European requirements
on emergency caller location determination and transport
European Telecommunications Standards Institute