I certainly should have typed "VoIP communications device" not "IP". Funny what a couple of characters can do ... I stand by the rest of my spiel: any emergency services solution needs to be transparent to the user. Among other reasons, VoIP is a personal service more like cell phones than PBX extensions. And we should be making progress, not regressing to old and tedious solutions (even if they work:-). We'll probably be better served by not mandating anything vis-a-vis emergency services and VoIP until we can do it right (at least on a national level).
Dean
>> 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).
> How do you figure that? In my proposal, *ONLY* the VoIP functionality is
> ffected by the need to 'drop cookie crumbs".
>> 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!).
> This solution is *exactly* what PBX admins have to do when they move
> hard-wired phones behind their PBX. It is in real-world use today. > It works.
> If you want to be your own phone service provider, there are
> responsibilities that go along with that task.
> Doing VoIP *does* mean that you are the 'last mile' phone service
> provider -- The VoIP provider is providing the 'port' on the switch,
> at their premises. It is *your* responsibility to provide the
> connection to that point.
>> 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 ..]]