[80507] in North American Network Operators' Group
Re: FCC To Require 911 for VoIP
daemon@ATHENA.MIT.EDU (John Todd)
Mon May 2 11:34:07 2005
In-Reply-To: <8B4FB9DE-747E-4B6A-8A09-CEF3AC68C19C@muada.com>
Date: Mon, 2 May 2005 01:50:54 -0700
To: nanog@merit.edu
From: John Todd <jtodd@loligo.com>
Errors-To: owner-nanog@merit.edu
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)
