|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: FCC To Require 911 for VoIP
At 12:55 AM +0200 on 4/29/05, Iljitsch van Beijnum wrote: On 29-apr-2005, at 0:17, Owen DeLong wrote:Someone should show them some of the 802.11 based "cellular-like" SIP phones and ask them how exactly they plan to get good geolocation data for 911 on those and the soft-phone in my laptop.You're absolutely right. I submit that if the US government wants location information for VoIP 911 calls, they should create an infrastructure that allows people to determine their location. Your example shows that this infrastructure should also be available outside the US. Maybe a satellite network that continuously transmit location beacon information which can be used to triangulate one's location would do the trick?Who exactly will I be talking to when I dial 911 from an internet cafe in Puerto Vallarta through my Virgina VOIP account with a California Billing address? For better information, and people who are truly working on this (versus armchair quarterbacking, like me): http://www.ietf-ecrit.org/cgi-bin/ecrit.cgi http://www.nena.org/VoIP_IP/index.htm Now: On with the wild opinions, speculation, and exclamation points. My biggest concern regarding VoIP-based E911 (a.k.a.: emergency services) delivery is the lack of an easily-available database which maps lat/lon/alt to a PSAP number that can be reached by a normal VoIP->PSTN gateway. I know where (almost) all my end users are. While I appreciate the mobile nature of IP endpoints, it is still the case that as an iPBX administrator or ITSP, I have fairly high certainty of where the physical location of each endpoint is, or I can extract those data from the user via a list of methods which makes use of the VoIP platform painful or threatening if they do not provide accurate geographic location. Political or technical solutions exist to enforce the accuracy of these data, to varying degrees of success. However, I am not incented to collect, store, or use these data at all today since it is meaningless unless I have a PSTN gateway to an emergency-services capable POTS line in the same location as the VoIP endpoint. My PBXs or IP gateways can ultimately make/take calls to the PSTN, so why can't I hand off emergency calls even though I know the exact location of the endpoint? The reason is because I have no access to the data that maps physical location to a PSAP, so handing off the call to the PSTN will result in failure except for those locations that have an overlap of physical POTS gateway devices and VoIP handsets in close proximity. Even if I were to have 100% accurate locations of devices down to a meter, it would be useless in the event of an emergency call if I didn't have an POTS connections within a few dozen meters of that user which could carry the call to the correct PSAP. This database exists in fractured form - it HAS to exist, since every state uses it to currently map POTS lines to PSAPs(1). I expect however that the data is spread out across a million little niches of turf, where each niche is controlled by one of a variety of unpleasant bureaucrats who probably don't even work directly for the PSAPs. I expect wrestling these data out of these regional fiefdoms will take some time unless some Federal agency kicks down some doors, at least here in the US. Perhaps in other nations this may be easier, and a multinational coordinated effort would be the best way to approach this with a "single query" method that works regardless of country (brr... starts to smell like ENUM...) Here's my quick opinion summary on what really is the underlying database missing link for a workable VoIP E911 solution in the United States (though certainly other nations have the same problem.) I think it is required that we have a location-to-PSAP number database that is: 0: network-based - IP as the basic transport, specifically on the public Internet 1: fast - has to provide responses in <2 seconds 2: real-time - while caching might be _possible_, it should be possible/preferred to do lookups in real-time 3: authenticated - I encourage authenticated lookups, so that registration is required (I'll leave the reasons as an exercise to the reader.) 4: distributed - the system must be able to withstand massive DoS attempts and natural volume spikes 5: multiply-connected - getting there via "public" IP is essential, but perhaps I'd like to get there via (say) GPRS in a way that is completely alternate to public IP paths 6: accurate - must provide correct data in a way that is equal or greater accuracy than current PSTN methods (assuming I give it correct lat/lon/alt of device) 7: not free - I don't mind paying! As long as it's not >1.5x what I pay now per line, or not more than $6/mo for a small PBX, OR I'm willing to pay $xx on a per-lookup basis (2) 8: standards-based - XML would be ideal, of course, and NENA already has some basics for this in place 9: open - no proprietary or patent-encumbered protocols, schemas, or methods 10: supported - provide some stone-cold stupid Perl script examples, or Python, or C libraries plus example configs; we can all benefit from more examples in our lives. 11: public - anyone can purchase lookup rights if they can pay the fee 12: easy - signup and daily use should be easily implemented, at least on the database lookup subscription process; no harder than "normal" electronic commerce signup 13: effective - the returned number should be an e.164 (normal telephone) number which leads to the same operators as if the call was placed from a POTS phone (this perhaps is the most difficult part, depending on locale. (4)) What I've really just described here is a Federally-funded, easy-to-use version of the services similar to what Intrado and TCS currently provide, if one is to judge from their website and press release comments. While I appreciate that they are providing good service right now, there is no possible way I can sign up my 4 user PBX in my home, or even my 20 user PBX at work with their service - everything is geared towards the "big guys" and "service providers" of various ilk(5). I'm also uncertain about the private nature of such a project: if US-based VoIP ITSPs are going to have E911 stuffed down their throats by the FCC on a Federal level, then I'd be in favor of seeing this "common good" be provided by the Federal Government on an at-cost or subsidized basis. Besides, getting a common platform across all states would probably only be possible with a Federal effort. (That's the last time you'll hear me in favor of Federal expansion...) JT Footers: (1) some of the data is bad, I'm sure, but VoIP would be no worse than POTS, and the data purity problem of PSAP mapping for the last 1% of the data is not the problem we're trying to solve here. (2) I'm not firmly convinced of this billing method. Another method which I appreciate greatly is the "billing the access provider" method, where the last hop of the transit network pays a tax, which covers both emergency services and Universal Service Fund costs. However, I'll assume it's easier to start paying for a new service that I've never had than it is to start paying for something that was previously free or untaxed. (3) I'm not addressing the biggest technical issue, which is what gets everyone panting here: how do we know where the devices _are_? That's the topic for another discussion, but I actually don't think it's the most difficult or problematic discussion, since "we" (the engineering/networking/design community) control the specifications and implementations for the most part, versus the political and economic realities of PSAP regulation and funding which would make most of us have an aneurysm just to think about. I look at the (literally) dozens of PBX platforms that I've installed and only in about 5% of the installed line base are the handsets "mobile", and of those, almost all are softphones. I don't expect most of my softphone users will try to dial 911 on their laptop when they're on the road. WiFi SIP phones of course will change this expectation model, but there are working groups tackling this technical problem (see the geopriv working group as an example: http://www.ietf.org/html.charters/geopriv-charter.html) Even VoIP providers can solve much of this problem through political or technical methods with a manual process for update, though certainly having a "hard" location-based method extracted from the device is the preferred final arrangement. I don't want to make it sound like location determination is a minor problem: it is a huge problem. However: I think it's a huge problem only for a subset of the VoIP-using population, and the problem of knowing where to send the call needs to be answered first, and is relevant for 100% of the user population, so that's the part of the elephant I'd put in the pot first. (4) Many 911 centers don't have an e.164 number that reaches them in the same way that other emergency calls reach them. This is the big problem to overcome, since this last point describes implementation actions, and not simply data transfer in a vacuum. Even if the call is gatewayed correctly, this connection method may not always provide accurate on-screen location of the caller, and perhaps non-accurate callback information either. However, it would provide _something_. I believe that this could be in production far sooner than any of the other proposals that I've followed, though it is not a permanent solution, and would possibly have zero cost to the PSAPs for incremental effectiveness. (5) Things are changing rapidly in this market, so if someone knows of such a database that fits my criteria or is even close, and is generally affordable to businesses who are hyper-sensitive to recurring monthly costs, let me know. Other resources: NENA: IP Specific Discussion: http://www.nena9-1-1.org/9-1-1TechStandards/TechInfoDocs/NENATIDIPPSAPIF.pdf XML Data Exchange Format: http://www.nena.org/9-1-1TechStandards/Standards_PDF/NENA%2002-010.PDF VOIPSEC Mailing list (not directly related, but close) http://voipsa.org/pipermail/voipsec_voipsa.org/2005-April/subject.html#start (see "VoIP For Free??" thread, and specifically Brian Rosen's comments) |