December 2000

Heeding The Call Of Standards 

BY Tom Keating

Companies such as Cidco, congruency, ESI, e-Tel, Pingtel, and Unidata all offer IP telephones. Of course, the fact that several products have been announced or released isn't necessarily a bad thing. In fact, it shows that the Internet telephony industry is growing, maturing. Though I should point out, we've still got a way to go. What about interoperability between these products? In order to bone up on this matter, I attended Internet Telephony Expo in San Diego and learned quite a bit.

ADMIT THAT THE WATERS AROUND YOU HAVE GROWN
With over eight competing IP telephones to choose from, interoperability becomes a major issue. No one ever worried whether or not a Sony analog cordless phone would be able to dial over the PSTN and connect to a Radio Shack phone. That's the beauty of standards. I still can't believe that when I was growing up my parents had virtually no choice of analog phones to use. Even worse, they were forced to lease the phone from the phone company with a reoccurring monthly charge on the phone bill. Talk about a rip-off!

Thankfully, with competition coupled with deregulation, today we can have a wide selection of analog telephone sets that are guaranteed to work on our analog phone line. And thankfully we can buy our phones at any local Radio Shack, Circuit City, or K-Mart instead of leasing them. Heck, sometimes you can even get a football phone as an incentive to subscribe to certain sports magazines!

SINK OR SWIM
Standards, such as those defined for the traditional circuit-switched network, including analog, SS7, T1, and others, are exactly what we need within the Internet telephony industry. Sure, we've probably all heard about standards for VoIP, such as H.323, MGCP, and SIP, but are they really standards? A standard isn't truly a standard until three conditions are met:

1) Vendors understand and fully implement the standard "to the letter," with no proprietary add-ons which dilute the standard.

2) A certified and recognized standards body defines and ratifies a standard with no vagueness or gray areas.

3) Market acceptance and penetration.

The first condition states that vendors understand the standard and follow it precisely. Too often with technology standards such as Java or HTML, at least one company decides to go with a proprietary method that can set everything out of whack. Many companies resist "commoditizing" their product for fear that several competitors will then be able to enter their space, forcing lower prices. This "fear factor" is often why companies choose to stick with proprietary methods to maintain a certain level of control within their market niche. However, in my opinion, choosing a proprietary solution in today's fast-paced Internet society will only stunt market growth.

I don't believe that any H.323, SIP, or MGCP vendors have intentionally failed to follow their respective standard to the letter of the law. Although, I do believe some may be stalling implementing a 100 percent interoperable product. You see, companies want your money and business today. If they can get you to buy more of their product (in this case forcing you to buy their gatekeeper), they'll do it.

THE WHEEL'S STILL IN SPIN
In any event, most companies have tried to follow the H.323, SIP, and MGCP standards without incorporating proprietary add-ons. However, I still have to give all the VoIP standards a "B- rating" (See Chart 1) since I have seen too little interoperability between VoIP products. This in itself means that these companies do not fully understand the standards they are trying to implement or they have made mistakes while doing so. Too often there are VoIP products with unintentional mistakes in some implementations that affect interoperability.

The second condition (stating that a standards body defines and ratifies a standard with no "vague" or "gray" areas) is very important. For example, I can't tell you how often I hear vendors say that the H.323 standard is too complex to implement and leaves too much open to interpretation. But there's a catch-22. If you add to the definition of the standard, you can increase the complexity. This is not to say that H.323 is a bad standard. It certainly has its merits. But it's frustrating when vendors claim to be H.323-compliant and then fail when I ask them to demonstrate that interoperability with competing H.323 products.

SIP does not suffer the same fate as H.323 with regards to being "vague" or having "gray areas." SIP is much easier to implement and less complicated than H.323, so I give SIP an "A" rating for meeting this second condition. MGCP, on the other hand, is a powerful standard that can actually manage both SIP and H.323 traffic. There aren't a whole lot of MGCP implementers, but it shows promise and is probably more clearly defined than H.323, thus earning an "A-" rating. Finally, H.323 suffers from too many poorly understood interpretations, which merits it a below satisfactory "C-" rating.

