Re: Vonage Changes 911 to Opt-Out

In article , TELECOM Digest Editor noted:

[TELECOM Digest Editor's Note: I wonder how this scheme would work ...

Executive summary: Not very well.

any calls to 911 from a VOIP get intercepted by the broadband ISP > who is handling the connection.

And if there is a VPN/tunnel involved? say, to a head-end halfway across the country. "OOPS!" applies.

The IP address in use (and its physical address) get transmitted > 'like ANI' to the local police. The 'ANI-like' information passed > along (from wherever) to the PSAP identifies it as a VOIP from > address (registered with the ISP for the IP street address.)

So now, the local ISP, who is *NOT* the VoIP provider, is responsible for handling the 911 type call? What if they don't have VoIP equipment? Or are you proposing a 'surcharge' on basic ISP service, to pay for the extra cost of having VoIP support there, "just in case" the customer decides to do VoIP at a later date? Or is the ISP just supposed to 'eat' this 'cost of doing business'?

Are you proposing that each ISP run a "Carnivore"-type tap on all customer traffic, being prepared to 'transparently' intercept any SIP session set-up that invokes 911? Or that all existing VoIP "phone" software be modified to give 'special' handling to 911 calls? If the latter, how does the phone know _which_ ISP -- as in "what IP address to use" is handling the connection? How does it pick up that information? Especially if it is a 'mobile' device? Do we now have to specify: IP/address, netmask, gateway, *and* '911 VoIP' server when setting up a network connection?

Am I correct in my assumption that most stationary > computers with broadband stay in the same place and they are almost > always on the same IP address as well?

No. The last part is an invalid assumption. Some ISPs that forbid servers routinely re-assign DHCP addresses. As in "every few hours", to "every few days". Some even do it based on the amount of inbound traffic.

Yes, they can track down "who was using what address, when" at any given point in time in the (relatively recent) past.

*NO*, the information is not necessarily readily available in real-time. (Sometimes the latency is days, sometimes it is into the next month.)

The info doesn't _have_ to be delayed, It's a matter of how the existing infrastructure is designed. And whether the infrastructure is 'theirs', or 'leased' from an infrastructure provider. Where data is delayed, things could be redesigned so that data was available in real-time. *BUT* there are costs associated with doing that. In some cases, _big_ costs. Which "somebody" has to pay for. Whereupon the question becomes "who pays?"

If a provider is *NOT* offering VoIP services, why should *they* incur the costs for supporting VoIP 'emergency call' infrastructure?

The "easy" solution is a two-part one.

Part 1: The VoIP 'head end' tracks the 'most recently used' IP address for each customer. _EVERY_TIME_ the customer IP address changes, the phone goes *out*of*service* with a notice that the customer must update their "calling location".

Possibly with an added hook that if the phone has been 'off line' for some non-trivial period, that when it goes back 'on line', the customer is queried (in an automated fashion) to confirm that they are still at "thus and such location"; where "thus and such" is the previously specified location for the phone.

Part 2: The VoIP 'head end' maps the various 'calling locations' to the appropriate PSAP, upon need.

Add an option for the customer to intentionally _not_ specify his location, but which also totally disables 911 calling. This protects his 'privacy' at the expense of his safety, but it is the customer's decision.

The last part of the puzzle is ensuring that the customer is aware that the "location information" provided is used for "emergency calls" and that deliberately providing FALSE information can (and probably _will_) lead to criminal prosecution if emergency services are directed to an incorrect location as a result of said false information. There is already existing enforcement mechanism for this

-- "filing a false police report", etc.

I know in my instance I have been 24.xxx.xxx.xxx for however long, > here at the same street address, etc. Can't those two items (IP and > street address) often as not be matched? PAT]

An ISP knows the physical location where _their_service_ is delivered to. They have *NO*WAY* of knowing "if", or "how much" of a network lies behind the point to which they deliver service. For an extreme case, that customer could have a satellite 'uplink' dish, which is down-linked half-way around the world.

Now, silly as it sounds, something that "works right" 98% of the time, but "invisibly" does the _wrong_ thing the other 2% of the time is

*worse* that something that 'almost never' gets it right.

An essential element of a 911 'locator' system it that it either gives a 'right answer', or it gives *NO* answer. "Wrong answers" are simply not acceptable -- wrong answers (a) delay the response to the location where it is needed, *and* (b) tie up resources that may be needed to respond to a 'real' emergency.

[TELECOM Digest Editor's Note: Well ... regards your first point, of a 'tunnel' to some remote place, do you remember when 'Foreign Exchange Service' (or FX) was quite common? You picked up a phone with FX on it and got dial tone 'locally' from the distant city? There were two reasons people got that service: one, they wanted their customers to have a 'local' (in customer's community) office to deal with for customer's convenience in reaching them. There is a company here in Independence now which has an FX line from Tulsa, OK.

When I worked for Amoco in the 1960's, our (admittedly huge) PBX allowed me to dial various three digit codes and get local dial tone from those places. I don't know if telco offers those any longer; they seem to prefer 'virtual' FX now. I know in Amoco's instance, one of the three digit 'tie-line codes' on the PBX produced dialtone from _London, England_ and another tie-line brought back dial tone from somewhere in the middle east, Kuwait I think.

The other reason companies used those FX tie lines was because someone had calculated the expense involved in long distance calling to those points, and _despite_ the expenses for 'mileage' and other charges associated with telco running that wire, they calculated it was still _cheaper_ for the company to use them instead of the best laid WATS plans or direct dialing plans. I guess if your business involves calling London or Kuwait a dozen or more times daily, and talking for hours on end, it may make better sense economically to have an FX tie-line, even if the cost of that line is a 'mere' ten-thousand dollars per month or so from telco.

So, one day in my office, a masked man breaks in, and waving his gun around, he announces, "I am going to rob all the cashiers and rape all the men". I say, 'oh no you are not!' and rush to my phone to call the police. But in my haste I grab up the FX tie-line phone and dial '911' -- (or as Bonomi would say, ooops) ... -- and wind up lodging my complaint with the police in Kalamazoo and Timbuck also. If a _real man_ does not know where his broadband service is out of, then he has no business calling the police to start with, does he? PAT]