You are essentially relegating every IP communications device to a 911 caller first and then any other type of communications (and only after the customer jumps through a number of hoops remembering to drop cookie crums so she can find her way back should she need to change something). I agree with you that this solution would probably be a quicker one to implement, but I don't think it would ever be considered satisfactory. Any 911 solution needs to be more transparent to the user than what you describe. Therefore, it probably has to be a technology solution (naturally any technology will be implementing policy!).
Your points about GPS and its relatives are well taken. Sadly, even though I consider your suggested solution inadequate, I have nothing better to suggest at this time ... Frankly I think it's too soon to suggest anything in this field, except that users of VoIP should be
*warned* that their service doesn't include 911. I would hazard the guess that most anyone who at some point in time needs to dial 911 from a VoIP phone, also has a cell available to do that job. Maybe for now we should only mandate that anyone who dials 911 from a VoIP phone should be given an announement to the effect "use your cell phone to make this call!"Dean
> [[.. munch ..]]
>> 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.
> [[.. munch ..]]
>> 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?
> It still exists today. Either as actual hard-wire to the remote CO (with
> a *BIG* one-time install charge, plus a moderate monthly) or, more > commonly,
> as a 'virtualized' service.
>> 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 politce in Kalamazoo and Timbuck also.
> Funny thing about FX lines, the telco _does_ know where the end of
> that line is. In your scenario, if you called 911 on that line, while
> the call _might_ go to the PSAP for locale where the switch is, the
> *location* *information* given to the police would be accurate.
> The accurate POTS parallel to the VoIP 'location' problems is the
> situation where there the telephone company service terminates at a
> PBX, and there are 'extensions' *BEHIND* the PBX to 'remote'
> locations. The *telco* _does_not_ _know_ anything about what goes on
> behind the PBX, and can only report where =their= service terminates.
> Which leads to the telco providing "wrong answers" to the 911 center.
> Cell phone systems have the same problem. The point at which a
> cell-phone call is connected to the PSTN is _not_ necessarily anywhere
> "close" to the tower which is handling the call. AND, that tower may
> be in a different 'jurisdiction' than the one where the person
> _placing_ the call is.
> A review of actual 911 history will show that *both* of the above
> scenarios were real problems in the early days of 'enhanced 911'. In
> the first case, governmental regulations were issued that require PBX
> owners to keep the PSAP 'location database' updated with the
> *actual*location* of all extensions that are behind that PBX.
> The cell-phone problem was considerably thornier -- and went through a
> number of steps:
> 1) cell phone links were *blocked* from calling 911 because "wrong data"
> was being displayed.
> 2) 911 calling was re-enabled when it became possible to return "no
> data" for those calls, instead of "wrong data" as to the location.
> 3) enhanced technology was mandated/deployed _on_the_cell_ network
> (*NOT* a part of the PSTN) that allowed fairly precise _caller_
> location determination 'on the fly'.
> 4) Where that technology was deployed, "good" (as in valid/accurate)
> 'location' data was then passed to the PSAP, instead of the prior > "no data".
> Dealing with VoIP involves much 'harder' problems than either of the
> above. To have the phone itself figure out "where it is" it has to
> have straight-line inputs from a minimum of two sources that it (a)
> knows where are, *and* (b) can take directional bearings on, OR a
> minimum of three sources that it can measure signal timing from. AND
> it has to be able to reliably derive that information at _any_
> location where the phone might be used.
> Using GPS is not a viable option -- 'indoor' reception is too poor.
> And the 300 ft accuracy is problematic. That last can be remedied by
> using DGPS, but that makes for a more expensive receiver. And doesn't
> do anything for the fundamental reception problems. The only solution
> for _that_ problem is to replace the transmitters with more powerful
> ones. Which is *awfully* expensive.
> LORAN-C might be a possibility, it carries indoors fairly well. BUT,
> it operates at 100kHz, which requires a non-trivial antenna for decent
> reception. *AND* it is only accurate to around 1/4 of a mile. "within
> several blocks" is simply not good enough for emergency-service
> dispatch.
> One is left with the possibility of direction-finding on local
> commercial stations. This could possibly be made to work, but
> requires access to a fairly massive database of *precise* transmitter
> locations. The equipment required to get a precision bearing on a
> transmitter isn't cheap, either. (If you're 10 miles from the
> transmitter, a _one_degree_ uncertainty in direction makes for +/-
> nearly a thousand feet in your location.)
> "Technology" is not the solution for this, "Policy" is. The two-part
> solution described previously does get the job done.
> Administratively, not via technology. All the burden (what burden
> there is) is on the VoIP provider and the actual 'owner' of the phone.
> And it probably takes 30 days, or _less_, to get it into 'production'
> status at any/every major VoIP provider.
>> 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]
> I stand "corrected". PAT _has_ come up with the ultimate solution.
> With his proposed 'local ISP'-based handling of emergency calls,
> *NOBODY* but the person who set up the VoIP service -- and knows where
> it connects through -- is allowed to use the phone in an emergency.
> "So what" if that person is unconscious on the floor from a heart
> attack, and the VoIP phone is the only one available, and someone who
> _doesn't_know_ that it is an IP phone, or where it connects through,
> cannot call for help.
> No need to even consider the situation of the person who takes "their"
> phone to a friends place, because they may have to make some lengthy
> toll calls, and simply _don't_know_ where _that_ broadband service is
> out of. After all, that could _never_ happen, could it?
> [TELECOM Digest Editor's Note: No, of course it _could_ happen, but
> what are the odds? Figure the 'odds' based on these things: the VOIP
> phone is on the road somewhere, not in its usual place. The subscriber
> has an incident and needs help. Not only does _he_ not know where he
> is at (or is not in a position to speak to the police) and the _phone_
> does not know where it is at. There is no landline available, and/or
> the person in trouble not only cannot get to the (landline) phone, or
> whatever. My personal reaction is _all those factors taken in combin-
> ation_ are so negligible as to not matter at all. As soon as any
> one of those conditions does not exist, the problem is dealt with. We
> do not live in the town of 'Perfect' as the commercial for Walgreens
> states. And you know what, Robert? Even if magically, every one of
> those rare obstacles were overcome tonight, magically, _YOU_ would
> come up with still more obstacles, wouldn't you? And after all, why
> not? You swear on a stack of tech reference manuals that _nothing_ can
> be done to tame the 'wild west' lifestyle of the internet. I have
> never yet seen you ever admit to any possible cure for the nastiness
> on the internet. It just has to be the way it is, because Robert has
> all the (non) answers. Why shouldn't any problems with E-911 and VOIP
> turn out the same way. You don't really want to see any answers to
> any of those problems, do you? And rather than do _something_ and
> bring some small amount of relief to the vast majority of users, there
> will still be some iota-percentage we are unable to help, given our
> understandings. So better to do nothing at all, right Robert? I
> thought your thinking was absolutely ludicrous where spam/scam/viri
> was concerned, but people have seen nothing at all until you explain
> the 'hassles' (as you see them) with 911 and VOIP. PAT]