SIP aces basic interop tests - Network World

Skip Links

DNSstuff.com
Get information about your IP
IP Information
50+ On-demand DNS and network tools

VoIP & Convergence

Videos

rssRss Feed
Get instant email notification when white papers, webcasts, executive guides are added to our library.  Stay informed and up-to-date with the latest on IT Technologies with Network World's Resource Alerts.

Additional Resources

RSS

FEATURED WHITEPAPERS

Fill the Gaps in Your Disaster Recovery Plan with Single Object Recovery for Active Directory NetPro

Most companies have a solid disaster recovery plan in place to handle a "complete failure" of its Active Directory, which is really quite rare. What most recovery plans are missing, and the most common scenario, is a means to efficiently restore single directory objects. In this paper, we'll explore what most disaster recovery plans already address, highlight potential weak points, and suggest solutions that help fill those gaps-without requiring you to completely re-do your existing plan.

RSS

FEATURED REPORTS

Executive Guide: Storage Heats Up HP

Get the latest on storage technologies that allow IT professionals to better cope with new IT demands. Learn how storage technologies can help you successfully tackle e-Discover, regulatory compliance, green data center initiatives and the data explosion. Get all the details now.

SIP aces basic interop tests

By Joel Snyder , Network World , 05/10/2004
  • Social Web 
  • Email 
  • Feedback 
  • Close
InteropNet Labs 2004

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.


Dialing for VoIP dollars
SIP terms
Chart: Testing SIP interoperability on a large scale

See also:
iLabs introduction
Vendors hit the 802.1X market for access, but security holes remain
Team mixes MPLS and IPv6 for enterprising results



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 AvayaCisco 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.

1 | 2 |  Next >
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to moderator approval. Register here for member benefits.
Have a NetworkWorld account? Log in here. Register now for a free account.
First Name
Last Name
E-mail
Zip Code
IT Buyer's Guides

View All Buyer's Guides