Interestingly the ability to SMS 999 now exists, if you are registered.
For a long time the way to contact emergency services is by calling 999 (or 112) from a landline phone. The location of the installation is automatically made available by the telco (mainly BT). Even with the next step - mobile - there is some basic cell location data passed. But ultimately this is still just a normal phone call.
But times change - and I have had some rather interesting discussions with the people that work on this sort of thing (NICC) and agree with national and international agreement on the way things should work.
The discussions (to which I was invited, thanks), started off rather badly. I have to find out where they have got to now and see if sanity has prevailed. I'll post more if I find out more. But when I left them, the discussions where around handling location data on VoIP calls.
This rather loses the plot a tad - the plans all centred around having ways to have emergency services get end point IP details and have a way to translate that to a location via APIs in to the ISPs. I.e. they wanted some proper and quick way to turn an IP address in to a real geographic address. They were really dead against user device supplied location data?!
This has all sorts of problems:-
- Technical - it is not always possible to turn an IP in to a location, and even where it is, there is no way to know that it is the end of the line as anyone can operate tunnels and relays and phone systems that mean the "IP you can see" is not the end of the link to the person talking.
- Even where it may be possible, it is not always possible in one step (which is what they want, and even want very low time scales of a few seconds). I.e. one may turn an IP in to a BT DSL circuit ID, which means asking BT where that is. Or to another IP because it is a tunnel service.
- Even that only makes sense where the services for such are within ISPs and not individuals or companies who will not be providing some API to allow tracing IPs through corporate or domestic networks.
- CGNAT makes that even harder - exact timing, IP and ports, both ends, makes it hard to trace the original link.
- If an ISP has to get the location from someone else, another ISP for a tunnel endpoint - why would other ISP provide an API for that (as opposed to an API for emergency services use)?
- What if the user is not even in the UK, or *any* step is via an ISP not in the UK even though the user is?
- Why would an ISP not providing VoIP/telephony, and so not subject to the legislation on 999 location data, want to comply?
- If such an API existed, even at a basic level, for common major ISPs even those working through CGNAT, you create all sorts of illegal and legal issues. Hackers get location from IP. Advertisers want location from IP. Copyright holders want location from IP. Before you know it, the existence of an API means people will demand access to it for god knows what.
- There are a lot of cases where the IP is mobile and tracing it then gets complex - wifi or mobile data.
We should not even be talking of VoIP calls to 999. It is almost never that a VoIP platform using some data link does not have either a "normal mobile" or a "physical landline" behind it which can be used for the 999 anyway. It does happen - at home I have glass and no phone lines at all - but we would call from a mobile if needed. So what we need is for any attempt to use 999 to revert to such old fashioned means. Some VoIP/DECT phones do this - having a landline connection as well, and calling 999 does not use VoIP but uses landline. Any VoIP hosted on a mobile phone device can (and should) revert 999 to the underlying GSM network.
But with so many people using mobile and wifi and data rather than conventional landline, we need something new. This is especially new when you have newer means to connect and communicate.
What do we need?
Well, obviously traditional landline and mobile calling 999 need to work as you expect. The last resort. That is in place and works fine.
But what we need is a proper published IP (i.e. data not phone call) based API for emergency services, and it needs to allow end user reporting of location, voice over IP, video, images, etc. It may even be sensible for personal health monitoring wrist bands and the like to be passed to the emergency services in real time.
But this needs not only an API but the back end to get all of that data to the services that need it. It would be massively helpful to have real time accurate GPS reporting to police. It would be massively helpful for Ambulance service call handling people to have access to video and health monitoring data. It would help anyone responding to an RTA to have video and image data in advance.
Ironically, such ancillary information can currently be gleaned from twitter and Facebook faster than any official API!
Once the API is defined (and please, not defined by committee) we need standard iPhone and Android apps that just use it as well as PC/Mac apps.
Then the whole issue of VoIP calling 999 will be moot.
I can FaceTime my mum - why can I not FaceTime an a hospital?
0118 999 881 999 119 725..............3
ReplyDeleteI sincerely hope they don't support FaceTime. I can just imagine it now - I'm sorry, you can't call an ambulance because you don't own an Apple device.
ReplyDelete> I can FaceTime my mum - why can I not FaceTime an a hospital?
ReplyDeleteYour approach of having an emergency services API to which others can integrate is broadly similar to my thinking about emergency service obligations at over the top communications services, but I am not sure about mandating support by the emergency services of particular proprietary over the top communications services.
I like the idea in principle, since many hundreds of thousands of users are using these services.
If it is "just" that the emergency services expose the API and it is up to the service provider / software developer to integrate, then no problem.
If, however, it is a case of development by the emergency services (well, PSAP software providers, perhaps) to integrate with FaceTime, then it might come down to whether the onus is on the service provider to fund the integration, which would mean that the public purse is not used to fund the integration of proprietary services.
It might be interesting to explore whether this should be a voluntary thing or a mandatory thing.
On the one hand, it could be voluntary, since having emergency services access could be a desirable feature for such devices, as a selling point, and so handled on a market-led basis like funding for any other feature.
However, could that mean some people are unable to call the emergency services, necessitating a mandatory integration? Perhaps limited to obligations on providers with more than 10,000 users in the UK, akin to maintenance of interception capability.
Or, at least, my previous proposal, which is that the emergency services are funded to develop their own apps for the most common platforms (all major desktop OSs and mobile OSs), and users are free to choose to install those if they so wish.
I agree, FaceTime is not the answer, but video, voice, text, image, etc, in a way that is common and platforms are encouraged to have built in apps to work with a standard API... Or, as you say, emergency services develop own apps. It would be good for one standard for global use though, and may need a GPS to service centre mapping.
ReplyDelete> a GPS to service centre mapping
DeleteAbsolutely. And some clever integration with a real-time voice translation system would be an added benefit.
When one lives in a part of the country with poor mobile coverage, there tend to be plenty of scenarios where one has wifi but no mobile phone signal and no access to a landline. My local (unmanned) community Hall is one, and my university out of hours is another.
ReplyDelete