VoIP Service Providers Must Offer 911 Service
April 5th, 2005 | Miscellaneous
News – VoIP Service Providers Must Offer 9-1-1, Says CRTC : Marketnews.ca
It’s about time that the CRTC came out with this decision. I’ve been considering VoIP, but will not get it until I have 911 service with it. Ninety days from now, VoIP services will have to offer the 911 Service.


This is extremely short-sighted.
I agree strongly that not depending on IP telephony for emergency service access is crucial. But governments using their authority to force a technological blunder – which is what this is – makes no sense at all.
The blunder results from a complete lack of understanding of what IP telephony is, and is not. It is a communication protocol. It is not a “service”, despite the fact that various people charge money to give you what you could provide for yourself.
As such, no VoIP “service provider” has the means to provide routing to location-specific emergency services. Nor does it make any sense to force them to create and maintain such a thing, or conversely to force the ILECs to provide new access to their hopelessly backward 911 networks.
What can accomplish the needed function is a general set of protocols that understand the layered nature of the Internet and its underlying facilities.
The current 911 networks assume a fixed relationship between a network-layer address (phone number) and the physical-layer address. Cellular telephony broke this assumption long ago, but the workaround was to fake a network-layer address from the currently-active cell tower. Kludge though it is, it works because the owner of the layer-1 address (the tower) and the owner of the layer-3 address (the TN) are the same or cooperating entities.
Internet telephony, where there are actually more layers, breaks all of those assumptions, and none of the kludges currently in use or proposed overcomes this. In this case, the TN, which originally represented a layer 3 address, is replaced by the IP address as a layer-3 entity, but this is determined by local network topology rather than being permanently owned by the user. Now we have an address that is more like a DNS entry, but more dynamic even than traditional fixed hosts.
The point is that there is now no permanent – or even reasonably fixed – relationship between the user’s logical address and his physical location. The only component of the network (if any) that can reliably determine the location of the caller’s device is the device itself.
There are a few ways to do this. The most obvious (and worst) is to have the user himself tell the device where it is. I don’t think I need to say what’s wrong with this, do I? Next, and least complex, is to have a physical-location request protocol, requesting, as a broadcast similar to rarp or bootp, the physical location of the nearest router, bridge, hub, access point or whatever that knows where it is. Whether the responding device gets its information from human input, DHCP, GPS, or cell-tower triangulation is immaterial, so long as it can respond.
Since all the routers I have seen in the last several years have upgradable firmware, giving them this capability should be pretty straightforward and economical. The “PSAP” can then be nothing more than a URL returned from a public server that maps location information to the service boundaries of all the responders in the area.
Of course, this is little more than a public-safety application of a general service that can be supported by more commercial concerns. Since the question generally is “Given that I am at point (x,y), where’s the nearest ?” where X can be “gas station”, “restaurant”, “hotel”, or whatever, plenty of commercial concerns would be happy to pay to advertise their locations in this way.
So I agree that you should not depend on 911 services from your VoIP phone, but I hope that you don’t really mean that you won’t begin to enjoy the cost and other benefits of IP calling until you can get it all in one place. And I really hope that you don’t continue to think that the new service should be built like the old.