In article <telecom24.214.5@telecom-digest.org>, 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]
Robert Bonomi (bonomi@host122.r-bonomi.com)