VoIP in the Home
There was some talk of home users at VON, but the vendors' energy was clearly not there. VoIP is not yet a mass phenomenon in the home market, at least in North America. And in fact, people with VoIP in the home tend to complain about quality. Is the problem meager provisioning of network bandwidth by the DSL or cable company? Not according to Peter Nilsson of i3 micro technology. He says he's spent lots of time configuring home networks for VoIP, and it's not easy to do well. It may be necessary, for instance, to set up separate virtual LANs for voice and data.
But ADSL, especially the newer ADSL2+, has plenty of bandwidth for voice and video. ADSL2+ promises 28Mb/s downstream in theory, and delivers about 15Mb/s. This should be enough for three video streams. As copper performance goes up in speed and video compression brings bandwidth requirements down, fiber to the home becomes less necessary--at least until new applications such as videoconferencing come into demand.
So a lot depends on configuration. Nilsson thinks many vendors spend three hours per year doing customer service over the phone with each customer, an investment that can take five months to recoup. Truck rolls are even more expensive. He boasts of the remote configuration designed into i3's customer-premise equipment, which takes the matter right out of the customer's hands; in fact, the customer often doesn't even realize something was done to the box to fix a bug or enable a new feature.
Firming Up the VoIP Foundation
As I pointed out, VoIP is evolving a bit differently from some familiar disruptive technologies such as the Web, instant messaging, and open source software. The latter went through a big grass-roots phase, becoming popular with individuals before businesses. VoIP has its early adopters, certainly (particularly among people making international long-distance calls), but it looks like it's on a trajectory now from big enterprises down to individual users.
Therefore, VoIP vendors are very concerned with robustness and reliability; they have to promise uptime just as good as the well-established circuit-switched phone network. Easy administration is also a concern for their enterprise customers.
So I wouldn't be surprised if the focus of VoIP slides for a while from innovation to standardization. Or more likely, hackers and academic experimenters will continue to develop new applications, but they won't be as visible at a show such as VON, just as a lot of the cutting-edge experiments with Linux are hard to find at the LinuxWorld trade show.
At VON last year (documented in an article from that time), everything I attended was about protocols and interoperability--technical concerns. This year, I've noticed a lot more interest in scaling up deployments (sometimes to the county level), remote management with self-administering gateways, and other such enterprise concerns. Many speakers announced the dominance of the SIP protocol, which is a bet on safety and familiarity. One vendor said that standards continue to evolve, but not so much through the invention of new ones as through extensions to standards that are known to have something to offer, notably SIP.
The recent eBay/Skype deal illustrates in a rather oddball way the entry of large companies into the VoIP space. More typical was the joint venture between Intel and Digium--the company founded by Asterisk creator Mark Spencer--to make Asterisk one of the drivers on Intel telephony products.
Security Sucks All Over Again
Just as with web database applications and other new programming environments, VoIP has to go through a familiar period of fixing up security. Set aside worries about sophisticated denial-of-service attacks: the immediate danger is in garden-variety buffer overflows and other common programming errors.
I talked to Ejovi Nuwere, who runs SecurityLab and makes a living auditing VoIP products for security. To show how we can't ignore lessons from the past, he examined several open source SIP implementations and found at least two major security vulnerabilities in each, reporting on them at the recent BlackHat conference.
The reasons he cites for security problems are also depressingly familiar. Firms developing VoIP solutions are small and have few resources to devote to coding; furthermore, they concentrate on features and equipment instead of robustness and security. Often they base their software on the open source implementations just mentioned, as a quick way into the market. (At least they won't be any worse than the rest of the vendors doing the same thing.) Managers may come from a public switched telephone network (PSTN) background and have a false sense of security, because they're used to a closed network.
Ways to capture voice and convert it to text have also been feasible for some time, an enabler of many good applications but also a boon to malicious snoopers.
Performance Monitoring for Quality of Service
Along with security, another province explored by several companies at VON was performance monitoring. I talked to Alan Clark, who worked at British Telecom and developed some important standards, such as V.42bis compression, while on his way to founding Telchemy to create monitoring software for VoIP and video over IP.
Many problems with these services are naturally transient; they depend on what somebody else along the route might be doing at the moment. Telchemy monitoring software has a small footprint and can be inserted practically anywhere, either into dedicated hardware or a network device doing the transmission. It measures packet loss and jitter, along with some other statistics that reflect subjective user experience.
Compared to voice, video is even more challenging because:
- It requires more bandwidth, so it is more likely to encounter congestion if the network is not up to the task.
- It is implemented with more protocols, leading to a combinatorial explosion.
- It is more sensitive to IP problems. For instance, while VoIP can usually tolerate up to 5 percent packet loss, video is unviewable at 1 percent packet loss--sometimes even lower. Furthermore, measures taken by sophisticated protocols can exacerbate problems of loss: for instance, most protocols use interframe difference encoding, which is very efficient but not robust if a frame is lost.
Changes Proposed at Layers 1 and 2
I had an intriguing short talk with David Bassett of Vocal Technologies. Their latest product can provide VoIP for a whole house of phones for about $100. The main component plugs into a DSL or cable modem, while other components connect individual phones to phone jacks and create an Ethernet over the internal phone lines.
Bassett found that Layer 1 and 2 protocols create problems for VoIP and could be improved to retransmit faster in case of collisions. He has submitted some ideas to the IETF for allowing trade-offs at these low layers between efficiency and fairness, ultimately cutting way down on packet loss for VoIP.