The third condition (market acceptance and penetration) is certainly led by H.323. H.323 implementations and port numbers currently outnumber both MGCP and SIP. Many companies support H.323, or plan to support it in their products, so H.323 has certainly gained market acceptance and penetration helping it to earn an "A+" rating. Both SIP and MGCP are fairly new, so they haven't had a whole lot of time for market acceptance and penetration, though SIP is very hot and has been growing fast. Many companies are looking at SIP as an alternative to H.323, especially in the communications ASP marketplace, and several SIP products are already on the market. I give SIP a "B+" rating and MGCP a "B" rating for market acceptance and penetration.

So where are we at in terms of interoperability? At the recent Internet Telephony Expo in San Diego, one of my TMC Labs collegues, Adam Altman, was responsible for running ConvergeNET, a VoIP interoperability test bed with over 25 participants. There were several successes but there were just as many failures getting vendors' products to interoperate. An example of one of the failures was AG Communications, a subsidiary of Lucent Technologies, who claimed to interoperate in their labs with other vendors, but could not prove their interoperability with the six or so vendors in their pavilion. This goes to show you that what happens in a test lab environment doesn't necessarily accurately simulate a "real world" situation.

One H.323 interoperability success was when QuickNet and ShelCad registered with Tundo's gatekeeper and successfully performed a VoIP call. Another H.323 interoperabilty success was when NetCentrex and UniData Communication Systems also registered with Tundo's gatekeeper and made successful VoIP calls. On the SIP side, 3Com successfully called Ubiquity and Pingtel from their SIP phones to the subsequent SIP endpoints. For a more detailed report, read Adam's article "An Urge to Converge" in the December 2000 issue of Internet Telephony.

YOUR OLD ROAD IS RAPIDLY AGIN'
While some might argue that having three standards for VoIP is too many, there are good reasons why all three are needed, at least for now. The point of this column isn't to say which standard is the best or which standard I prefer. Rather, I thought it was necessary to point out the strengths and weaknesses of each and why interoperability is important no matter which standard or standards find both market and mind share. Several vendors have taken a standard-agnostic approach by supporting both SIP and H.323 in their product line, and some support MGCP as well. Also, there are products that perform SIP to H.323 (and vice versa) protocol conversions so it doesn't matter which endpoints you use. One company doing protocol conversions is ComGates, but I'm sure there are others.

Of course if a vendor doesn't implement the VoIP standard 100 percent correct within their product, then interoperating with another company using the same VoIP standard is impossible, let alone interoperating with a different VoIP standard. So let me conclude by urging all Internet telephony vendors to attend VoIP interoperability events, such as ConvergeNET, to test their product's interoperability against other vendors' products. It is only through interoperability that will allow us to one day drive down to the local Radio Shack to purchase an IP phone that is guaranteed to work when we bring it home. It's like dj vu all over again. 

[ Return To The December 2000 Table Of Contents ]

Besides taking an eager interest in ConvergeNet at Internet Telephony Conference & Expo, I met with several interesting companies. One in particular, VegaStream, has a VoIP product called the Vega 50 IAD FXS, which is a VoIP gateway designed for plug-and-play deployment. Enhanced network services can be extended across IP networks to provide Centrex-type services to SMEs or SOHO environments. Featuring a LAN interface with either SIP or H.323 protocol stacks, it has the added advantage of two fall-back ports that when connected, route calls over the traditional phone network.

I also met with Continuous Computing, which has a product called Telco Protocol Engine for CompactPCI. Essentially a SPARC-based, NEBS-compliant, 19-inch rack mountable system targeted at the telecom market, it has some unique features. While most CompactPCI systems utilize the CompactPCI bus for card communication and fault-tolerance, Continuous Computing actually uses two redundant Ethernet connections for communication amongst the various components and to enable fault-tolerance. Since it utilizes Ethernet, a second or third chassis in an entirely different location can actually be added to the system for additional redundancy. Because all communication is handled via IP over Ethernet, disk mirroring is another feature standard with this system. Any data is written to two duplicate disks transparently over Ethernet. If one drive fails, the system can automatically switch over to the second disk with no loss of service. I highly recommend ASPs, ISPs, telcos, service providers, and anyone else needing high available systems to check out Continuous Computing's product line.

Finally, this bit of news isn't related to Internet Telephony Conference & Expo, but I thought it was interesting nevertheless. A company called BSQUARE has a VoIP software app called bInTouch 1.1, designed for Windows CE devices that allow one Windows CE device to communicate with another Windows CE device over any IP connection! Check it out at www.bsquare.com. 

[ Return To The December 2000 Table Of Contents ]