FCC To Require 911 for VoIP

Mon May 2 08:50:54 UTC 2005

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.
>
>>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?
>
>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?

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)