By Joel Snyder
Network World, 05/10/04
Original Article on Network World Web Site
We didn't just take a sip. We took a good long drink of SIP technology in this round of iLabs testing.
We gathered more than 50 devices from five SIP server vendors and 13 SIP endpoint vendors to prove that multi-vendor SIP telephony deployments are possible. Our results show that while basic SIP interoperability is outstanding, advanced features such as call forwarding and conferencing might not work so smoothly between all SIP devices.
Protocol simplicity is an argument in favor of SIP over the more complicated H.323 VoIP standard. This simplicity minimized interoperability problems and made device configuration easy. Compared with previous iLabs tests involving H.323, SIP let us connect more devices to more servers more quickly. With the exception of an older device an engineer brought from his own network, all SIP endpoints passed our basic call tests.
Starting from scratch
We defined our telephony environment in the context of a midsize company wanting to build a SIP-based VoIP system from the ground up. Designing a VoIP network is much like designing a LAN : You have to plan all aspects, from numbering of phones and IP addresses, to setting up services such as voice mail and call conferencing, to enabling voice encoders, to naming devices.
One of the first VoIP planning steps is setting up the dial plan (see "Dialing for VoIP dollars" ) that defines how long phone numbers are, how gateways to the public switched telephone network (PSTN) are addressed and how the internal network is divided between SIP servers.
In a traditional telephony environment, the dial plan is built into the PBX. In a SIP network, the dial plan has to be configured on all phones individually. If you don't program the dial plan into the phones, end users will either wait for the phone to "time out" when dialing or hit a terminator character (the pound sign is common) when they're done to get the phone to dial (like hitting "send" on a cell phone).
Because of the expanse of our SIP test bed, we had a fairly complex dialing plan and found that not every phone could support that. On our network, users could dial phone-to-phone with a four-digit extension. But to dial through to the PSTN, Interop's eNet or Free World Dialup SIP service, they'd use single-digit prefixes, such as "9," followed by a number on the other network. A number of SIP endpoints couldn't handle that much flexibility. With those phones, we put in a maximum number of digits - 19, to be exact - and use timeouts or terminators when dialing. It's hard to say whether this is an interoperability problem or just poor design.
With dialing plan in hand, we installed the five SIP proxy servers, open source Asterisk (from Digium) and SIP Express Router (SER, from iptel.org), and commercial products from Avaya, Cisco and Nortel. Each SIP server had to support a number of phones and be able to send calls to the other SIP servers. We took the 40-plus phones and assigned each to one of the SIP servers (see graphic ) so that each phone registered with only one SIP server and that server was responsible for routing any SIP calls for that phone.
When we achieved 100% interoperability between SIP servers using direct dialing, we threw a monkey wrench into the works by adding an Enum dialing test. An international proposal on how to link the Internet VoIP and PSTN worlds together using DNS Enum currently is mired in political infighting in the U.S. However, the concept of Enum can be applied at the enterprise level in a private DNS tree. For the SIP servers that supported Enum - Asterisk and SER - it worked well.
Once we had basic connectivity working, we dumped all the phones on the different SIP servers to test interoperability within each SIP server. We had a few problems getting the phones installed as the number of them stressed our team from an installation and a testing standpoint.
Most of the phones we tested were SIP "hard phones," generally managed using a Web-based interface. We installed phones from Avaya, Cisco, Grandstream Networks, ipDialog, Pingtel, Polycom, Pulver Innovations, Siemens and Snom Technology. We also tested soft phones from Xten on Windows and Mac OS X platforms, and FXS gateways (see "SIP terms") from AudioCodes, Cisco, D-Link Systems, MIP Telecom and Multi-Tech Systems.
When it came to simply calling from phone to phone through the same SIP proxy server, we achieved nearly 100% interoperability. Of the 230 test cases, only seven were not resolved by some reconfiguration in our testing, coming down to two very specific combinations of phone plus SIP proxy (ipDialog phone on SER SIP proxy and Polycom phone on Avaya SIP proxy). The most common problem we saw was phones that connected to each other, but didn't have audio reception.
This success doesn't mean that everything behaved perfectly. We ran into some problems, such as calls that wouldn't complete and phones that didn't ring, which disappeared when phones were rebooted or calls were redialed.
Our single-application VoIP network comprised a dedicated, 100M-byte switch port to each device. We discovered that the VoIP network was extraordinarily sensitive to small perturbations in topology. We were forced to make several adjustments to DNS and Dynamic Host Configuration Protocol services after discovering that many of the SIP phones do not have the same tolerances for different TCP/IP network designs. For example, our Cisco phones would occasionally fail to complete calls when DNS requests went through a router, but behaved when we added a non-routed path to the DNS server.
One very basic interoperability failure, however, was a complete surprise. We hooked an Adtran channel bank - which takes a multiplexed phone line, such as a T-1, and breaks it out to its 24 individual lines for connection to traditional analog telephony devices - to a Digium T-1 card to provide some analog phone lines to connect to phones and to the PSTN. Unfortunately, the channel bank didn't mix well with the inexpensive analog speaker phones we purchased for the test lab. We managed to make two of the phones unusable before we realized what was happening.
Features cry foul
Simply making calls is only part of the picture for an enterprise VoIP deployment. We also were interested in features, such as call transfer, that would further stress the interoperability of SIP phones and our SIP proxy servers a little more.
Testing these features is easy, but deciding where the problem lies when they don't work is not. To help us in this analysis, we depended heavily on EtherPeek NX from WildPackets and the VoIP-centric ClearSight Analyzer from ClearSight Technology. We were particularly impressed at ClearSight's ability to record a VoIP call and play it back, a feature that helped us debug voice quality problems.
Because many features are built into the phone, rather than into the SIP proxy server, there's no one place on the network to look for feature support. Some features, such as call transfer, also suffer from a lack of standard nomenclature across vendors. For example, when some vendors mention call transfer, they mean "blind transfer," where the call is simply sent from one phone to the other. Others mean "consultative transfer," where the person doing the transferring speaks first and says what is happening. These are pretty simple in traditional telephony, but are radically different operations in the VoIP world.
Where the VoIP community hasn't reached agreement on strategies, we also found interoperability problems. For example, there are several options on how to send dual-tone multifrequency (DTMF) tones - the tones you hear while dialing the phone - over a VoIP network. You simply can send the DTMF tones in-band over the data path as tones, or you can use the RFC 2833 format to send a special payload that tells the other end that a DTMF tone is being generated. We used the RFC 2833 format, which is more robust, and found two curious combinations of phone and SIP proxy combinations - the WiSIP phone on Asterisk SIP proxy and the Siemens phone on Avaya SIP proxy - where it didn't work properly. These were phones that worked correctly on other SIP proxy servers, and SIP proxy servers that worked correctly with other phones, so we could not determine which end was the source of the problem.
In testing our other enterprise features, including call hold and retrieve, call transfer, multi-line calling and receiving, call forwarding and conferencing, we ran into the same kind of variability: Many things worked, but we had a much lower success rate than with simple calling.
In some cases, we could see the culprit pretty easily. For example, no call transfer across SIP proxy servers involving the Asterisk SIP proxy worked, pointing the finger pretty strongly at Asterisk. We also saw repeated failures in call transfers involving Siemens phones and multiple SIP proxy servers.
PSTN and firewalls
One of our goals was to show how an enterprise SIP network could be connected to the PSTN directly over the Internet using a telephony service provider. Free World Dialup, a no-cost SIP network that has connections to several PSTN service providers, built a link to the iLabs SIP network. Voicepulse, Vonage and Packet8, three other commercial telephony service providers using SIP, declined.
The Free World Dialup link showed another SIP interoperability issue in bold letters: security. We initially protected our SIP test bed using a Check Point firewall, its latest and greatest version of Firewall-1, which includes a SIP proxy as part of the basic unit. Using a fairly general model, the Firewall-1 SIP gateway knows about SIP proxy servers and SIP signaling and can use information on a proxy-to-proxy connection to let two phones talk directly to each other.
Unfortunately, a worldwide network like Free World Dialup isn't constrained very well because any system on the Internet can participate. That vagueness meant that Firewall-1's advanced SIP capabilities weren't much use to us. Even if you weren't connecting one enterprise SIP network to another company, you'd run into similar problems if you let end users take soft phones or hard phones on the road with them. A stronger authentication measure, such as an IPSec VPN tunnel, would probably be necessary.
We also integrated an Intertex IX66 SIP firewall in to our test network between a Polycom phone and an Asterisk SIP proxy server without any changes in interoperability or feature support.
Doing your own testing
We pinpointed several areas where additional SIP testing is needed. One is voice quality. Some SIP devices, such as the AudioCodes FXS gateway, were tuned to work best across a low-latency network like a Fast Ethernet LAN. When we used the AudioCodes gateway, there was no noticeable latency on VoIP calls. At the other end of the spectrum were the soft phones from Xten, the Windows and Mac versions of X-Pro. With Xten, the combination of the latency introduced by our test laptops and tuning aimed at calls over the wide-area Internet, introduced a very distinct delay into our calls.
Most SIP hard and soft phones and gateways let you tune the audio jitter to meet the performance characteristics of your network. In testing for an enterprise deployment, human factors such as jitter management and appropriate delay are important considerations.
