T5.4: Routing, Location-based Information and Caller ID
Table of content
Introduction ... 2
Terminology ... 2
IP-based emergency services’ access ... 3
Emergency Call Identification ... 4
Call Routing ... 5
Location Information... 5
Caller Identity ... 8
Implementation Status ... 10
Recommendations and Guidelines to the Project ... 10
Conclusion ... 16
Introduction
The task for the work in the task 5.4 is to develop a report that will serve as input to the implementation and deployment work in the different countries. The aim is to help every pilot country to implement appropriate routing so that emergency calls get to the right PSAP, to provide PSAP’s with automatic caller-location and caller-ID so that first responders can intervene at the place of incident with the relevant information and use some traditional emergency services functions such as call-back.
To achieve these goals, a questionnaire (see appendix A) was created by EENA (Task Leader) and sent to all involved partners. The responses were then discussed during dedicated conference calls along with the presentation of best practices in the field of routing, caller-location and caller-ID. Personal contacts were then established by phone and emails between EENA (Hannes Tschofenig/Gary Machado) and partners involved. Best practices, literature and ongoing standardisation efforts were reviewed by Hannes Tschofenig from EENA who is/was also involved with several standardisation groups in the field (EENA NG112, IETF ECRIT, NENA NG911, etc...). It should be noted that at the time of the redaction of the task’s timeframe and missions, it was not foreseen that the tasks would deserve so much attention and efforts. Deliverable D2.1 also revealed that emergency services considered as a high priority the delivery of caller-location information. The consortium therefore decided to extend the timeframe for this task in order to provide a complete report so that to facilitate implementation in the pilot countries.
The document is structured as follows:
A brief description of the concept of IP-based emergency services’ access, since REACH112
is a unique project focusing on providing IP-access to 112
A chapter on emergency call identification and routing that has been added since routing is
a challenge to be faced by the project when considering the use of IP
A chapter on the provision of caller-location information
A chapter on caller-identity (caller-ID)
An overview of the implementation status in the pilot countries
Recommendations and guidelines to the project for implementation
A conclusion highlighting what can be achieved and the challenges that the consortium and
any other entity willing to provide IP-access to 112 will face
Terminology
The terms used in this document can be found in http://www.ietf.org/rfc/rfc5012.txt and in the
NENA Glossary
IP-based emergency services’ access
The IP-based emergency services’ access architectures differentiate a few components that have different responsibilities for offering the complete end-to-end functionality. These roles are:
Internet Service Provider (ISP)
Voice Service Provider (VSP), or in a more generic form Application Service Provider (ASP)
Emergency Service Provider (that operates a PSAP) and vendors of equipment for those.
End Device
Independent Location Server. This entity is an artefact of today’s IP-to-location
infrastructure and other efforts to register network specific information (e.g., base station identifiers) to location information.
Note that a partner may combine multiple roles in a single organisation.
Figure 1 shows the parties graphically and the arrows indicate communication interaction as utilised in the pilot projects but other interactions are possible.
Figure 1: Participating Involved Entities.
The emergency call interaction on a high level takes place as follows: the user enters an emergency services number (or potentially an emergency dial string). The end device recognises the entered sequence of digits as an emergency call attempt and determines whether location information is available locally (as part of the GPS module, for example). If no location information is available locally then various protocol extensions have been defined that allow the end host to obtain location information from a location server in the ISP’s network. Additionally, independent location servers may be used as well. Then, the call setup procedure using SIP is started towards the user’s VSP/ASP. The VSP/ASP needs to make a route decision to determine where the call
needs to be forwarded to. Often, this decision is based on a combination of the caller’s location information as well as other policy aspects (such as time-of-day, workload of a specific PSAP).
When considering IP-access to emergency services, one should consider the following categories and the challenges they induce:
Fixed Access: From a user point of view this scenario is characterised by a stationary usage
of a computer, such as a desktop PC at someone’s home. Typically, these devices are often not equipped with a GPS receiver or, because of the indoor usage, these do not work very well or not at all. Information about the caller’s location can therefore come from manual configuration (which may be useful in cases where the location of the device indeed rarely changes or the user is careful in keeping the reported location accurate) or from the ISPs network since the attachment point is known to the operator’s network infrastructure.
Nomadic Access: Nomadic access is characterised in movement patterns that correspond to
regular laptop usage where user’s switch location from time to time (e.g. go to work, use their laptop at the university or in a coffee shop, and at home). In this scenario it is not realistic to assume that user’s keep their location accurate manually due to the frequent change. The usage of GPS may be possible even though network operator presented location would be preferred since users will typically use their device indoors.
Mobile Access: This scenario is an enhancement of the previously presented nomadic
access with the assumption that user’s roam while having their communication ongoing. In this scenario, devices, such as smart phones, are often equipped with GPS receivers and make the location determination process more accurate. Manually entered location is in this scenario not possible.
Note: This is a simplified view on networking from the user’s point of view. As network architectures become more sophisticated the boundaries between these scenarios get more fuzzy. As an example, one may consider a traveller using a laptop with wireless LAN (as he uses at home) in a train connected. The network infrastructure in the train is connected via a cellular infrastructure to the Internet. This example blurs nomadic access and mobile access. Consider another example where a teenager uses his high-performance laptop for gaming and sometimes uses it at home as a replacement for the desktop PC and sometimes at some LAN parties to compete with other games. From software program point of view these cases are very hard to differentiate since in all cases the end device is uses WLAN technology to communicate with the network. Hence, it is left to the user to “switch” between usage environments, which introduce problems when software developers make too restrictive assumptions about the environment where their devices will later be used or about the user’s awareness of the necessary configuration changes. Ideally, user’s should not need to configure their devices to prepare for the case of an emergency call. For the unlikely case of an emergency user’s should not be required to ever configure their device – zero configuration is the goal.
Emergency Call Identification
The overall process of establishing an emergency call begins with the person in need for help dialling the emergency dial string. The exact sequence of digits depends on the infrastructure the device is connected to. While 1-1-2 became the emergency services number for Europe many countries still provide emergency numbers in addition to the 112. Furthermore, many large enterprises, university, and hotels prefix the emergency numbers with additional digits, such as 0-112.
For devices that can be used in a variety of different environments, as discussed in the previous section, it is therefore important to automatically detect which dial string leads to an emergency
call. Pre-programming the list of numbers in use world-wide is not possible due to the overlap of emergency and non-emergency numbers.
There are two challenges to solve: First, a device needs to have the capability to learn their emergency services numbers available for a specific attachment point. Second, for protocol treatment it is useful to replace the actual dial string with a symbolic name. The latter part is addressed by the usage of Service URNs, see RFC 5031.
An example of a service URN is "urn:service:sos.police". Users do, however, not "dial" an emergency URN. Instead, the entered emergency dial strings are translated to corresponding service URNs, carried in the Request-URI of the INVITE request. This translation should ideally be done at the end point because the need to detect an emergency call at the end host is required, for example, to convey location in the signalling. Network entities can then use the service URN to easily perform preferential emergency service treatment to the incoming call setup attempt. LoST is an HTTP-based query/response protocol, see RFC 5222, which provides the mechanism for obtaining the emergency dial string for a given location. For the pilot project the usage of devices in different environments will initially be limited and hence the dynamic discovery of emergency dial strings can be replaced by provisioning of emergency numbers.
Call Routing
An important part of emergency handling is in the logic of delivering emergency calls to the appropriate PSAP. With devices that may be used with different VSPs/ASPs and in cases where there is no relationship between the ISP and the VSP/ASP the automatic routing decision becomes more complex. Consider the following example where REACH-112 user Bob travels to from Sweden to to Spain and wants to use their device to trigger an emergency real-time text interaction. Since Bob is using a real-time text provider in Sweden the messages are routed to the Swedish operator. Based on the provided location the Swedish operator notices that a PSAP in Spain has to be involved and, for example, initiates a conference bridge with Bob, a relay provider in Sweden serving as a language translator, and the PSAP operator in Spain. In order for the Swedish ASP/VSP or the Swedish PSAP to involve the appropriate Spanish PSAP their contact information needs to be available, and information about their responsibility (i.e. for which region they are responsible and which emergency service function they provide) needs to be published.
The Location-to-Service Translation Protocol (LoST) allows this information to be made available automatically rather than exchanging Excel sheets or Word documents. The main functionality of LoST therefore is to map a location and service URN to a specific PSAP URI and a service region. The returned PSAP URI does not necessary need to be the URI of the final PSAP but rather it will route the call closer to one. A LoST client software can run on an end host, on a VSP proxy, or within the emergency services network for multi-stage routing. As an example for the emergency call routing within an emergency services network the French pilot offers such support.
Location Information
The topic of location information can be sub-divided into the following categories:
1) Formats of location information
There are two important types of location information relevant to this document, namely civic and geodetic location information.
Civic location information describes the location of a person or object by a street address that corresponds to a building or other structure.
Geodetic location information contains longitude, latitude and altitude information based on a selected datum (such as WGS84).
Both location formats are useful for emergency services. Geodetic information is used in the cellular world whereas civic location information is utilised in fixed network deployments. Conversation from geodetic location information to civic addresses is also possible and used particularly for dispatch of first responders.
In the REACH112 project both location formats will be utilised.
2) Encoding of location information used for transmission in protocols
For usage in communication protocols location information needs to be encoded and different formats have evolved over time. Two formats widely used are based on XML and on a binary encoding.
For the purpose of the REACH112 project only the XML-based format is used. The XML-based
format for location was introduced in RFC 41191 with the Presence Information Data Format
Location Object (PIDF-LO). The format was revised with RFC 54912 (for geodetic location
information) and RFC 51393 (for civic location information). Furthermore,
http://datatracker.ietf.org/doc/draft-singh-geopriv-pidf-lo-dynamic/ extends the format in support of moving objects.
For the project it is useful to think about a civic location profile for the respective member countries in the style of RFC 57744.
An example PIDF-LO document that shows location information that could have been provided by a GPS receiver with a point location shape (lat/long values only) inside a SIP INVITE is shown below:
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Max-Forwards: 70
To: PSAP <sips:psap@example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@atlanta.example.com> ;routing-allowed=yes
Supported: geolocation
Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE
Contact: <sips:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ...SDP goes here
1 http://datatracker.ietf.org/doc/rfc4119/ 2 http://datatracker.ietf.org/doc/rfc5491/ 3http://datatracker.ietf.org/doc/rfc5139/ 4 http://datatracker.ietf.org/doc/rfc5774/
--boundary1 Content-Type: application/pidf+xml Content-ID: <target123@atlanta.example.com> <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gml="http://www.opengis.net/gml" entity="pres:alice@atlanta.example.com"> <tuple id="target123"> <dm:device id="target123-1"> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>32.86726 -97.16054</gml:pos> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no </gp:retransmission-allowed> <gp:retention-expiry>2010-07-30T20:00:00Z </gp:retention-expiry> </gp:usage-rules> <gp:method>GPS</gp:method> </gp:geopriv> <dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp> </dm:device> </tuple> </presence> --boundary1--
GPS obtained location information can be encoded in a PIDF-LO document in a few different ways depending on the accuracy, such as a Circle, Ellipse, or Ellipsoid. The detailed encoding of location is described in RFC 5491.
3) Protocol mechanisms to request and obtain location information
A number of protocols have been developed to allow an entity to request location and to obtain it in response. The designs vary based on what input information is utilised and into what other
communication protocols the message exchanges are embedded. The description in this document will only focus on the protocol mechanisms that are relevant for the REACH-112 project rather than a complete survey of all protocols available on the market.
Two protocol mechanisms may be used in the REACH-112 pilot for obtaining location information, namely
1) A protocol for allowing a Nokia phone to communicate with a Nokia Location Database. 2) A protocol for allowing the French PSAPs to obtain location information from the France Telecom location server.
In case #1 the interaction is based on a standardised protocol, namely SUPL, but since no network operator in the pilot countries utilises this protocol and, in case of the Nokia Location Database, only Nokia phones are allowed to access the database no interoperability need arises.
In case #2 the interaction is based on a proprietary HTTP-based protocols for retrieving location
information, as documented in http://api.orange.com/en/api/location-api/documentation,1.
4) Procedures for location determination.
Before location can be encoded, put into a protocol for delivery and utilised it first needs to be determined. Location information can be entered by a user ("manual configuration"), measured by the end host, can be delivered to the end system by some protocol or measured by a third party. The actual process of location determination is largely outside the scope of the REACH-112 project but manual configuration, GPS usage, and the usage of location servers is relevant.
Many VoIP deployments allow their users to manually enter location information for later usage with emergency services. Typically, the users enter their home address into a web-based form and this data would then be used for emergency service call routing and also delivered to PSAP operators. This mechanism is primarily suitable for user’s utilising fixed network deployments (such as Cable and DSL networks) rather than cellular networks where the current user’s location changes continuously. For nomadic users this approach already becomes very cumbersome for end users. While this mechanism clearly has limitations it is still a useful approach in absence of other techniques.
For devices like laptops and in particular mobile phones the usage of GPS is a promising technique that is able to provide highly accuracy. While it has also has limitations (for example when used indoor) and may need a fair amount of time to provide the initial location fix it is a promising technique. In the REACH112 project many of the mobile end devices have GPS available and from an implementation point of view only the appropriate Application Programmable Interfaces (APIs) need to used in order to gain access to GPS information.
Caller Identity
Caller identity information is another important information element that is provided to the PSAP in case of an emergency call. In the more generic form we speak about data that is associated with the person initiating the call. Caller identity comes in the form of the calling party’s SIP Uniform Resource Identifier (URI) that can be used for a callback in case the communication got interrupted prematurely and further information needs to be obtained by the call taker.
While the caller’s identity is clearly useful for emergency services purposes it’s main usage is for regular peer-to-peer communication in Total Conversation: knowing the calling party for decision making is a critical aspect for a communication system.
The SIP protocol suite has a number of specifications that provide caller identity information and this section describes the main mechanisms. The mechanisms can be clustered into three categories for the purpose of this document, as shown in Figure 2. There are four distinct building blocks that need to be considered, namely
1) the process of verifying the user’s identity. The VSP/ASP’s infrastructure elements authenticate the user. This can, for example, happen via the basic SIP authentication mechanisms (such as digest authentication).
2) the process of asserting the previously verified identity. The previously authenticated
identity is not only important for the VSP/ASP but for end-to-end communication of interest to the remote party as well. The VSP/ASP can assert this identity towards other parties using mechanisms, such as SIP Identity described in RFC 4774 or P-Asserted-Identity described in RFC 3325. The main difference between the two mechanisms, as described in more detail later is that the cryptographic assurance provided with SIP Identity is provided with P-Assert-Identity using a non-cryptographic technique called chain-of-trust.
3) SIP signalling security. This ensures that an adversary cannot inject fake signalling
messages, eavesdrop on the communication, etc. Transport Layer Security (TLS) is one possible protocol providing such security support function.
4) Media security. Since the ultimate goal of the communication establishment is in the
exchange of data between the two end points the security properties need to cover the full range of communication exchanges, including the media exchange. SRTP is the established standard for securing the Real-Time Transport Protocol (RTP). In order to enable SRTP cryptographic keys need to be established between the two communication parties. The Security Description (SDES), described in RFC 4568, and DTLS-SRTP, described in RFC 5763, are two mechanisms to do so.
Figure 2: Identity and Security Architecture Overview.
Appendix D: Identity and Security
Mechanisms
.Implementation Status
This section summarises the feedback from a questionnaire distributed to the different project members. The main purpose of the questionnaire was to get a better understanding what implementation support regarding location support and caller-id is available. The response is clustered into two groups, namely caller-id and location, and the provided information reflects the status around the April-May 2010 timeframe when the responses to the questionnaire were returned.
Caller Identity
To authenticate the user most implementations only support the basic functionality of the
SIP specification, namely HTTP Digest (RFC261). Nokia reported more sophisticated authentication capabilities with Digest AKA (RFC3310), IMS AKA (TS 33.203) and Early IMS authentication (TR 33.978).
Support for P-Asserted-Identity was stated as not being available while SIP Identity was
implemented by Aupix. IVES, however, stated plans to implemented PAI.
4CT indicates support for SRTP. No information is available regarding the key management.
SIP signalling security mechanisms do not seem to be available in the implementations.
Implementation support for GRUU is not available.
Location
Support for manually entered location is available for all pilot countries, except for Sweden.
Many of the mobile devices come with GPS support, which can be used for location support.
Nearly all of the current members have not implemented location support yet. The APIs for
access to the GPS receiver (in the operating system or the used programming framework) are claimed to be available (for example, based on response from Nokia, and IVES).
SIP Location Conveyance http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance
was not implemented by any of the parties (which is not surprising given the answer about the location implementation support). There is interest in implementing SIP location conveyance (e.g. IVES).
Location configuration protocols and location dereferencing protocols are not implemented
with the exception for Nokia and FT. As described in the document these two implementations either do not allow interoperability or are proprietary. Nevertheless, they are very useful for the purpose being investigated.
There is also interest to provide the support for an IP-to-geolocation service (e.g. IVES).
Recommendations and Guidelines to the Project
Recommendations
I. Location Information
Recommendation L-1: Use PIDF-LO for encoding of location information (civic as well as geodetic location information).
Recommendation L-2: Use the ability to carry a PIDF-LO MIME object in SIP (as suggested with Location Conveyance) for the delivery of location information in SIP. Note that this does not require every feature of SIP Location Conveyance to be implemented since the scenarios in REACH112 only provide end host provided location information and not a proxy to insert a location on the fly. Recommendation L-3: Support manual configuration of location information for users in fixed network deployments. This requires a user interface to allow users to enter their information. For user-entered information it is recommended to validate the received input against an authoritative address guide containing existing civic addresses.
Recommendation L-4: Make use of GPS enabled devices for accurate location. Due to the nature of GPS mid-session location updates (e.g. via re-INVITEs or SIP UPDATE) need to be supported. Recommendation L-5: For cellular devices information about cell identifiers should be transmitted in SIP to allow the cell sector where the emergency caller is located to be determined.
II. Caller Identity
Recommendation I-1: In addition to the authentication verification capability (e.g. via SIP digest) also support the facility to assert the user’s identity with P-Asserted-Identity.
Recommendation I-2: To provide protection of SIP signalling offer support for Transport Layer Security (TLS).
Recommendation I-3: For security of media traffic exchanged between the two parties (particularly in the non-emergency services communication) provide SRTP for media security. To establish keying material for usage with SRTP at least support SDES.
III. Emergency Call Signalling
Recommendation S-1: End hosts SIP stacks must be enhanced to detect emergency dial strings entered by users to initiate an emergency call. Due to the limited nature of many of the devices in the pilot countries and their inability to be moved to be used in a generic context (and even in another pilot region) it is recommended to pre-configure a list of emergency dial strings into those devices. For devices that can, however, be used in different environment a dynamic discovery procedure is recommended. In the long-run an automatic configuration will be required to avoid surprises for user’s seeking for help.
Recommendation S-2: To mark emergency calls in SIP signaling the usage of the Service URNs is recommended.
Country-specific Circumstances
This section summarises aspects that are unique for the different pilot countries. The description refers to the high level setup shown in Figure 1 but we replicate the figures to illustrate the participants in the country-specific pilots.
Important: The figures show the parties that provide the software rather than those who provide the hardware or those who run the software.
Figure 3: Swedish Pilot Setup.
Figure 3 shows the setup of the Swedish pilot with devices in the form of:
• Special hardware devices (Internet Tablets provided by Omnitor)
• Mobile phones (E71 provided by Nokia)
• Laptops (with software provided by Omnitor)
The client software from Omnitor is a SIP client. that is not available as open source. The same is true for the SIP client on the Nokia devices.
Currently, there is no location support provided in the Swedish pilot for the Omnitor devices (including the lack of support for manual registration of the user’s location). The emergency number is recognised by the VSP/ASP proxy provided by Omnitor. Basic SIP security is offered for authentication but no TLS call signalling is provided or media security.
The relay for sign language interpretation is provided by a third-party; the same is true for the text relay. The PSAP is operated by SOS Alarm and Omnitor will install 2 PCs onsite to provide IP-based emergency services support.
Recommendations:
Since the Nokia phones are equipped with GPS and may be able to utilise circuit-switched
location information or the Nokia location database there is a chance to offer location support for emergency calling within the Swedish pilot.
For improved security between the end device and the VSP the Nokia device could be used
but still the VSP/ASP proxy by Omnitor would have to offer the corresponding support to utilise the functionality. To utilise end-to-end media security the end host can interact with two possible end points, namely the third party relay and Omnitor’s PSAP. Currently, these two devices do not support SRTP and the corresponding key management.
Providing identity support is fairly simple in case of emergency communication towards the
Omnitor PCs located at SOS Alarm when Omnitor’s VSP/ASP proxy acts as an Authentication Service. In this case the identity assertion is provided by Omnitor’s proxy and verified by Omnitor’s SIP server PSAP. Interoperability challenges arise in case of roaming where the caller uses a different VSP/ASP.
For end-to-end security with the PSAP the Omnitor SIP server has to be upgraded.
Spain
Figure 4: Spanish Pilot Setup.
Figure 4 shows the setup of the Spanish pilot with devices in the form of
PCs/Laptops (provided by Siemens)
Mobile phones (E71 provided by Nokia)
The software used at the Siemens devices is based on an open source SIP stack (see
http://sourceforge.net/projects/tipcon1/) that was originally developed in a project where Omnitor was involved. It should be noted that this SIP stack is different to the one used by Omnitor in Sweden. This implementation offers a good real-time text implementation but does not offer location support or anything beyond very basic authentication security support (based on username and password). Neither media security nor signalling security is offered.
Recommendations:
Manual location configuration support by the user is provided. More details are, however,
needed to verify the approach taken with those from other pilot countries (e.g. screenshots).
No location server support is provided although the dialog with Telefonica could be initiated
since they are providing location support in the EU funded PEACE project also for emergency services purposes.
Figure 5: French Pilot Setup.
Figure 5 shows the setup of the French pilot with devices from IVÈS.
The important aspect in the French pilot is the usage of location from France Telecom using an HTTP-based location retrieval function. More detail about the location API can be found here:
http://api.orange.com/en/api/location-api/documentation,1
Support for manual location provisioning is envisioned in the pilot as well as the usage of a GeoIP functionality for lookup at the VSP to determine the country of the emergency caller.
Recommendations:
• The usage of FTs location for mobile devices via the location API will offer a unique aspect
in the project given the small number of ISPs in REACH112. For the usage with this pilot there are two constraints: a) This API can be used for France Telecom/Orange customers only. b) The exposure of location information needs to be explicitly confirmed either in advance to the call or at the call time).
• Providing additional support for manual configuration and the usage of GeoIP is
recommended for those cases where location cannot be obtained otherwise. Netherlands
Figure 6 shows the setup of the pilot in the Netherlands with only mobile devices. The primary devices being used are Blackberry phones equipped with GPS. If possible then Nokia E71 phones will be used as well.
The implementation supports text, voice and video. The VSP/ASP proxy is provided by 4CTelecom and the same is true for the software running on the PSAPs operated by KLPD.
Recommendations:
For location information the GPS information will be used. The GPS receiver in the mobile
end devices will accessed by the SIP client software via a Application Programming Interface to obtain raw location data. This location data will then be encoded to fit into a PIDF-LO document to be delivered to the PSAP.
Additionally, there is the plan to convey cell-id information. This information can be
delivered in SIP based on the header fields defined in RFC 3455, such as P-Access-Network-Info header.
Manual configuration by users is in this pilot scenario not useful.
UK
Figure 7: UK Pilot Setup.
Figure 7 shows the setup of the UK pilot with devices from AUPIX based on laptops an Internet tablets. The end host software is available as a downloadable application. The VSP/ASP part is also provided by AUPIX based on various components, including Asterisk. The code for video and real-time text handling in Asterisk is in fact based by initial work from John Martin (Aupix)
This scenario is particularly interesting since all components are provided by a single party. Recommendations:
Regarding location information mechanisms are provided to allow users to manually enter
their location information.
Similarly with other pilot countries currently there is no implementation support for
To provide location information for the case the user has not manually provided location information in the case of fixed devices GeoIP should be provided. It is important that the IP addressed used for the lookup has to be the address obtained from the ISP rather than IP addresses obtained via IP tunnels or through VPNs.
Conclusion
The work on standardising IP-based emergency services is ongoing for many years already and most of the work has been completed already (including open source implementations that are available). While this progress gives hope there are also limitations that can be seen within the REACH-112 project. The challenges particularly concern two areas:
1. The need for interoperability is not visible within the pilot countries since only very
few parties participate in the communication exchange.
2. Availability of accurate location information from ISPs to support automatic location
configuration for IP-based devices
3. Widespread deployment of an emergency call routing infrastructure (using LoST)
The first challenge needs to be addressed in the following ways:
Support of end host roaming: If a large range of end devices are used in the different pilot
countries then interoperability problems between the end host and the VSP/ASP, and also along the entire call signalling chain become visible.
Roaming of end devices needs to be demonstrated to ensure that call routing functionality
is tested. For example, a call would then start at the device in Spain and would be directed to a VSP in the UK then this VSP would have to determine where to route the call next. If location-based routing is used then this UK-based VSP would have to route it to a PSAP in Spain. This requires different VSPs/ASPs to interact with PSAPs from other countries. Challenges #2 and #3 are based on the unclear division of responsibilities. While it is clear that someone has to provide emergency services, the number of incentives, given the liability and unclear funding models, is rather low. Regulators try not to dictate specific business models or solution approaches for emergency services and this is also true in general. However, it is uncertain whether the absence of specific guidance on how to share responsibilities will lead to a robust emergency services infrastructure for IP-based devices.
To explain the challenges we describe the most fundamental difference between the IP-based communication infrastructure and the circuit-switched environment: The Internet with the Internet Protocol (IP) provides a generic communication network where those providing the network infrastructure (ISP) to route packets are not necessarily providing the application layer services, such as voice, video and real-time communication (ASP/VSP). Since fewer parties are involved when deploying new services on the Internet the speed of innovation is faster.
Location Information Challenge
The ISP is still the entity that knows the end hosts location best and most reliable due to the physical proximity.
As explained earlier in this report location information is required for three purposes:
1) Dispatch of first responders
2) Emergency call routing
Depending on the emergency services infrastructure setup only very rough location information is required for item #2 “call routing” and item #3 only requires country-level precision. Location for first responders, however, requires accurate location information. Incentives have to be provided to the ISP to invest in infrastructure (such as location servers). Currently, these incentives do not seem to exist. In the REACH-112 project only in the French pilot region some amount of location information is available from the ISP, France Telecom. In all other regions work-a-rounds have to be created. Unfortunately, a large number of ISPs need to be involved and the project only has a single ISP as a project partner.
It is obvious that on this topic the consortium can do very few since the decisions should be taken at higher level by national or supranational telecommunications regulators. The reliability of the provision of location information can only be ensured via the full collaboration of ISPs. The EENA has already informed the European Commission and several national regulatory authorities about the need for incentives and/or appropriate regulation of the ISPs so that to ensure IP-access to emergency services.
Call Routing
In the area of call routing the situation is similar to location, namely unclear responsibilities. While there are clear benefits from allowing users to discover the emergency numbers used in a specific region automatically without user involvement and to have ways to discover the PSAP that is responsible for a specific region but it is not clear who’s responsibility it is to establish the server-side infrastructure. Those who benefit from the infrastructure, such as end devices and VSPs/ASPs, do not have the means to setup the infrastructure since they lack the data. The authoritative data is available with the emergency services organisations but they typically lack the funding to operate the infrastructure. When no infrastructure is available then there are no incentives for end devices and VSPs/ASPs to integrate the available code into their software; a chicken-and-egg problem.
To some extend the problem is less difficult to solve than the location problem since a single entity, such as an emergency services organisation, can offer the functionality to all entities within their region of influence (such as a country). This is not possible with location since every ISP has to provide location server support.
Summary
As a summary of this report we have to conclude that very little location support, no location-based call routing, and very basic identity support is available in the project overall. There are indications that future implementation efforts will improve availability of location via manual configuration, via GPS, and also (in case of the French pilot) from France Telecom, as an ISP. As such, there is still a fair amount of integration work that needs to be done to provide basic support for IP-based emergency calling in this Total Conversation project.
The solutions highlighted are adapted to the nature of the consortium and the general context that does not encourage or oblige the ISPs to implement the necessary components. It should however be noted that this reports proposes several ways to go forward with location, routing and caller-ID and clearly intends to improve the situation.
Appendix
Appendix A: Questionnaire for T5.4
Introduction
The task for the work in the task T5.4 is to develop a report that will serve as input to the implementation and deployment work in the different countries. The aim is to help every pilot country in implementing appropriate routing so that emergency calls get to the right PSAP and provide automatic caller-location so that dispatchers can intervene at the place of incident.
In order to accomplish this goal it is necessary to
(1) Investigate and chapter the different architectural choices with respect to the topics of caller-location, call-routing, and additional data.
(2) Analyse which partner serves which role in the different pilot locations. Once the role is identified it is relatively easy to identify what functionality has to be offered (among the choices being offered in the solution architecture).
The IP-based emergency services architectures differentiate a few roles that have different responsibilities for offering the complete end-to-end functionality. These roles are:
* Internet Service Provider (ISP)
* Voice Service Provider (VSP), or in a more generic form Application Service Provider (ASP) * Emergency Service Provider (that operates a PSAP) and vendors of equipment for those. * End Device
Note that a specific partner may provide multiple roles.
The terms are described in http://www.ietf.org/rfc/rfc5012.txt
You can also look at NENA Glossary:
http://www.nena.org/sites/default/files/NENA%2000-001_V12a%20July%202009.pdf
Questionnaire
1) Please indicate the roles you act in the different pilot countries
2) State-of-the-Art Analysis
For ISPs:
Location:
Please describe the Location Server technology you are using.
For what network technologies can the Location Server be used in the pilot project?
Are there technical/operational/legal/ethical constraints you are aware of with the usage of this Location Server for the pilot?
For VSPs/ASPs:(Focused on those offering service in the network including relay providers.)
Caller Identity:
Are you offering caller identity information using P-Asserted-Identity? Are you offering caller identity information using SIP Identity?
Additional Data:
Are you offering the ability to carry additional data (beyond location and identity) in SIP messages?
Location:
Do you offer your end users the possibility to manually enter their location when they subscribe to your service?
Are you offering the ability to attach, carry, and process location in SIP?
Do you implement SIP Location Conveyance according to
http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-02?
What location dereference protocols are implemented already (such as MLP, HELD Deref, HELD Identity, LOCSIP, SIP presence)?
Location-based Call Routing:
Are you offering any mechanisms to perform location-based call routing?
For Emergency Services Providers and vendors of emergency services providers:
Caller Identity:
How do you process incoming caller identity information? Do you support P-Asserted-Identity and SIP Identity?
What are your abilities for call-back? Are you able to differentiate the AoR and the GRUU for call-back?
Additional Data:
Do you have mechanisms to retrieve additional data and to display it?
Location:
How do you process and display incoming location information based on the SIP Location Conveyance standard?
What location dereference protocols are implemented already (such as MLP, HELD Deref, HELD Identity, LOCSIP, SIP presence)?
Are you able to process location updates during the call?
For End Device manufacturers and End Device Software Vendors/Developers:(Note: Responses need to be separated for different hardware and software platforms used in the pilot.)
Caller Identity:
What user authentication mechanisms do you implement? What SIP signalling security mechanisms do you implement?
Do you implement secure RTP (SRTP)? If yes, what key management do you offer?
Location:
Are GPS receivers available for the device?
What APIs exist to access location information within the device/platform? What are their capabilities and constraints? Have they been used already in practice?
What protocols for access to a Location Server are available in your device/platform?
Are you offering the ability to attach location in SIP according to
http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-02? In particular, are you able to send multi-party MIME bodies in your SIP messages and are you able to offer location updates during on ongoing session?
3) Anticipated Functionality
Considering the responses you provided in (2) what functionality, if already investigated, do you plan to offer/implement during the lifetime of the project? Please detail your plans and your wishes.
Appendix B: Implementation Example based on Skype
This section provides an example implementation based on a deployed VoIP software from Skype as used in the UK for emergency services. Skype users are given the possibility to manually enter their address, which helps in case of fixed phone deployments. This is shown in
Figure 8
(for a user with his or her home location in Finland) vs.Figure 9
for a user with his or her home location in the UK where emergency support is available.Figure 9: Home Location where emergency calling is supported.
Figure 10
shows the state machine as implemented on a Skype end point. The state machine determines how the Skype program executes instructions and therefore how it behaves.First, the emergency call needs to be detected based on the user entering the emergency dial strings. Skype uses the following pre-provisioned numbers (that can be modified using Skype's software update mechanism):
999 190 100 911 1999 1190 1100 1911 101 17 08 961 1101 117 108 1961 110 119 051 191 1110 1119 1051 1191 117 997 123 000 1117 1997 1123 1000 112 111 532 0112 1112 1111 1532 10112
This initial decision then leads to the emergency call procedures. The next decision is based on the user’s manually entered location information (“country from profile”) since the emergency call procedure is only available in the UK and not in other countries. Hence, a determination needs to be made about the user’s location. If the user did not provide information into their profile data the geo-IP process is started, which evaluates the current location of the user using the publically available data based on the IP address. Such a lookup is not accurate and can lead to errors particularly when the user is utilising various tunneling and mobility protocols. Still, for determining the country the user is currently located this method provides an additional data point.
Finally, the emergency call is executed and the call will be routed to a Skype gateway that then forwards the call to a BT based PSTN entity. Since the IP-based call is currently forwarded to the PSTN and no interworking with the existing real-time text system is provided only voice emergency calls are supported. Furthermore, lacking the protocol support for conveying location information to the stage-1 PSAP the available location information is not forwarded from Skype towards BT’s network.
Figure 10: State Machine for Processing Emergency Calls.
The following two figures show screen shots for emergency call situations as experienced by the user. Figure 11 shows a successful emergency call setup where the user is provided status information about the dynamically determined location information. Figure 12 on the other hand provides the user with information that he is currently located in the US and that emergency services support is not provided in the US. The user is, however, provided with the option to re-configure its country to proceed with the emergency call setup.
Figure 11: Successful Emergency Call
Appendix C: Pointers to Open Source Code
The following list includes a few valuable pointers to open source implementations and other tools.
Displaying PIDF-LOs in a Browser
http://held-location.sourceforge.net/held_js/pidflo.html
SIP based emergency services client implementation:
http://ecrit.labs.nic.at/cgi-bin/trac.cgi
Ecritdroid: This application adds support for ECRIT (Emergency Context Resolution with Internet Technologies) calling to your Android phone.
http://code.google.com/p/ecritdroid/
Asterisk Patch, which can be used to get location by value out of the (multipart) body of a SIP message:
http://ecrit.labs.nic.at/cgi-bin/trac.cgi/wiki/Asterisk-Patches
LoST client, server
http://ecrit.net.informatik.uni-goettingen.de/wp/
Internet Geolocation Toolkit (includes LIS discovery, and HELD client, DHCP client, LoST client)
http://igtk.sourceforge.net/index.html
LoST server, and client (including a Web and Ajax based client)
http://honamsun.cs.columbia.edu/index.html
Krakau LoST server & client. Also includes code for SIP stacks
Appendix D: Identity and Security Mechanisms
This section of the appendix illustrates the identity and security mechanisms in more detail.RFC 3325: P-Asserted-Identity (PAI)
The basic principle of PAI is based on a chain of trust. After authenticating the user, the VSP/ASP’s SIP proxy adds the P-Asserted-Identity header to the SIP message. This header carries the authenticated identity (SIP URI) of the user. The P-Asserted-Identity header is protected only in a hop-by-hop fashion between the SIP proxies along the path. The mechanism can only be used within a trust domain in which the SIP proxies and UAs communicate securely and the proxies are mutually trusted.
RFC 4474: SIP Identity
SIP Identity extends the PAI concept with a cryptographic identity assurance by sending SIP messages via an Authentication Service. The authentication service authenticates the user (e.g. by HTTP Digest) and verifies the SIP identity written into the From header of the SIP request. This is identical to the PAI scheme. Then, the authentication service authorises population of From header and digitally signs the message before forwarding it towards the ultimate recipient, using the Identity header. Within the forwarded SIP request the authentication service also provides a reference (HTTP URI) to its own domain certificate, using Identity-Info header.
The recipient of the SIP message (e.g. PSAP or the other communication partner) performs the following actions when it to verify the authenticated identity. First, it fetches and validates the certificate of the authentication service. Then, it verifies the signature of the SIP message and the identity of the user. Finally, it checks the value of signed Date header to protect against replay attacks.
The diagram below shows an example exchange graphically.
Figure 13: SIP Identity Example Exchange.
RFC 4568: Security Description
SDES is the simplest key distribution mechanism for establishing Secure Real-time Transport Protocol (SRTP) communication. Both endpoints announce their encryption keys in the Session Description Protocol (SDP) in
clear text. To provide protection against an attacker the SIP signaling communication needs to be confidentiality protected, for example using TLS.
A attribute used by SDES to announce their encryption key is "a=crypto" and describes the cryptographic suite, key parameters, and session parameters for the preceding unicast media line
The following figure illustrates the protocol exchange graphically:
Figure 14: SDES for SRTP.
RFC 5763: DTLS-SRTP
RFC 5763 specifies how to use SIP to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signalling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies.
Figure 15: DTLS-SRTP for SRTP.
The exchange can be described as follows: With the initial SIP signaling message a fingerprint of the certificate is exchanged between the two parties. Then, the DTLS handshake (with a special ciphersuite for establishing SRTP keying material) is performed along the media path. When the handshake completes the DTLS establishes the keying material for SRTP.
