February 1st, 2005
Better VPN survivability needed for VoIP
In a recent story on a McDonald’s pilot project that leverages DSL, the public Internet, and VoIP,thefast food chainseeks to gain efficiency by consolidating drive-through order takers to a centralized call center. Based on the results, the project illustrates why the "IP" in VoIP still stands more for "Internet Protocol" and not the "public Internet" as far as serious business telephony deployments are concerned.
For most businesses, VoIP deployments primarily roam private LANs and WANs where the quality of the network is tightly controlled and almost never on the public Internet. In this experiment, McDonald’s is using a DSL connection at the remote stores to establish a site-to-site VPN tunnel to the central site to carry Voice over IP traffic. On a bad day, one of the branches experienced afour-hour outage in their VPN tunnel and had to resort to the traditional way of taking orders. This may or may not be acceptable to McDonald’s, but it clearly illustrates that the public Internet’s "best effort" delivery is nowhere near the reliability that we have come to expect from traditional telephony. This mistrust of the Internet to carry VoIP traffic won’t change until superior survivability mechanisms are more common for VoIP technology.
To improve VPN survivability, a lot of VPN solutions use ISDN as an alternate WAN link in case the VPN tunnel goes down. Unfortunately, the existing failover mechanisms are totally oblivious to the state and well-being of its telephony cargo and do not provide good failover mechanisms for VoIP. You could easily have a situation where the VPN tunnel stays up, but voice quality isunintelligible, yet the VPN box doesn’t know to switch over to ISDN for VoIP traffic. What is needed is a VPN solution that monitors VoIP call quality by means of an R-Value and will transparently switch live calls to a toll-based ISDN link. The toll charges for ISDN would be extremely minimal because it would rarely be used and would only serve to smooth out the rough patches in the public Internet. (Note that the R-Value in this context is not to be confused with the measurement of thermal resistance, R-Value in this case is the measurement of packet loss, jitter, and delay.)
Nortel, with their9100 series of remote telephony gateways, is one of the few companies that has implemented such an elaborate failover mechanism. In fact, it’s so unconventional that it not only completely bypasses the IP infrastructure, but IP itself. Instead of encapsulating voice with the traditional IP packet and those bulky IP/UDP/RTP headers (whichare twice the size of the actual voice data), Nortel manages to squeeze 16 G.729 encoded conversations into a single BRI ISDN link! Not only that, but it can flip the connection to ISDN for a live telephone callwhen conditions on the public Internet become temporarily unsuitable for voice transmission and R-Values decline greatly. Technically speaking, this couldn’t even be called VoIP anymore because the "IP" isn’t being used.But if it works, who cares? Not only does the Nortel solution eliminate almost all of the overhead for voice traffic and make the best use of a measily ISDN BRI link, but it knows when to fold up its tent on the public Internet and move to greener pastures on ISDN.My question: Who’s going to follow Nortel’s lead?
George Ou is Technical Director of ZDNet. See his full profile and disclosure of his industry affiliations.
