VoIP and Emergency Calls - Where is the Caller?
(7 votes, average: 5 out of 5)
Loading ...Background
OFCOM (the UK telecommunications regulator) recently mandated that any VoIP Service Provider that allows end users to make calls to the PSTN must also provide access to the Emergency Services number.
They also mandated that “to the extent technically feasible” the Emergency Handling Agencies (EHAs) must be supplied with the location of the caller. This speeds up the emergency response, and also helps in those cases where the caller is unable to provide their location.
This is already done by the existing PSTN and mobile telephone companies and is not a particularly difficult problem for them as they control all elements of the telephony service. However for VoIP the problem is substantially more difficult - VoIP users can connect to their VoIP service provider over any internet connection, from anywhere in the world.
In some parts of the world the customer is required to notify their VoIP service provider of their location. This isn’t feasible however for users who regularly use their VoIP service away from home, e.g. with a WiFi VoIP handset. Also, if this information is out of date then the consequences can be tragic as seen recently in Canada where the initial ambulance dispatch went to the customer’s previous address, 2500 miles away from where it was needed.
Proposed Solution
The proposed architecture currently being developed by NICC (the UK telecoms industry standards group) is to have the VoIP Providers, the Internet Service Providers, and the Access Network Providers all cooperate to provide location information in real-time.
The VoIP provider will know what the end user’s public IP address is, but they don’t know where it is. When they receive an emergency call they’ll pass the call over the PSTN to the EHA, but at the same time they’ll also send a separate message (using TCP/IP) containing that end user IP address.
The EHA will maintain a database derived from BGP4 real-time routeing data that maps from IP addresses to ISPs. Once they know the ISP, they’ll send the ISP’s “Location Information Service” a HELD protocol request containing the IP address as the lookup key (see IETF Draft geopriv-http-location-delivery). The response from the ISP is an XML document in PIDF-LO format (see RFC4119 and RFC5139) which contains either a “civic address” or a “geodetic location” (i.e. latitude/longitude).
A further complication is that many types of internet access run over a separate Access Network Service which is independent of the ISP. Most ADSL in the UK, for example, is provided using BT Wholesale’s “IPStream” access product which is then packaged up by hundreds of different ISPs.
In these networks it’s common for individual users not to be tied to a specific access line. Hence the Access Network needs to tell the ISP exactly which line is being used. In some cases that might be sufficient for the ISP to determine the address, but in many cases it’s expected that the ISP LIS will need to proxy the HELD request onwards to the Access Network where they should have the most accurate and up-to-date address information.
The diagram below is a simplified representation of how it’s expected to work.
Policy Issues
In my opinion the biggest problem with the architecture at the moment is that neither the ISPs nor the Access Networks actually operate Location Information Services. Partly this is because the relevant standards are still in development, but particularly because as yet there’s no regulation requiring them to do so.
All of the OFCOM regulatory changes so far have been focussed on the VoIP providers, without sufficient acknowledgment of the fact that it’s only the ISPs and the Access Networks that really know where any particular IP connection is being made from. However Ofcom are committed to revisit the regulations for the location issue very early next year, once technical standards (national and international) are clarified.
In my opinion most ISPs are at the moment completely unaware that they might need to do anything, and I hope that this article will stimulate further involvement from the ISP industry. I believe that regulation requiring ISPs and Access Networks to operate Location Information Services is inevitable and it would be better to work now towards a practical solution than to be stuck with an unworkable one later.
It should be noted that the implementation costs for this will be significant, and ISPs looking to recover their costs might start looking at how they could sell-on their customers’ location information to third parties. The potential market for location-based advertising is enormous, but so too are the privacy implications.
Ray Bellis - Senior Researcher
June 24th, 2008 at 9:31 am
I think you also need to look at layering issues at the ISP.
Firstly, not every ISP operates their own ASN. I suppose these fall into two broad categories: small ISPs operating their own network, and large ISPs operating to varying extents ‘off the back of’ another ISP. I see you have “ISP” and “Access Network Provider” but there may be more layers than that (think about, e.g. Datastream in the way).
Secondly, ISP information about customer geographic location can be poor, even if you reach the ISP in a contractual relationship with the customer. There are a large number of reasons for failure cases. A few years ago I ran an exercise for a DSL ISP with relatively good data to see whether premises receiving ADSL service were on-net or near-on-net for a given fiber company; around 20% of the data was unusable, and that was (as I say) in an ISP with good data. ISPs typically care only about retaining a billing address that works, and a means of identifying a circuit so it can be fixed. When end users move (as per the Canadian case) within the same local exchange area, the ISP may not even know. There are then other “poor cases” e.g. customers with a small number of NAT devices and geographically diverse networks, or simply customers with large buildings or campuses where the extra information given is worth little. Whilst it’s often possible from this to get a physical address from ISP data, I would argue that it is frequently not possible to do so automatedly and reliably.
Thirdly, the assumption that ASNs will in one hop map to an ISP is flawed at a technical level. Consider, for instance, the ISP who has “gone multihomed” taking a subnet of the upstream’s PA space with him. This subnet may not be announced globally. This raises the prospect of emergency services getting a false positive and going to visit the ‘customer’ concerned which is in fact an ISP.
Quite apart from this, I am struggling to see why all this additional cost and complexity should be the ISP’s problem in the first place. The customer of the ISP has bought a service to move packets, not to locate him. If there is additional cost, it should be met by either the customer using the VOIP service or the VOIP provider. Given GPS chipsets are a matter of dollars, why not solve the problem properly and mandate that VOIP handsets have a GPS chipset built in (or failing that ask for address confirmation when IP address changes)?
June 24th, 2008 at 3:55 pm
A few points in response to Alex’s post:
1. “Request steering”. Perhaps one of the most difficult things for the interim architecture that NICC is defining is the step of identifying the correct ISP to send the location request to. It should be noted that this “method” of query is called On-Behalf-Of (or OBO) in the IETF Geopriv working group where the location service protocols are being defined. The IETF working group (ECRIT) that is defining the emergency model for VoIP doesn’t actually recommend OBO - it requires the calling device itself to query the LIS in the access network and provide the location information in the VoIP call signaling. Location can be passed by value or as a URI which can be dereferenced toward the LIS later. This is where all networks need to get to in time since it’s properly scalable and supports international “roaming” scenarios as well. However - not to make perfect the enemy of good - the NICC model addresses the short term issue where VoIP clients are not location aware, don’t know how to query a LIS, and do not know how to convey location information in the call signalling.It only works for the subset of VoIP providers that are UK-based and the scenarios where the call also originates in a participating UK ISP; but that’s a good chunk of user population taken care of, and an excellent start. So - OBO is the most pragmatic approach in the short term and until VoIP providers make their clients “ECRIT compliant”.
2. “Unreliable data” - The fact is that the biggest challenge for the operators of LIS is, in fact, the gathering, grooming, and provisioning of the location data. This isn’t a new problem. When the FCC imposed the requirement on US cellular operators to provide location with the calls, their operational data was similarly patchy. Certainly they needed to know the approximate location of their base stations - but this information was neither systematically maintained nor kept to the degree of accuracy necessary to support their new obligations. After eight years of operating under this mandate, this information is now of almost universally high quality. It is correct to distinguish between ISPs and the broadband infrastructure providers. The ISP may need to field the request (being responsible for the subscriber with the target IP address) but the LIS operated by the ISP will almost certainly need to proxy the request to the broadband network operator - probably providing the L2TP tunnel identifier as the key for a typical DSL service. The LIS operated by the infrastructure operator will be the one that needs to correlate that identity with, ultimately, the DSLAM termination and associated civic street address. And - yes - if the data is not accurate today, there is now an imperative to manage it such that it is (just as it has had to be for decades to get accurate location associated with emergency POTS calls). The Internet is replacing the PSTN - that is inevitable. As such, it shouldn’t surprise us if Internet access begins to attract similar regulatory requirements and impositions to support social services just as the PSTN did over time. Internet access is no longer a fad or a recreational facility - it has become an essential service.
3. “It’s not fair” - It’s understandable that ISPs should feel “put upon” if told they must provide a location service when it’s the VoIP provider that is “using it” (I’ll leave aside the fact that most ISPs offer a VoIP service bundle anyway). On the other hand, nobody actually wants to have an obligation to support emergency services. Telephone operators, given the choice, wouldn’t have provided free emergency calls. It’s a cost and it’s a responsibility. As such, history suggests, it won’t happen without a legislative imperative. It should also be noted that ISPs aren’t being “picked on” when it comes to singling them out as the location source. The need is driven by the physics of the situation. The network provider, by definition, has the most direct proximity to the user and is in a position to make an informed judgement of their location; a VoIP provider simply is not. GPS is not a solution - devices cannot be assumed to have it (see the OBO comment with respect to the interim solution) and, in any case, it is not a high yield technology. It does not work in a great many environments and situations. It gives a nice high accuracy when it works (though no civic addresses which are really desired for emergency dispatch) but it does not have a reliable fallback - when it doesn’t work you get nothing. Network-based location determination has to be there to provide the one hundred percent yield and device-capability independent certainty that is required for emergency services. Finally, consider the ECRIT architecture (and the NENA i3 architecture). These models don’t actually require a VoIP provider to mediate in an emergency call. The device uses a network service (LoST) to determine the URI of the emergency service and can initiate a SIP call directly to it. IMO this is how all emergency calling will eventually happen. Using VoIP providers that may have no national presence whatsoever to mediate emergency calls does not make sense and is, ultimately, unnecessary. Direct calling will bring the emergency service back to being a completely local jurisdictional procedure again - as it is for PSTN emergency calls and eliminate all the uncertain variables associated with involving arbitrary VoIP services and protocols. In this scenario, it is apparent that there is no VoIP provider; there is only the ISP and access network to provide the necessary caller location infrastructure.
Finally, I think ISPs and access providers should have cost-recovery provided to offset the cost of providing a location service. There’s certainly no point in looking at foreign VoIP providers as a way to impose tariffs to underwrite the cost of providing emergency services. Indeed, a location service is of value to broadband subscribers for a great many applications. Beyond providing it “free” for emergency services, ISPs should be able to offer the option of open access to the service for some incremental subscription fee (think of it as a supplementary service like calling-line-display or message bank in a POTS context).
Cheers,
Martin
June 26th, 2008 at 8:01 am
[…] this article by Ray Bellis about the ongoing work in the UK to develop an emergency services architecture and […]
July 10th, 2008 at 8:43 am
Perhaps the biggest thing this falls down on is those customers with WAN or VPN networks behind a public internet connection. We provide a number of VOIP-ISDN Gateways and internal SIP PBX Solutions to corporates and more often than not the end user has a Private WAN or VPN that would hide the true location of the caller with this method.
July 10th, 2008 at 3:16 pm
There are certainly no easy answers here. Although it may be pragmatic to assume that the majority of public IP addresses currently map to a physical location, just how solid is that assumption for the future? You could argue that IPv6 should negate the original need for IP NAT (i.e. lack of public address space) but NAT has other security benefits and I imagine the industry will not rush to give every device a public IP. Wireless technology such as WiMAX could well make it even harder to pinpoint a public IP to a civic address. One small and relatively easy step would be to have VoIP services registered with the EMA as being IP based services so that the dispatcher is at least aware that there is some level of uncertainty about the geographic location. As far as I’m aware this is not the case today.
July 30th, 2008 at 3:03 am
VPN - Yes, that’s one of the reasons that OBO (by the emergency services) is not recommended by the IETF. The IETF/ECRIT recommendations are that the calling device gets the location from the serving network. For a WAN, this means that the location comes from either a location service in the WAN or from the first physical public access that the caller’s site is using. I will note that OBO within the WAN may still be appropriate - an IP PABX in a WAN may still invoke the location service accurately “on behalf of” IP voice terminals within that WAN.
With specific reference to VPN, the implication is also that the device should get the location from the location service in the *physically* connected network - not from the location service out in the virtual network connection. As a corollary, the location service in the VPN should recognize that the device is so attached and refuse to provide location information if it can’t reliably determine it.
As stated previously, the NICC model is by no means representative of an appropriate end game solution. It is, however, an appropriate middle step in that it establishes the all important notion of a location service in the access networks and manages to cover a significant part of the current (yes, temporarily) status quo into the bargain.