On Tue, 2008-05-06 at 05:57 -0400, SIP wrote: > The comments in that article, which, by the way, is not reachable at the > URL you provided (you left off an l : > http://www.cbc.ca/canada/calgary/story/2008/05/05/rethinking-voip.html) > show that people really still have no grasp on the technology used for > VoIP or the difficulties in providing E911 service. > > Some of the questions/suggestions given were things like: > > -Why can't we put GPS into VoIP phones like we do in cell phones? > - Be like AT&T and the minute a phone changes locations (changes IPs), > lock it out completely until the customer provides current location > information or verifies he's at the old location. > > Neither of which are terribly effective. GPS is rather unreliable > indoors, and if you're truly on the move, having your phone stop working > every time you switch APs until you reconfirm your location (which you > may not even know) is, perhaps, a worthless solution. > > The overall problem lies in the way people view VoIP as a replacement > for telephones. Skype is VoIP, but its dependence on the computer puts > it into a class of VoIP services such as those tied with other IM > services that people simply don't EXPECT to behave like a phone. > However, when you have a service which CAN be used with something like a > phone, people then expect it to behave just like a phone in all ways. > They've tied their awareness to a familiar paradigm, and they're unable > to expand beyond that. > > It's really fascinating from the standpoint of psychology. > > When WiMax comes into play in a larger scale (assuming it ever becomes > cost-effective), it will open up yet further avenues of misconception. > Will my new WiMax-enabled GoogleTalk Communicator or AIM Handset have > E911? I mean... it LOOKS like a phone, right? So it should have E911. Of > course, if I'm outdoors, they might have GPS built in, but if I'm > downstairs in the mall, with wifi repeaters all around to keep the > signal strong, and just roaming from store to store, how would anyone > ever know where to find me? > > These are basic problems for which NO one has a solution. As many > E911-capable VoIP services as there are these days, the simple fact > remains that truly nomadic VoIP does not have the infrastructure yet to > be able to handle E911. And the more flexible we make it, the less > chance we will ever solve that problem without massive redesigns of the > way IP is routed and handled. > > > > Trevor Peirce wrote: > > Drew Gibson wrote: > > > >> This call was one of the marginal cases and this is the question I was > >> trying to ask. As with most emergencies, this situation was created by > >> a combination of failures. > >> > >> Rightly or wrongly the current situation is that... > >> > >> 1. The customer expects the Telco to take care of 911 entirely, as > >> they always have in the past. > >> > > Indeed. The VoIP provider should take a more proactive role to ensure > > the customer understands that 911 address != billing address. First, > > the regulations require periodic reminders be sent to the customer to > > keep their address current. Second, it would be good practice for all > > providers to offer to update 911 address at the same time when they are > > processing a billing address update. > > > >> 2. The VoIP provider expects the customer to update their 911 address, > >> as the provider cannot strictly control location (except the cable > >> providers such as Shaw Cable, through which the ambulance was > >> correctly dispatched) > >> > > As above. Cable companies have a benefit that they attach their device > > to your house so it cannot be moved without them coming out and doing it > > for you. Thus, they are allowed to route directly to a PSAP and use > > E911. VoIP is not allowed to do this per CRTC regulations. > > > >> I'll leave it to the lawyers to apportion blame but, in the mean time, > >> how is this disconnect being addressed by VoIP and 911 service providers? > >> > > In my opinion the address not being updated is a very small factor of > > the failure at hand. The bigger failure is the lack of communication to > > verify the caller's address or let them speak to the PSAP directly. If > > the caller did speak to the PSAP, or if the caller told the person on > > the phone that the old address was correct, then the point of failure > > shifts from the VoIP provider/911 termination partner to the caller. > > However, it is my understanding that the address was not verified with > > the caller and that the caller never spoke to the PSAP, and that is why > > this happened. > > > > The current implemented system in Canada has room for improvement, but > > the processes required by law does work fine and requires several stages > > that would have prevented this failure if they had been followed by all > > involved parties. It will be interesting to find out the details of > > what exactly went wrong. > > > > Because of this failure, here is today's article recommending against > > VoIP services: > > http://www.cbc.ca/canada/calgary/story/2008/05/05/rethinking-voip.htm > >
I still strongly believe is not a voip only responsibility may be I am being naive here, but if not provided by the registrar why don't enforce all VoIP devices to have to configure by firmware a fail-over 911 routing, (with the due 911 counterpart from 911 services) all will be fixed to something like sip:[EMAIL PROTECTED] (or ca) and you get to enter some data like location, doable things @ 911: some IP mapping when receiving yearly auto call to confirm location field test site to test, confirm location, and enable service (like sip:[EMAIL PROTECTED]) ask where are you? if voip call (happens with cells too, some calls appear as originating from different cities) > > _______________________________________________ > > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > > > asterisk-biz mailing list > > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-biz > > > > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-biz mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-biz
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz
