FCC To Require 911 for VoIP
A rather important turn of events. http://www.newsfactor.com/story.xhtml?story_id=33733 - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/
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? Owen --On Thursday, April 28, 2005 4:45 PM +0000 "Fergie (Paul Ferguson)" <fergdawg@netzero.net> wrote:
A rather important turn of events.
http://www.newsfactor.com/story.xhtml?story_id=33733
- ferg
-- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/
-- If it wasn't crypto-signed, it probably didn't come from me.
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?
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?
I submit that I don't necessarily want my communications device or my location tracked at all times by the government. My point is not the need for location, but, that it is impractical to reliably implement the traditional 911 model for VOIP. The traditional 911 model depends on being able to make determination of at least a roughly correct 911 service provider based on connection point. (Cell site, telco central office, service location, etc.). None of these are available for many VOIP services. I think that if the focus were on delivering 911 service for fixed-location VOIP systems, it would make much more sense. However, the FCC, so far, does not seem to understand that this distinction is possible or relevant. Owen -- If it wasn't crypto-signed, it probably didn't come from me.
On 29-apr-2005, at 3:12, Owen DeLong wrote:
Maybe a satellite network that continuously transmit location beacon information which can be used to triangulate one's location would do the trick?
I submit that I don't necessarily want my communications device or my location tracked at all times by the government.
Well, adding a GPS receiver to a mobile VoIP phone doesn't automatically enable the government to track your location at all times.
My point is not the need for location, but, that it is impractical to reliably implement the traditional 911 model for VOIP.
I don't think VoIP is ever going to be as reliable as traditional telephony. But, neither are cell phones so that's not necessarily a disqualification.
The traditional 911 model depends on being able to make determination of at least a roughly correct 911 service provider based on connection point. (Cell site, telco central office, service location, etc.).
None of these are available for many VOIP services.
But there is absolutely no reason why this feature can't be added to VoIP. The first order of business is for the phone to know its location. For truely mobile devices this probably means GPS, but for less mobile devices I can imagine a networked location discovery protocol: a periodic broadcast or a DHCP option or some such. The phone can then tell the SIP server or whatever similar system it uses what its location is, and the SIP server can then make call routing decisions based on the phone's location for certain types of calls. For extra credit the paranoid among us may design a system where the SIP server only gets to hear the location when the user makes a call for which location information is required. Don't forget that we're in a transition period right now. Right now VoIP is mostly used as a last mile technology which is a huge waste of potential. All of this will get much more interesting when end-to- end VoIP calls become the norm.
On 29-apr-2005, at 3:12, Owen DeLong wrote:
Maybe a satellite network that continuously transmit location beacon information which can be used to triangulate one's location would do the trick?
Skype and public domain telefones dont know about location, nor will they ever learn. The only place where somebody could catch a 911 call is at a sip server. The sip server does not know about the INAIC in Newyork connecting me via tunnel from Germany. If they traced me they would find my IPv6 tunnel endpoint in Japan. Where to connect me? The Newyork police probably does not speak German. In Germany emergency calls are 110 not 911. If they connected me to Tokio police, they dont speak german either. The only way out for me to immagine is: A big wooden plate with big letters and with letters for blind people to touch, telling everybody how to dial emergency - or open the window and shout for help. That might be faster. Regards, Peter Dambier
I submit that I don't necessarily want my communications device or my location tracked at all times by the government.
Well, adding a GPS receiver to a mobile VoIP phone doesn't automatically enable the government to track your location at all times.
My point is not the need for location, but, that it is impractical to reliably implement the traditional 911 model for VOIP.
I don't think VoIP is ever going to be as reliable as traditional telephony. But, neither are cell phones so that's not necessarily a disqualification.
The traditional 911 model depends on being able to make determination of at least a roughly correct 911 service provider based on connection point. (Cell site, telco central office, service location, etc.).
None of these are available for many VOIP services.
But there is absolutely no reason why this feature can't be added to VoIP. The first order of business is for the phone to know its location. For truely mobile devices this probably means GPS, but for less mobile devices I can imagine a networked location discovery protocol: a periodic broadcast or a DHCP option or some such. The phone can then tell the SIP server or whatever similar system it uses what its location is, and the SIP server can then make call routing decisions based on the phone's location for certain types of calls.
For extra credit the paranoid among us may design a system where the SIP server only gets to hear the location when the user makes a call for which location information is required.
Don't forget that we're in a transition period right now. Right now VoIP is mostly used as a last mile technology which is a huge waste of potential. All of this will get much more interesting when end-to- end VoIP calls become the norm.
-- Peter und Karin Dambier Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-6252-599091 (O2 Genion) +1-360-226-6583-9738 (INAIC) peter@peter-dambier.de www.peter-dambier.de peter-dambier.site.voila.fr
* Peter & Karin Dambier:
Skype and public domain telefones dont know about location, nor will they ever learn.
The only place where somebody could catch a 911 call is at a sip server.
Come on, let's be a bit more creative. Location signalling over IP would be technically feasible. Your ISP does in fact know where your connection ends. Even it's just a tunnel, we eventually get down to layer 1 and bingo, the information is there. Of course, you don't get the necessary infrastructure for free, but you could use it for other services, too (like making identity theft a bit harder). There are privacy implications as well. But I'm not sure if an enticement to develop technical solutions is necessarily a bad thing.
On Thu, Apr 28, 2005 at 06:12:25PM -0700, Owen DeLong wrote:
I submit that I don't necessarily want my communications device or my location tracked at all times by the government. My point is not the need for location, but, that it is impractical to reliably implement the traditional 911 model for VOIP.
The traditional 911 model depends on being able to make determination of at least a roughly correct 911 service provider based on connection point. (Cell site, telco central office, service location, etc.).
None of these are available for many VOIP services. I think that if the focus were on delivering 911 service for fixed-location VOIP systems, it would make much more sense. However, the FCC, so far, does not seem to understand that this distinction is possible or relevant.
How about an anycast address implement(ed|able) by every network provider that would return a zipcode? $ telnet 10.255.255.254 Connected 33709 Disconnected. $ Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Sun, May 01, 2005 at 04:37:40PM +0000, Christopher L. Morrow wrote:
On Sun, 1 May 2005, Jay R. Ashworth wrote:
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
$ telnet 10.255.255.254 Connected 33709 Disconnected.
is there a unique zipcode in shanghai?
s/zipcode/unique geographic identifier on the rough order of a square mile/ Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Sun, 1 May 2005, Jay R. Ashworth wrote:
On Sun, May 01, 2005 at 04:37:40PM +0000, Christopher L. Morrow wrote:
On Sun, 1 May 2005, Jay R. Ashworth wrote:
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
$ telnet 10.255.255.254 Connected 33709 Disconnected.
is there a unique zipcode in shanghai?
s/zipcode/unique geographic identifier on the rough order of a square mile/
so, how does this work when you dial into the internet in (or use your DSL) in newark and the termination point for L3 is in Philadelphia? That seems like more than 1sq mile...
On May 1, 2005, at 11:53 AM, Christopher L. Morrow wrote:
so, how does this work when you dial into the internet in (or use your DSL) in newark and the termination point for L3 is in Philadelphia? That seems like more than 1sq mile...
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
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 :) -- Simon J. Lyall. | Very Busy | Mail: simon@darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.
On Mon, 2 May 2005, Simon Lyall wrote:
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?
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.
Speaking on Deep Background, the Press Secretary whispered:
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?
The PBX intercepts the call and uses special trunks to the PSAP; it also has to send data telling where the caller is. Here's one vendor: http://www.tonecommander.com/e911/How%20PBX%20ANI-LINK%20Works.htm -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
On Sun, 1 May 2005, David Lesher wrote:
Speaking on Deep Background, the Press Secretary whispered:
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?
The PBX intercepts the call and uses special trunks to the PSAP; it also has to send data telling where the caller is.
Here's one vendor: http://www.tonecommander.com/e911/How%20PBX%20ANI-LINK%20Works.htm
I think this scheme isn't going to work for VOIP. It relies on sending an ANI ID code which is setup in the E911 database with a more exact address. This is fine for a PBX with fixed phones. But it won't work for VOIP phones that could be anywhere now and somewhere else in 10 minutes, just by plugging them in to a new jack (and don't forget wifi phones). I think that VOIP phones will either ultimately be exempted, or required to have GPS (or triangulation or some other scheme), and the ability to send the GPS data to 911 services like cellphones. (And GPS doesn't work so well inside buildings, so I sort of doubt that its going to be very good as a locator for VOIP phones). I think that this is going to be a hard problem to solve. Or maybe we'll just start to see red phones next to the fire-alarm boxes. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Speaking on Deep Background, the Press Secretary whispered:
Here's one vendor: http://www.tonecommander.com/e911/How%20PBX%20ANI-LINK%20Works.htm
I think this scheme isn't going to work for VOIP.
Well, yea.. It's not.
I think that VOIP phones will either ultimately be exempted, or required to have GPS (or triangulation or some other scheme)
...that might work....sometimes...
Or maybe we'll just start to see red phones next to the fire-alarm boxes.
Alas, Gamewell fire boxes are all but dead. I don't know of any city still running them. Too bad, because it was a dirt-simple technology that Just Plain Worked. Looks like they were first deployed in the 1850's. Oops; NYC may still have some: http://www.forgotten-ny.com/STREET%20SCENES/Fire%20Alarms%20page/Alarms.html. And if http://plaws.net/fire/list.shtml is accurate, much of Mass. Hmm. OT explantion: There was a loop from the fire alarm office around the city {or fraction thereof}, through each box, and back to the office. One end had +130v {or so}; the other had -130. When you pulled a box, it split the loop in half, and grounded both halves in a sequence set on a spring-driven wheel ("3 2 5 PAUSE 3 2 5"). Think of that as the static IP address... At the office, 2 pen registers recorded the loop current. If two boxes (say 325 and 326) got pulled; 325 showed on the one chart, 326 on the other. We might have them still in wide use today if not for social changes; the false-alarm rate is many times higher than voice calls, and most departments gave up. I think there are NANOG lessons in there. Sometimes, a less than 100% optimal technology is good enough to outlast many a "newer better faster sexier" one... -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
On Sun, May 01, 2005 at 11:56:50PM -0400, David Lesher wrote:
Alas, Gamewell fire boxes are all but dead. I don't know of any city still running them. Too bad, because it was a dirt-simple technology that Just Plain Worked. Looks like they were first deployed in the 1850's.
I believe that there's a chance Westwood MA might still have some; they hadn't yanked them out yet by 1981 when I moved. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On May 1, 2005, at 11:44 AM, Jay R. Ashworth wrote:
On Sun, May 01, 2005 at 04:37:40PM +0000, Christopher L. Morrow wrote:
On Sun, 1 May 2005, Jay R. Ashworth wrote:
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
$ telnet 10.255.255.254 Connected 33709 Disconnected.
is there a unique zipcode in shanghai?
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. --Chris
On Sun, 1 May 2005, Chris Boyd wrote:
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.
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. -- The idle mind is the devil's playground
On Mon, 2 May 2005, Niels Bakker wrote:
* 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, always making it harder to stalk people :( darn you!
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
On May 1, 2005, at 6:43 PM, Sean Donelan wrote:
On Sun, 1 May 2005, Chris Boyd wrote:
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.
Why do you think the ISP knows anything more precise that the information they already give in the IN-ADDR.ARPA name?
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
On Mon, 2 May 2005, Chris Boyd wrote:
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.
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
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
Speaking on Deep Background, the Press Secretary whispered:
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
$ telnet 10.255.255.254 Connected 33709 Disconnected.
is there a unique zipcode in shanghai?
And even Zip+4 plus whatever they have now added to it will not meet Big Brother's requirement in the USA. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
On Sun, May 01, 2005 at 12:55:16PM -0400, David Lesher wrote:
Speaking on Deep Background, the Press Secretary whispered:
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
$ telnet 10.255.255.254 Connected 33709 Disconnected.
is there a unique zipcode in shanghai?
And even Zip+4 plus whatever they have now added to it will not meet Big Brother's requirement in the USA.
My issue, David, is not "where is the user exactly?", it's "which PSAP do I route to?". Something on the close order of a US ZIP<tm> Code is fine for that. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Sun, May 01, 2005 at 12:34:16PM -0400, Jay R. Ashworth wrote:
On Thu, Apr 28, 2005 at 06:12:25PM -0700, Owen DeLong wrote:
I submit that I don't necessarily want my communications device or my location tracked at all times by the government. My point is not the need for location, but, that it is impractical to reliably implement the traditional 911 model for VOIP.
The traditional 911 model depends on being able to make determination of at least a roughly correct 911 service provider based on connection point. (Cell site, telco central office, service location, etc.).
None of these are available for many VOIP services. I think that if the focus were on delivering 911 service for fixed-location VOIP systems, it would make much more sense. However, the FCC, so far, does not seem to understand that this distinction is possible or relevant.
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
$ telnet 10.255.255.254 Connected 33709 Disconnected. $
Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
If you can read this... thank a system administrator. Or two. --me
are you -REALLY- arguing for the return of "finger" ?? --bill
On Sun, May 01, 2005 at 04:38:10PM +0000, bmanning@vacation.karoshi.com wrote:
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
$ telnet 10.255.255.254 Connected 33709 Disconnected. $ are you -REALLY- arguing for the return of "finger" ??
I thought it was clear that I was not. 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). 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). I Am Not An ISP, Either, but this problem doesn't seem *all* that hard to solve to me... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
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).
The fact is: Skype is not interested where the client is located. They dont care. Well, Skype is not a defined standard but skype exits. There are lots of VoIP telefones out. Do you really want to call them back in to change the software? How about tunnels? Do we have to rewrite all tunnel software? How do I know where that client with ip 192.168.48.226 (me) is located? NAT behind NAT behind NAT, some packet-radio links and IPv6 over ISODE tunnels and all that via SNA through an IBM company link. No, my network is not really that complicated - but I thought of a hamradio friend who is working at the Georg-Von-Neumayer Antarctic Base. Or simply think of an IP-phone used aboard an airplane moving from Berlin to Abitibi-Témiscamingue (Québec). You cannot change all phones out there. You cannot change all public domain telephone software. All you can do is tell your sip office to direct any 911 or 112 calls directly to the Vatican. Hopefully they will have someone speaking the right language. Probably they will have the right personnel to deal with this kind of emergency. A buddhist monastery in Tibet would do nicely too. I think that is where the chinese route their calls :)
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).
I know where my DSLAM is located. That is some 80 KM or say 40 miles away from here. My link to that router is via PPPoE. There are some switches, bridges and dont ask me what other hardware in between. All that router knows is, I am one of 4K costumers connected. It does not care where I plug in my DSL modem as long as I stay some 150 KM around Frankfurt. There are some 60 police callcenters within this area. I had already the experience what it means when my GSM phone connects the wrong one of them. Of course whe have 112 service for cellurlar phones - only they wont help you if you need them. Just take the final two bytes of your ip and connect one of them randomly. You probably hit the right one. Why dialing a number? How about dialing an ip? 156.106.192.163 that is www.itu.int. They are the right one to ask about telephone regulations anyway. Cheers, Peter -- Peter und Karin Dambier Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-6252-599091 (O2 Genion) +1-360-226-6583-9738 (INAIC) peter@peter-dambier.de www.peter-dambier.de peter-dambier.site.voila.fr
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 ] On Tue, May 03, 2005 at 03:08:54PM +0100, Michael.Dillon@radianz.com wrote:
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 -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
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
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
$ telnet 10.255.255.254 Connected 33709 Disconnected. $
are you -REALLY- arguing for the return of "finger" ??
--bill
Not finger, but something like this could work. The server would return the physical address of the customer of record assigned that IP address. Kind of a uni-directional rwhois. The VoIP phone could connect to the anycast address and the ISP would lookup the allocation for the connecting IP and return a text string with the physical service location. The VoIP provider would be handed this location as part of the SIP registration (or other proprietary protocol used). In the event of a 911 call, the phone may check the location again to make sure the address of record/IP address hasn't changed before the registration expires. This would work fine for all customers except those who are mobile and served by a wireless base station which serves a large geographic region. If the provider was using some type of authentication before handing out IP addresses (I think most probably are) they could at least hand out the serving wireless AP location - some of the newer adjustable directional APs could even be modified to give an approximate relative location. I doubt that VoIP will be exempt from 911 regulations forever as much as I would like to see that. In lieu of the regulatory state going away, it makes sense to come up with a workable technology solution which is easy for IP providers and VoIP carriers to implement. VoIP providers could recommend IP transit players who support IP911 location services. Once it becomes a competitive advantage, the smart players will quickly adapt their systems to support IP911. I think we could do this within a couple of days with a few hours of coding. It isn't terribly difficult to setup. Those providers who don't use a centralized database for provisioning and IP allocation would definitely have a harder time, but it could still be done with some effort. The extra message elements of the SIP registration message could be used immediately once a standard is decided upon much as the TXT DNS records have been used for SPF records to fight email forgery. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin
Thus spake "Jay R. Ashworth" <jra@baylink.com>
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
First, there are plenty of examples of ZIP codes which are shared by multiple municipalities and thus PSAPs, but at least you'd get _someone_ who could probably help, even if they needed to transfer you to a different PSAP (assuming that's possible). Cell phones have the same problem when you're near city or county boundaries. Second, there are at least two states where you must provide location information _within X sqft_ to the PSAP. In the business world this means you need to know which part of which floor in which building the phone is located, ostensibly so the police/fire crews don't waste time searching for you if you're unable to speak. This is a nightmare for PBX admins, VoIP or not. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
On May 2, 2005, at 2:34 AM, Jay R. Ashworth wrote:
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
That would be fine in the US, and with some extension in Canada and a few other countries. No, I think the service would have to be built using some real definition of location (such as GPS) which is offered by the phone to the called party on user command, and the called party then refers that to some clearinghouse that gets it to the right emergency service office.
No to nit picks, but do zip codes share the same boundaries as municipalities?
How about an anycast address implement(ed|able) by every network provider that would return a zipcode?
$ telnet 10.255.255.254 Connected 33709 Disconnected. $
Cheers, -- jra
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net
Speaking on Deep Background, the Press Secretary whispered:
No to nit picks, but do zip codes share the same boundaries as municipalities?
ROTFL... Zip codes, municipalities, voting districts {we have many: State, ergo US Senate, US House, State House, County, City, precinct, school district, special assessment area, etc etc.}, telephone serving offices and geography ALL have unique boundaries. Sometime they share the same one -- CO boundaries and others usually follow say the Mississippi river, for example, but WAIT! The VM-MD boundary is high-water mark on the VA side. That island under 66? It has a foot bridge to VA but is in not part of same. And there are unique voting areas consisting of one house. (As I recall the story, it's in Hooterville for ALL except the school district, where it's in Podunk, since there is no road the school bus can take there...except through Podunk.) And let's not forget Point Roberts, WA. Oh, don't forget 'special' zip codes such as 44181 and my favorite for survey-takers -- 20505. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
On Sun, 1 May 2005, David Lesher wrote:
Oh, don't forget 'special' zip codes such as 44181 and my favorite for survey-takers -- 20505.
There are plenty like 44181, which is Cleveland, Ohio's airmail facility, that don't represent physical locations. Others are 44101, the Cleveland main post office, and 44072, "Novelty, Ohio" (which doesn't exist as a municipality, only a post office; it's part of the town of South Russell). Most ZIP codes do map to geographic locations, though, and even ones like this aren't too hard to map if you know the area (44181=SW Cleveland by the airport, 44101=downtown, 44072=South Russell). -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / sjsobol@JustThe.net / PGP: 0xE3AE35ED "The wisdom of a fool won't set you free" --New Order, "Bizarre Love Triangle"
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)
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?
Even more interesting, what if you have a heart attack and a helpful local picks up your phone and dials 060? Normally, in Puerto Vallarta this is the emergency number. Or perhaps the helpful person is a tourist who knows that the worldwide standard for cellular emergency numbers is to dial 112. What will happen then with your mobile SIP phone? --Michael Dillon P.S. in England, you would dial 999. In Australia you would dial 000. And in Russia you would dial 01 for the fire service, 02 for police or 03 for ambulance.
Slashdotted http://yro.slashdot.org/article.pl?sid=05/04/28/1938239 A few good arguments there On 4/28/05, Fergie (Paul Ferguson) <fergdawg@netzero.net> wrote:
A rather important turn of events.
http://www.newsfactor.com/story.xhtml?story_id=33733
- ferg
-- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/
-- Mark Owen
participants (26)
-
Alex Rubenstein -
bmanning＠vacation.karoshi.com -
Chris Boyd -
Christopher L. Morrow -
David Lesher -
Dean Anderson -
Eric Brunner-Williams in Portland Maine -
Fergie (Paul Ferguson) -
Florian Weimer -
Fred Baker -
Iljitsch van Beijnum -
Jay R. Ashworth -
John Levine -
John Todd -
JP Velders -
Mark Owen -
Michael.Dillon＠radianz.com -
Niels Bakker -
Owen DeLong -
Peter & Karin Dambier -
Randy Bush -
Robert Boyle -
Sean Donelan -
Simon Lyall -
Stephen Sprunk -
Steven J. Sobol