VoIP E911 Notification

Jeff Pulver points to an FCC public notice regarding the notification requirement for interconnected VoIP providers to tell their subscribers that 911 might not work on their VoIP service.

I have to say I find disturbing the requirement that service providers disconnect all customers who have not affirmatively acknowledged the notification. As Jeff points out (I haven't independently checked his numbers, but see no reason to dispute them), 1.5M landlines in the US do not have E911, and significant numbers of wireless phones do not have E911, but there has been no requirement on ILECs or Cellular carriers to get affirmative acknowledgdment from these customers, and especially none to shut off service to customers who don't affirmatively acknowledge.

Is the public interest better served by customers not having VoIP service at all than by customers having VoIP service without E911? How does this square with the logic that the public interest is better served by ILEC and Cellular customers having service without E911?

(Let's ignore for the moment that the ILECs that do not provide E911 are typically rural independent telcos, which have an inordinate amount of lobbying clout.)

If you're an ILEC customer without E911, it's OK for the ILEC to give you a phone line without E911, because they're often the provider of last resort - if they don't give you a phone line, you don't have a phone line. But if you're a VoIP subscriber, I guess the logic is that you can always get phone service from the ILEC if the VoIP service provider cuts you off.

But isn't that a regulatory impediment to competition? If the FCC considers intermodal competition (e.g., cable companies competing with telcos for telephone service) a better method of ensuring consumer protection than, for example, regulations like local service unbundling, shouldn't they at the very least be avoiding asymmetrical regulation (such as requiring VoIP service providers to notify - and collect affirmative acknowledgement - of E911 limitations, but not requiring the same of telcos)?

This only applies out in the boondocks, where independent telcos don't provide E911, you say? Well, let's look at some of Packet8's caveats about when E911 may not work as expected, for example:

• When there is an electrical power outage, service outage or suspension/disconnection of Packet8 service due to billing or other issues.
• When a change of address has been reported, but not yet been updated on the Packet8 account.
• When the local PSAP receiving Packet8 E911 emergency service calls does not have a system configured for E911 services that enables the operator to capture and/or retain automatic number or location information.
• When due to technical factors in network design and/or in the event of network congestion on the Packet8 network, a Packet8 E911 call may produce a busy signal or experience unexpected answering wait times and/or take longer to answer.

Those could apply to my landline just as easily. If the ILEC has a service outage, my E911 service won't work. If I move and my ILEC drops the ball getting my new address into ALI, my E911 service won't deliver the correct address. If the PSAP can't receive or capture ANI/ALI, they won't get it. If there's a major emergency that results in mass calling, my E911 calls may not get through right away. But my ILEC isn't required to notify me of these limitations (I wonder how many people realize that telco switches have line concentration, and particularly in newer developments served by digital loop carriers, if everyone in their neighborhood picks up the phone and tries to call 911 at the same time, many of them won't even get a dial tone, let alone get through to the PSAP), and clearly aren't required to cut off my phone service if I don't affirmatively acknowledge these limitations.

Again, I fail to see how, in a deregulatory model that is supposed to encourage competition over regulation, imposing asymmetrical regulation like this is in the public interest.

I'm also trying to figure out exactly how you put a warning sticker on a softphone, but that's another topic...

Sprint/Nextel, WiMax, and Moto

It says here that Sprint and Nextel, after the merger, will transition their iDEN customers to CDMA. That means a lot of smart Motorola wireless techies will need something else to do.

It says here that Sprint expects to someday build a network using its 2.5 GHz spectrum, which is reported to cover 85% of the US population and is covered by one of the first WiMax profiles to be available.

It says here that Motorola has "expanded its strategic focus to bring comprehensive WiMax (802.16e) solutions quickly to market," including "increased R&D (and) resources."

Seems to me that Motorola has decided to take the lemons from the Sprint/Nextel merger and make itself some lemonade. And it seems that they're the team to beat to grab Sprint's mobile broadband wireless business, whenever Sprint does decide to build something. Consider:

1. Sprint is going to be looking for a mobile broadband wireless technology, not a DSL replacement. When Moto talks WiMax in the US, they mean 802.16e mobile.
2. Both Sprint and Nextel have bought Motorola, and existing purchaser relationships can mean a lot.
3. Motorola can show Sprint a solid corporate commitment to WiMax; Sprint's other two major vendors (Lucent and Nortel), not so much. Lucent is reselling Alvarion's WiMax line; Nortel is partnering with LG Electronics.

You've got to like the idea of a network supporting tri-mode devices that'll switch between WiFi (spotty coverage, high bandwidth), WiMax (wide coverage, moderate bandwidth), and EV-DO (ubiquity, lower bandwidth), depending on what's available.

NASA's Idea of Multimedia

I watched the Discovery launch today, with my heart in my throat until the solid rocket motors were jettisoned. (I'm in the generation for whom "where were you when the Challenger exploded" is a touchpoint question, much as the Kennedy assassination was for my parents' generation, and 9/11 will be for my kids'.) The difference from Challenger being that instead of watching it in my basement apartment at college on my 13" black and white TV, I watched the streaming video from NASA on my laptop.

Cool, I can watch the Shuttle launch here at the office without having to find a TV. One thing irks me, though, and that's the use of the term "multimedia" to describe streaming video to a computer. (Sorry to single out NASA; they've got better things to do than drive meaningful usage of technology-related terms in the English language, but it was their usage that made me think of it.)

No. Throwing the NASA TV feed out a webcast isn't multimedia. Show me thumbnails of four camera feeds and let me select which one I want to watch (so I can cut away from the shot of the Governer and his sister-in-law to, gee, maybe the launch pad). Superimpose the countdown clock over the video feed so you don't have to keep cutting back to the camera shot from the viewing stage where the clock is visible. Show a map with the transatlantic abort sites. After the launch superimpose the vehicle telemetry with position, altitude, and speed. Even better, have a live map showing vehicle position with altitude and speed superimposed. That's multimedia.

Microsoft, GIPS, Skype, and Money

So Microsoft has licensed the Global IP Sound VoiceEngine product, which provides the broadband codecs that Skype uses. (Several other bloggers have already noted this; I picked it up from Andy and James.)

Previously, when I conjectured on how much Skype was paying for its GIPS license, a commenter claimed that GIPS doesn't always charge on a per-port basis; rather, they "use the business model of each of their customers," and that since Skype doesn't charge for downloads, the license fee will be a percentage of revenues.

Hmm. MSN Messenger is a free download, just like Skype. Think GIPS is getting a percentage of Microsoft's revenues?

Facetiousness aside, this item and some recent commentary about the tension between Skype the platform and Skype the company developing applications got me thinking on several levels.

First, if in fact GIPS is getting licensing fees from Skype based on Skype's revenue, I would think they could be getting nervous about an explosion of third-party applications that contribute nothing to Skype's top line. Particularly if those applications are ones that don't drive Skype interworking with the PSTN, which is the only place Skype makes money currently. If I'm using Skype as a platform for video communications using one of the third-party video apps, there's nothing particularly driving me to buy SkypeIn, SkypeOut, or Skype VM.

By the same token, Skype itself has got a fundamental conflict, which makes it very different from, say, Microsoft. It makes no money off its basic platform. The more ability it gives developers to invent creative new applications, the less likely it is to be able to sell similar applications itself. Mindshare is great, mass adoption is great, but it doesn't pay the bills.

Companies in a situation like this have several options:

1. Limit the ability for third parties to develop applications that compete with in-house applications. Keep some capabilities out of the API, for example. Doesn't exactly endear you to third-party developers.
   
2. Charge developers in some way for access to the API. Also doesn't endear you to third-party developers, and inherently reduces the number of people who will want to be third-party developers.
3. Charge for the platform. Probably a rather unpopular move, and dangerous if user barriers to switching are as low as people think.
4. Charge for parts of the platform. Segment the product into two, for example: a "Skype Lite" and a "Skype Pro", with more capabilities in "Skype Pro" -- but only "Skype Lite" available for free.
   
5. Build applications that are so much better than what the third parties will build that customers will buy yours instead of someone else's. Hard, given the ability of third parties to focus more narrowly.

Personally, I'm betting on Number 4.