In article <telecom24.220.11@telecom-digest.org>, Dean M.
<cjmebox-telecomdigest@yahoo.com> wrote:
> 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
> Robert Bonomi <bonomi@host122.r-bonomi.com> wrote in message
> news:telecom24.218.11@telecom-digest.org:
>> In article <telecom24.215.13@telecom-digest.org>, Robert Bonomi
>> <bonomi@host122.r-bonomi.com> wrote:
>> [[.. 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 ..]]
Robert Bonomi (bonomi@host122.r-bonomi.com)