Saturday, June 04, 2005

Some Initial Impressions of the FCC's "Order on E911 Requirements for IP-Enabled Service Providers"

Jeff Pulver - The Jeff Pulver Blog



Well, as I mentioned in a preceding blog, the FCC released its "Order on E911 Requirements for IP-Enabled Service Providers". So far, I haven't found any major surprises in the text or rules, but we haven't yet parsed through the entire Order. I would like to highlight a couple of points that would likely interest members of the VoIP Community.
First of all, I am relieved that, as the FCC indicated, it is not (at least at the moment) applying technologically impossible obligations to what I consider purer IP-based communications products, services, applications and providers, most-notably the peer-to-peer IP-based communications services, such as Skype, the various IM platforms, the incidental voice applications associated with X-Box live, or my own Free World Dialup. The rules apply, as expected, to "Interconnected VoIP Services", and not to the cooler, cutting-edge, more differentiated applications that I think will ultimately revolutionize the ways in which we communicate. The definition of what VoIP services are considered is most telling:
"Interconnected VoIP service. An interconnected Voice over
Internet protocol (VoIP) service is a service that: (1) enables real-time,
two-way voice communications; (2) requires a broadband connection from the
user's location; (3) requires Internet protocol-compatible customer premises
equipment (CPE); and (4) permits users generally to receive calls that
originate on the public switched telephone network and to terminate calls to
the public switched telephone network."
I'm generally relieved by this definitional construction, at least until someone figures out how to extend and misconstrue this definition to subsume the purer flavors of VoIP. In any case, seeing this comforting definition in print underscores my own internal battle over why I have been somewhat critical of the FCC's process and approach to extending E911 obligations to "VoIP." If truth be told, I don't know if I would even consider the examples of "Interconnected VoIP Service" that we've seen to date to really be "VoIP." To some extent, they have been advertised as replacement services, and there is a compelling argument that they should be treated as telecom services. (Having said that, these providers should probably also have the rights of telecom carriers - including the rights to interconnect, obtain numbers, collocate, directly access the LEC-controlled selective routers, enter into interconnection agreements and arbitrate disputes with other carriers. But, perhaps this is not my battle.
In any event, it's been a strange couple of weeks for me on the policy front. Frankly, I felt compelled to question what the FCC was doing primarily because no one else seemed to have the will to do so. All of the VoIP providers were cowed by potential allegations or the perception that they were anti-emergency response and anti-safety if they challenged the process. It is exceedingly difficult to challenge the FCC when all it really wants to do is ensure ubiquitous emergency response capabilities as soon as possible. I want that too. I just don't want it at the expense of a better, next-generation, IP-enabled emergency response system. And I don't want to see it serve as a vehicle to dismantle some of the best additional features that IP technology affords, most notably the mobile, nomadic capabilities of VoIP and the ability to allow for another means other than a traditional phone to contact an emergency responder, even if that means is not fully compliant with the "traditional" E911 process. (In an upcoming blog, I will discuss in further details recent efforts to establish public hotspots and the ability to establish a much more ubiquitous, redundant emergency response capability.)
In any event, I have been in the lonely and unenviable position of challenging the FCC's approach to E911 for VoIP providers, knowing full well that the Order would not directly implicate any services that pulver.com offers. Anyone who follows my blogs knows that I should probably have been among the least likely of members of the VoIP community to fight for the PSTN-connected VoIP providers. In fact, I have historically been very critical of the bland, replacement service offerings of the broadband phone companies who use IP technology primarily to provide POTS replacement services. I applauded the FCC when it found that, under existing rules, simply including a little IP technology in the middle of what otherwise appears to be a traditional phone service, should not exempt the provider of such services from traditional telecom rules. I received some degree of criticism from several "VoIP" providers using IP technology to bypass long distance access charges. In hindsight, I might have overstated my support for the FCC conclusion in that Order. (Frankly, that "IP-in-the-Middle" Order has been used (and, in my opinion, misconstrued and over-applied) to stymie some legitimate deployment of connected-VoIP services. In any event, I have generally been quite critical of those providers that simply use IP-technology to offer stale replacement POTS-like services, without availing themselves of the true enabling power of IP technology.
Having said the foregoing, I am concerned that the FCC inverted what, to me, could have been a forward-looking approach that might have seriously advanced our emergency response capabilities. Rather than compelling VoIP providers to build "backwards" to accommodate the existing broadband-and-IP-limited emergency response centers, the FCC could have worked to bring the emergency response centers into the 21st Century. The PSAPs should all have broadband access and become IP-enabled. In fact, voice should not be the only mechanism to place an emergency "call." An IP user should be able send an IM, SMS, text or email message to emergency responders. In other words, the PSAPs should be upgraded; the PSAPs should become broadband-ready and should talk in IP to the IP-enabled world. That would produce a much more robust emergency response system. Instead, we might be stuck with a mediocre, limited, narrow-band emergency response capability and never get around to devoting the resources needed to upgrade the existing emergency response infrastructure.
* * *
I have some lingering concerns with some other conclusions in the Order. For instance, while we had been led to believe that VoIP providers would not be exempted from liability, I found it hard to fathom that the FCC would hold the VoIP providers to a higher standard than bona fide carriers. I was actually surprised to see it in black and white. The FCC's conclusion on liability for VoIP providers reads as follows:
"We decline to exempt providers of interconnected VoIP
service from liability under state law related to their E911 services.
Although the Notice did not directly address the issue, Intrado, among
others, requests that the Commission insulate these VoIP providers from
liability to the same extent that Congress insulated wireless carriers from
liability related to the provision of 911/E911 service in the wireless
context."
The FCC admits that this conclusion is based on the fact that it cannot point to legal authority allowing it to limit liability. I think the FCC could simply have made this point without specifically subjecting non-carrier VoIP providers to a higher level of liability than that imposed upon those for whom it has clear authority - bona fide telecom carriers, with all the rights and responsibilities that such status entails.
There is also a Notice of Proposed Rulemaking attached to the Order, which, as expected, asks whether the FCC should extend E911 obligations to providers of other VoIP services that are not covered by the rules adopted in this Order. For instance, the FCC asks what E911 obligations, if any, should apply to VoIP services that are not fully interconnected to the PSTN? Specifically, should E911 obligations apply to VoIP services that enable users to terminate calls to the PSTN but do not permit users to receive calls that originate on the PSTN? Should E911 obligations apply to the converse situation in which a VoIP service enables users to receive calls from the PSTN but does not permit the user to make calls terminating to thePSTN? The FCC tentatively concluded that "a provider of a VoIP service offering that permits users generally to receive calls that originate on the PSTN and separately makes available a different offering that permits users generally to terminate calls to the PSTN should be subject to the E911 obligations if a user can combine those separate offerings or can use them simultaneously or in immediate succession."
Uh, folks, I think they mean us - those of us offering more unique applications that are less likely to service as POTS replacement services. What happens to the Asian user who finds herself in America with a PDA upon which she has downloaded LibreTel's Port of Call and SkypeOut? Now, that PDA can reach the PSTN and receive calls from the PSTN. Did that user expect to have E911 capabilities in America? Should America's E911 rules outlaw her ability to download distinct inbound and outbound VoIP applications? I would say no. I suspect the FCC might conclude otherwise. Stay tuned (but let's just stick with text - it's less likely to be confused for telephony and less likely to be subjected to regulatory obligations).

0 Comments:

Post a Comment

<< Home