Thursday, May 05, 2005
VoIP E911 problem solved End of September by definition
According to Reuters the U.S. Federal Communications Commission Chairman Kevin Martin has proposed requiring Internet-based telephone services to offer 911 emergency services to customers by as early as the end of September, people familiar with the plan said on Wednesday. ... The proposal would require companies like Vonage Holdings Corp. to route 911 calls directly to primary emergency lines within four months of the order being issued, the sources said, declining to be identified because the proposal is not a public record. Martin has circulated the proposal so it could be voted at the agency's open meeting on May 19, the sources said. He would have to win the votes of two of the other three FCC commissioners for approval or work out a compromise with them. An FCC spokesman had no immediate comment.
Ok, I have some immediate comments:. This approach is typical how politicians solve technical problems today: by setting a dead-line. These technical morons always raise issues and come with endless problems, you just have to give them a certain date - if it works out, it is your success, if not, you simply blame the technicians - everybody knows how stupid they are.
Location infomation from mobile phones, biometric data on passports, too sexy cheerleaders in Texas, emergency calls from an application on a PC, all the same.
Being involved in IETF ecrit , NENA and ETSI EMTEL, I know of the intentions, requirements and the status of work in these groups to provide emergency services from devices connected to the Internet. To make it short: the issue looks promising and at the end-of-the-day the solutions provided will be superior what we have now, but there are still some problems to be solved and this will take some time.
One outcome of this will be basically derived from the same principle I talked aboiut in my post on the NGN: The Internet is end-to-end and VoIP is an application, not necessarily a service.
This implies that you may not have a VoIP service provider at all, so why put obligations on service providers in the first place. The obligations will shift to device manufacturers, access and infrastructure providers and to the PSAPs. But this will need some considerations and also regulatory and legal action, but these issues can definitely not solved within 3 month.
In addition, if you provide a VoIP service on the Internet only, you are not obliged to provide access to emergency services. Now if you provide OutCalls (say SkypeOut) in addition, you are? If your gateway feeding to the PSTN is not in the US?
Hmm, but if you provide InCalls from the PSTN, now you are obligated, because you need our national numbers, hehe, gotcha. But we are dsicussing calls TO emergency services, so what has this to do with InCalls to a E.164 number. Ah, it is the number displayed in the OutCalls to identify yourself to the ANI and ALI, or whatever. But what if I use two different providers for In- and OutCalls? The provider for OutCalls will not know the number I have from the provider for InCalls, so what is displayed in the OutCall. This will be no problem with future direct connectivity IETF ecrit is working on, because the identity and location will be transmitted directly to the PSAP, if the PSAPs have VoIP connectivity.
But this will not be the case until September. Ok, in the meantime Verizon and SBC may sell their products to the VoIP providers. Now I finally got it.
Ok, I have some immediate comments:. This approach is typical how politicians solve technical problems today: by setting a dead-line. These technical morons always raise issues and come with endless problems, you just have to give them a certain date - if it works out, it is your success, if not, you simply blame the technicians - everybody knows how stupid they are.
Location infomation from mobile phones, biometric data on passports, too sexy cheerleaders in Texas, emergency calls from an application on a PC, all the same.
Being involved in IETF ecrit , NENA and ETSI EMTEL, I know of the intentions, requirements and the status of work in these groups to provide emergency services from devices connected to the Internet. To make it short: the issue looks promising and at the end-of-the-day the solutions provided will be superior what we have now, but there are still some problems to be solved and this will take some time.
One outcome of this will be basically derived from the same principle I talked aboiut in my post on the NGN: The Internet is end-to-end and VoIP is an application, not necessarily a service.
This implies that you may not have a VoIP service provider at all, so why put obligations on service providers in the first place. The obligations will shift to device manufacturers, access and infrastructure providers and to the PSAPs. But this will need some considerations and also regulatory and legal action, but these issues can definitely not solved within 3 month.
In addition, if you provide a VoIP service on the Internet only, you are not obliged to provide access to emergency services. Now if you provide OutCalls (say SkypeOut) in addition, you are? If your gateway feeding to the PSTN is not in the US?
Hmm, but if you provide InCalls from the PSTN, now you are obligated, because you need our national numbers, hehe, gotcha. But we are dsicussing calls TO emergency services, so what has this to do with InCalls to a E.164 number. Ah, it is the number displayed in the OutCalls to identify yourself to the ANI and ALI, or whatever. But what if I use two different providers for In- and OutCalls? The provider for OutCalls will not know the number I have from the provider for InCalls, so what is displayed in the OutCall. This will be no problem with future direct connectivity IETF ecrit is working on, because the identity and location will be transmitted directly to the PSAP, if the PSAPs have VoIP connectivity.
But this will not be the case until September. Ok, in the meantime Verizon and SBC may sell their products to the VoIP providers. Now I finally got it.
Comments:
Post a Comment
