isen.blog

[I wrote the following article for America's Network. It appeared in the June 15, 2004 issue.]

No technological platform’s place is secure when change is rapid. In the ‘80s I bought into the vision of ISDN services like text messaging and digital music-on-demand. But such ISDN services never left the telcos’ labs. In the ‘90s I saw ATM as the telco architecture of the future. However, in a few years processing improved so much that packets of any size could be handled at “wire speed,” and suddenly ATM’s 53-byte cells seemed unnecessarily inflexible. The story repeats. Remember token ring? Datakit? HomeRF?


Recently I’ve proclaimed that Session Initiation Protocol (SIP) will do for communications what HTTP did for documents. SIP has become the dominant Voice over IP platform. Vendors of telecommunications hardware and applications have put heroic and successful efforts into SIP interoperability. But SIP was not carried down from a mountain on stone tablets. And it has hit some big problems.


SIP’s architects decided to separate call control from the voice stream (and other communications content) so SIP can handle the most sophisticated communications applications. “I can add feature servers and application servers located all over the world without impacting voice latency,” explains Jonathan Rosenberg, one of SIP’s formative developers.



SIGNAL AND STREAM

This separation of signal from stream lets SIP handle complex applications like third-party call control.


But SIP’s separation of signaling packets from media packets creates problems wherever Network Address Translation (NAT) is used — and that’s virtually everywhere there is an Internet based local area network (LAN).


After traversing a NAT, a signaling packet might carry a meaningless destination IP address for its media packets — NATs translate header addresses but not addresses in a packet’s payload. There are several fixes.


The most common, according to Rosenberg, is to re-combine the two kinds of packets at the sending server, so they traverse the NAT together. And Rosenberg has authored a third, more general fix, called ICE, which is working its way through the Internet Engineering Task Force.


I asked Mark Spencer, the author of IAX, another fast-gaining communications protocol that is shaping up as SIP’s rival, about differences between SIP and IAX. “SIP violates protocol layering principles,” says Spencer. In addition, he says, SIP is hobbled by complexity of “seemingly limitless extensions.”


SIMPLE SOLUTION

IAX, he says, is comparatively simple. More importantly, IAX is architected so that both media and signaling are multiplexed on a single port and unpacked at the application level. IAX packets contain signaling and media that are separated only by an application.


Asterisk is the main application built on IAX. It is an open-source PBX, or even a “software central office,” according to Brian Capouch, a wireless ISP and VoIP service provider. Benjamin Kowarsch, a VoIP systems integrator specializing in Asterisk phone systems for enterprises says, “With an IAX phone, VoIP is a true plug-and-play affair.”


SIP devotees are quick to point out Asterisk’s limited handling of complex situations, and they say that anything IAX can do, SIP can do better. Furthermore, even though IAX is open source, it has close ties to a single hardware vendor, Digium.


My fingernails are way too clean to call winners. But I’m intrigued by lightweight protocols that require no network changes. And the buzz around IAX is getting too loud to ignore.