Or have the server return the SNMP location information. The network operator would then be able to configure locally meaningful information.
--Chris
In the dial up case, you could/should know the originating number, so location can be determined from that.
In the DSL case, the ATM PVC can often be mapped back to a DSLAM port and thus a wire pair with a known termination.
Whether the provisioning and management systems are up to the task of providing this information quickly enough for emergency services, I don't know.
--Chris
No to nit picks, but do zip codes share the same boundaries as municipalities?
Why do you think the ISP knows anything more precise that the information
they already give in the IN-ADDR.ARPA name? Let's encode the ZIP Code
in the router DNS name ... (well, someone had to suggest using DNS as
the universal database solution eventually). And more importantly why
do you think it is actually useful enough to solve the problem?
If the location of the ISP's router was good enough to identify the
location of the user, the marketing people would have already solved the
problem.
For everyone who thinks they have discovered the final, universal solution
to any problem, they probably don't understand the entire problem.
If you actually want to solve the problem, you need to get at least 5 to
10 different databases/protocols/systems to inter-operate on a world-wide
level with an embedded base of hundreds of millions. There are
years/decades of FCC/PUC rulings prohibiting those systems from
inter-operating. And finally, who is going to pay for the changes.
* sean@donelan.com (Sean Donelan) [Mon 02 May 2005, 01:45 CEST]:
Why do you think the ISP knows anything more precise that the information they already give in the IN-ADDR.ARPA name? Let's encode the ZIP Code in the router DNS name ... (well, someone had to suggest using DNS as the universal database solution eventually).
Well that's fun... whenever you see a phone number you can get its
physical location. Doesn't sound like such a good idea to me,
privacy-wise.
-- Niels.
This speculation is fun but my question is how do people do this now? I
would assume that many people on this list work for large companies with
multiple sites and a single phone network spanning them all.
When somebody in the office picks up a phone and dials EXTERNAL-911 how
do the emergancy services know they are in one building rather than another
office across town?
Anyway, everybody knows this whole thing with locating phones for
emergancy calls is just a smokescreen for the CIA/NSA/FBI/UN/RIAA being
able to track us 24x7 everywhere 
Perhaps they don't.
PBX's and nationwide tie-lines have been a problem for E911/ALI services
since the beginning.
PSAP call takers are trained to get/confirm the caller's location and the
location of the emergency because people don't always call from the
location of the emergency. And there has always been a problem some
callers don't know, or are mistaken, about their current location. Or
refer to their location by a different name, such as the Atlanta Olympic
Park bombing where the caller and the pay phone records referred to
a physical location which didn't exist in the police department's
dispatching computers even though the physical location was on television
every day of the Atlanta Olympics.
The most common way people "solve" this today is by installing at least
one ordinary POTS line in each building, and the PBX uses least-cost
routing to route E911 calls to the local line. VOIP ATA's can do the same
thing by including a POTS jack on the ATA and connecting 9-1-1 calls to
the local POTS line.
There are more advanced methods, but they all involve someone updating
some database whenever a telephone is moved. They all have the exact same
problem of assuming a person will keep the database with their current
location up to date. People forget, or make mistakes, and its very
difficult to discover the mistakes in advance.
Life is complicated.
s/zipcode/unique geographic identifier on the rough order of a square
mile/Or have the server return the SNMP location information. The network
operator would then be able to configure locally meaningful
information.
i figured that folk were welcome to smoke whatever they wanted on
the weekend. but the hot air is getting pretty thick, and it's
almost 28c here, and the tradewinds are too light today <whine>.
so, do tell me the oh so simple and deployable solution that will
cover just how i use voip
o asterisk server in seattle with gateways to
- a few voip/pstn gateways
- peer asterisks in nigeria, ...
- and a direct pstn gateway or two
o fixed sip phones about 10 miles from seattle but tunnel to
seattle
o fixed sip phones in hawaii about 2500 miles away from seattle
and they tunnel
o same for los angeles
o soft phones on various laptops, some tunnel some don't, but
they all meet the pstn via (not necessarily at) seattle
o 802.11 sip phones with which we wander into all sorts of 802.11
hot spots around the globe, but they meet the pstn via (not
necessarily at) seattle
o ...
when you have a scheme simple enough to be described in a screen of
ascii, and which lets me have control of my data privacy (it's none
of the fascists' business where i am unless i want to tell them),
i'll listen. otherwise, i suggest you have some studying to do
rather than wasting your cred or trying to clue trogs such as jay.
randy
niels, always making it harder to stalk people 
darn you!
At 12:55 AM +0200 on 4/29/05, Iljitsch van Beijnum 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)
Date: Mon, 2 May 2005 01:46:50 +0200
From: Niels Bakker <niels=nanog@bakker.net>
To: nanog@merit.edu
Subject: Re: FCC To Require 911 for VoIP
* sean@donelan.com (Sean Donelan) [Mon 02 May 2005, 01:45 CEST]:
>Why do you think the ISP knows anything more precise that the
>information they already give in the IN-ADDR.ARPA name? Let's encode
>the ZIP Code in the router DNS name ... (well, someone had to suggest
>using DNS as the universal database solution eventually).
Well that's fun... whenever you see a phone number you can get its
physical location. Doesn't sound like such a good idea to me,
privacy-wise.
Looking it up in the phonebook (be it digital or otherwise) is much
the same, although you won't have any control over being listed or
not. I even recall that the Dutch Phonebook on a CD-ROM had unlisted
numbers on it, so you could get the address associated with it...
The same goes for DSL IP's with some DSL telco's... They allow for
automated billing by sites through the phone bill (opt-out ofcourse)
or even provide the sought geolocation info (Klipping). The latter is
mostly used by devious marketing agencies ofcourse, and some of the
ISP's have explicitly taken care of the opt-out for all their
subscribers...
In short, technologies exist, how they're used is mostly up to us. How
to prevent abuse is definitely up to us (techies or whatever ;D)...
Rome wasn't built in a day...
(though some argue it was destroyed in one ;D)
-- Niels.
Regards,
JP Velders
Hardly.
Sorry--Made an ambigous "network operator" reference there. I meant the operator of the LAN, not the ISP.
This would be a similar responsibility to what PBX admins already have to do, as others have pointed out. Less clueful and/or home users would need to have dire warnings printed in the doc and displayed on screen about configuring the correct location information, but that can easily be done in new equipment and updates to older software.
Adding the information as a DHCP option sounds interesting. Maybe bears further discussion....?
--Chris
You mean like the dozens of dire warnings Vonage has in their product to
repeatedly remind less clueful and home users to register the correct
location information for their phone. And yet, Vonage is still being
sued by an State Attorney General.
Who is the family going to sue when Dad forgets to configure the correct
location information for the home VOIP phone?
Large companies, hotels, universities, hospitals, etc have professional
staff (or hire a company) to keep their phone systems working and the
information up to date. Just like home PC's, most residential users do
not have either an IT staff or a PBX staff. Most home users don't want
to be system managers or PBX managers. They just want their phone to
work, including all the stuff they get from their POTS line today.
You mean like the dozens of dire warnings Vonage has in their product
to repeatedly remind less clueful and home users to register the
correct location information for their phone. And yet, Vonage is
still being sued by an State Attorney General.
I believe that the incident that provoked this chain of events
involved a Vonage customer who had provided the correct location data,
dialed 911, and was connected to a recording that said "go away and
call us from a real phone."
The problem is that Vonage doesn't want to spend the money to provide
real E911 so instead they have this half-assed service that calls the
phone on the receptionist's desk at the PSAP. If a VoIP provider
wants to provide real E911, there is no technical bar to their doing
so, using E911 trunks from the CLECs who provide their connection to
the phone network. VoIP provider Packet8 makes a selling point that
they provide real E911 (at extra cost, about the same as the mandatory
911 fee on a POTS line) in most of the U.S. now.
Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.com
To expand: the problem is the VoIP client being able to *furnish* an
approximation of where it is, to permit the selection of the proper
Public Safety Access Point (or equivalent).
VoIP clients can't provide such information unless they
KNOW this information in the first place. The only somewhat
reliable way to know this information is for the hardware
device containing the VoIP client to also contain a
GPS system or some equivalent (cell triangulation, querying
cell transmitters, triangulate RTT measurements to known IP addresses)
That is a big problem.
If each end-router supplied that data, through *some* easily queriable
protocol, such clients could retrieve it, and then decide (in some
fashion) where to send Emergency Services Request calls (or furnish it
to their carrier, if they have one, for similar purposes).
And if I am using a laptop communicating with IP over Bluetooth
to a GPRS cellphone in order to establish an IPv6 tunnel to
my colocated server in Germany, then which router should my
VoIP client query? My home DSL router in London? The router
at the colo in Germany? The GPRS cell transmitter? The Japanese
IP gateway router between the cell network and the Internet?
This is not a simple technical problem. There are human factors
included as well, for instance, should there be a separate
specification for different classes of device so that a device
with a screen greater than 320 x 320 pixels should ask the user
to confirm (or override their address)? A quick knee-jerk fix
will only create new problems and muddy the waters further if
it is presented as the ultimate solution.
--Michael Dillon
[ questionably OT for NANOG; subject line changed; killfile at your
discretion ]
> To expand: the problem is the VoIP client being able to *furnish* an
> approximation of where it is, to permit the selection of the proper
> Public Safety Access Point (or equivalent).VoIP clients can't provide such information unless they
KNOW this information in the first place. The only somewhat
reliable way to know this information is for the hardware
device containing the VoIP client to also contain a
GPS system or some equivalent (cell triangulation, querying
cell transmitters, triangulate RTT measurements to known IP addresses)
That is a big problem.
Except that the problem can be approached on several scales, more of
which seem useful than might be obvious at first glance.
I was trying to imply this in some of my earlier postings, with
apparently questionable luck; I'll try to be more explicit here.
> If each end-router supplied that data, through *some* easily queriable
> protocol, such clients could retrieve it, and then decide (in some
> fashion) where to send Emergency Services Request calls (or furnish it
> to their carrier, if they have one, for similar purposes).And if I am using a laptop communicating with IP over Bluetooth
to a GPRS cellphone in order to establish an IPv6 tunnel to
my colocated server in Germany, then which router should my
VoIP client query? My home DSL router in London? The router
at the colo in Germany? The GPRS cell transmitter? The Japanese
IP gateway router between the cell network and the Internet?
Well, first, let us define more closely the problem we're trying to
solve.
We want to know, for a given physical location of an IP end node device
(a PC, laptop, WiFi phone, or some other object which has an IP stack
and enough processor and hardware to do VoIP) to which Public Safety
Access Point (or the logical equivalent of that outside the US)
emergency services ("9-1-1") calls should be sent.
A second level of information which might need to be provided is the
exact physical location of that end-node device; this level of service
is commonly referred to as "E-911", and requires Automatic Location
Identification (which is provided by a database dip on normal PSTN
lines).
The final expansion on this issue is called E-ALI, and concerns making
sure the PSAP can identify the physical location of a specific
end-station when it lives behind a PBX: *which* phone at MIT is calling
for help (MIT, for those who don't know this, is mind-bogglingly big.
I mean, you might think it's a long way to the corner chemist...).
These problems are listed in order of ascending difficulty to solve
well, and the stack may be attacked from either end.
There may be regulatory requirements (although I don't believe there
currently are) upon commercial players in the Internet Telephony space,
but those corporations do not make up the total space, and the problem
is worthwhile of solution regardless of the fact that some people may
{make money,not lose lawsuits} due to it's solution; this is the
approach I've been trying to take in my comments to date.
This is not a simple technical problem. There are human factors
included as well, for instance, should there be a separate
specification for different classes of device so that a device
with a screen greater than 320 x 320 pixels should ask the user
to confirm (or override their address)? A quick knee-jerk fix
will only create new problems and muddy the waters further if
it is presented as the ultimate solution.
No, it's actually *three* separate technical problems, some of the
solutions to which overlap.
To go back, though, to your first question, and my first solution:
And if I am using a laptop communicating with IP over Bluetooth
to a GPRS cellphone in order to establish an IPv6 tunnel to
my colocated server in Germany, then which router should my
VoIP client query? My home DSL router in London? The router
at the colo in Germany? The GPRS cell transmitter? The Japanese
IP gateway router between the cell network and the Internet?
I'm trying to solve the "which PSAP" problem.
There's a lower level "which protocol" problem involved, but the answer
to your question, IMHO, is to provide a mechanism whereby the end
device can make *some* sort of query (ethernet broadcast, GPRS ping,
whatever it might be -- IP level would be nice, but not necessary), to
the nearest network device to it, which device would tell it whom to
call, based on some hardware and path identifier attached to the
incoming request by the network itself.
In the instance you gave, you're after the physical location of the
*cellphone*. The Bluetooth layer is clearly unuseful, so we ignore it.
The next thing is IP. The phone is acting like either an ethernet
adapter, or a cell-modem. In either case, it is (virtually) the
laptop's network adapter, and it can (possibly via emulation) either
acquire or send IP packets with lower-layer identifiers that will
denote which tower the phone was talking to. Some piece of equipment
at the carrier can then use that to do a short lookup to a locally
maintained tabel (this data does not change all that rapidly, TTBOMK),
and return an appropriate reply. This clearly requires bridging
levels, but that's not that big a deal, is it?
That was a bit of a rough example, as I'm sure you intended, but while
other topologies are easier to manage, the point remains that there
*is* some way to acquire *some* useful information of about the
location of an endpoint, to a granularity good enough for the "which
PSAP" problem, which can be designed for (and into) the necessary
equipment which provides that topology.
Certainly some are more difficult than others; some types of gear
replacement-cycle slower than others.
But it seemed to *me* that the point of the whole thread either was, or
should have been, to figure out the solution before the FCC (who are
guaranteed to screw it up) did it for us, no? That end doesn't seem to
me to be served by the tenor of and contributions to the thread as I
saw it.
Cheers,
-- jra
I'm trying to solve the "which PSAP" problem.
In that case, consider this. If I am in Tokyo and
you route me to a Tokyo PSAP, I won't be able to
communicate because I don't speak Japanese. But if
I were in Moscow and you route me to a Moscow PSAP,
there is no problem; I can communicate there. So although
I am normally a resident of London England, it may make
more sense to route me to a U.S. PSAP when I am in Tokyo
because that way I can explain the problem. Of course this
does me no good if the emergency services in various
countries are not linked up in some way.
But! Aren't we talking about *IP* telephony here?
Isn't it logical to include IP network connectivity
to E911 centers in the solution. And if all E911 centers
have resilient Internet connections to handle incoming
VoIP emergency calls, then why can't they also use this
to communicate with other nations. Presumably Japan
could designate a center with people speaking English,
Chinese, Russian and Korean to handle referrals from
other countries.
There have been incidents where people used their mobile
phone to call a relative at home, and that relative contacted
the emergency services. This has been reported several times
in the British media and one case involved an emergency
situation in Australia.
Even this seemingly simple routing problem has to be
solved in a larger context.
But it seemed to *me* that the point of the whole thread either was, or
should have been, to figure out the solution before the FCC (who are
guaranteed to screw it up) did it for us, no?
If the FCC decide to solve the problem through consultation
then they will probably come up with the best solution
that is currently possible. However, consultation only works
when people with domain knowledge are willing to share that
knowledge with the FCC.
I know that people from the FCC, FBI, NSA and other agencies
attend NANOG meetings. How often do people from the NANOG world
attend FCC meetings to present possible solutions to issues?
--Michael Dillon