Polycom KOs Proprietary VoIP Woes

Besides the six participating vendors, we invited Alcatel, Avaya, Cisco Systems, Nortel Networks, Pingtel and 3Com. Alcatel told us it does not make a SIP phone, though it does provide SIP functionality in its OmniPCX Enterprise PBX. Pingtel is an early adopter of SIP with its Expressa product. In fact, Pingtel's phones were used at The Hotel Commonwealth, Boston, where the company partnered with Alcatel (see "SIP Shows Some Hospitality,"). However, Pingtel's phones didn't meet our requirement for two Ethernet ports, though the company did say it would have a product with those ports by September. 3Com said it was anxious to participate, but didn't have a product meeting our requirements ready in time for our tests. We never got definitive answers from the others on why they didn't want to play.

We used BroadSoft's BroadWorks SIP services for our testing. This gave us the opportunity to partner with a leading SIP vendor for a reference platform for interoperability testing. BroadSoft employs a B2BUA (back-to-back user agent) for SIP signaling, meaning the proxy server stays available throughout the call and also for the termination of the call. Without B2BUA, the proxy server would drop out of the picture once the initial connection was completed. With B2BUA, we gained centralized tracking of the call for call-detail recording.

The most important thing we can say about these phones is that they worked as well as any quality business-class phone could be expected to work. We made phone calls easily and with confidence. In fact, the many hours of calls that we made during our tests--to vendors and co-workers alike and including several teleconferences--were made on SIP phones. It's also worth noting that our SIP server and gateway to the PSTN were located at BroadSoft's site, meaning that all call signaling and audio had to go across the Internet. Normally these services are delivered over a more private controlled network.

Interoperability among the phones was a key consideration during testing. What's the point of standards-based equipment if you can't mix and match? Although we were pleased that all the phones passed these interoperability tests with flying colors, we can't say we were surprised: Interoperability testing has been going on for more than four years. This testing has been closed to the public, but the 12 "SIPit" events held by the SIP Forum have given vendors the opportunity to test and re-test in a nonthreatening environment.

Although we told all the vendors that we would conduct interoperability testing, we didn't share any details. That obviously didn't deter the six that came to the party, and we can only speculate on whether it contributed to our high no-show rate. We did encounter a few glitches with some of our testing, but we simply captured the packets involved using Network Associates' Sniffer Voice analyzer software and sent them to the vendors. All came up with fixes in a couple of days. Fortunately, we didn't have to do much of this, and the result was that all the products earned perfect scores for interoperability.

We are also glad to report that another standard key to VoIP phone deployment, 802.3af PoE, was a cakewalk for all the phones. This is serendipitous timing for phone vendors because most network equipment vendors are rolling out 802.3af-compatible switches. Powering the phones in this manner means you need only one cable plugged into the phone. It also means that it's possible to provide UPS for the phones from centralized locations, such as wiring closets.One quibble: With all phones, we had to hit a send button after dialing a number. Anyone who's used a cell phone will find this familiar, but it is an extra step. Normally, a PBX has a dialing plan where number patterns and area codes can be programmed to alert the PBX when it has the right combination of numbers to make the call. We take for granted the fact that we just dial the number, and the phone knows what to do with it. SIP works by sending an Invite message only after it has all the digits of the phone number that is being dialed. The Polycom, ipDialog and Mitel phones can program a dialing plan into the local phone so that it would send the SIP Invite after it received a valid number, eliminating this extra step. Zultys says it plans to add this capability by the end of the year.

All the phones except the ipDialog SipTone had buttons for multiple call appearances, which makes it possible to have multiple lines associated with the same phone, and most had some combination of buttons for the most common features, such as speakerphone, hold, transfer, forward and volume control. This made accessing the most-often-used features as easy as pushing a button and saved us from having to navigate through the ubiquitous LCD screens.

Unless a gateway is involved, all the audio in a SIP call will go directly between the phones. This requires that the phones negotiate the correct codec to use via the SDP (Session Description Protocol) that SIP uses for this purpose. All the phones support G.711 codecs. G.711 provides PCMU (Pulse Code Modulation), conventionally used to digitize human speech in legacy, digital TDM trunks. In theory, PCMU requires 64,000 bits per second of bandwidth. In reality, we saw by watching our analyzer that it actually took about 80,000 bps to packetize the call into Ethernet and IP.

All but one of the phones also support the G.729 codec, which has the advantage of using a lot less bandwidth (Zultys plans to add it by the end of the year). G.729 codecs compress the 64,000 bps down to 8,000 bps. While we didn't detect a difference in sound quality with G.729, it did add significant latency due to the compression and decompression functions. This isn't necessarily a problem--unless there are additional sources of latency caused by your network. If latency gets too high, it can have significant impact on the quality of the conversation.

SIP phones have a lot of functionality, all of which must be managed. For example, in a typical enterprise setting, every phone needs the name of a SIP proxy server set in its configuration. The proxy server is used to route calls. In theory, SIP lets you make calls in a peer-to-peer mode without the use of a proxy server, but this requires that the caller maintain the location of all the other phones. It works fine for calling a few friends on the Internet, but it doesn't scale.

Each phone also needs the address of a registration server, so that it can maintain its presence and status on the network, as well as such mundane items such as IP address and subnet mask, for example. Although it is possible to enter a lot of this information on the phone manually, we found it very labor-intensive and tedious. Because the phone interface is optimized for the end user (as it should be), administrative functions were usually buried under layers of submenus.The most scalable solution is to download configurations remotely via TFTP (Trivial FTP). DHCP plays a role here. Along with the IP address, gateway address and DNS servers, we used DHCP to inform the devices of the TFTP server address. The phones could then use this address to download a configuration. TFTP could also be used to upgrade the software image. A common way to identify unique configurations for each phone is to tie it to the phone's Ethernet address. It's possible to have a file on the server with the Ethernet addresses as part of the name, which makes the association.

We found troubleshooting more difficult with VoIP phones than with legacy devices. First, messing with any one of the configuration options often caused the phone to malfunction. The phones can lock down these settings with a password. Also, the data network that the phones use for transport can cause problems. For example, if there is too much congestion, call quality will suffer.

All the phones except the Zultys provided access to major configuration parameters via a Web interface, which we used to quickly verify the configuration. Also, the Polycom phone provided a number of useful statistics available from the display. We checked on packet jitter, packet drops, network utilization and even the CPU utilization of the phone.

Still, we would have liked even more troubleshooting options for the phones in general. For example, it would have been useful to be able to access the statistics that the Polycom phone kept remotely.

We were also interested in the pricing for the phones, because standards encourage competition. Prices ranged from $250 to $440, but keep in mind that these are retail, and discounts are common. Also, these prices include all software licensing necessary to make the phones operate. If you look at our features chart online, you'll see there are no hidden costs for additional software. That's the way it should be.After months of crystal-clear calls, with only a very rare pop, the range between first and last place was less than 0.5 percent, with three of the five tying for second. Still, only one can emerge victorious, and Polycom's SoundPoint IP 600 took our Editor's Choice award. We liked the SoundPoint's rich feature set, and we found it to be the easiest to use of all the phones tested.

Polycom, while best known for its videoconferencing products, also provides superior conference phones. Anyone who's ever used one can attest to the quality of the speakerphone. We were impressed with the phone's ease of use, and the features that made it possible to customize it for individual preferences. We also liked its diagnostic capabilities. This combination of features and functionality helped Polycom edge out Mitel, Siemens and Zultys for our Editor's Choice award.

The phone's layout is logical, intuitive and functional. When a call is received, the screen displays the phone's number, along with context-sensitive options for the four additional buttons along the bottom of the screen. And these options always seemed to make sense. For example, when receiving a call, the hold, transfer, end call and conference buttons were displayed. Those buttons were also available as hard keys on the phone, but we found ourselves taking our cues from the screen.

Six lighted buttons on the left of the screen can be used for call appearances or user-programmable speed-dials. It was a cinch to add numbers or even feature codes with labels that appeared on the display next to the corresponding buttons. The four cursor movement keys, along with an enter key (a check) and a delete key (an x) made this an intuitive process. For example, we were able to make a call pickup button that dialed *98, the number that the BroadSoft proxy server uses to pick up calls from phones in a call-pickup group. Eight additional keys are available for conference, transfer, redial and other functions.

Polycom had the best diagnostics, but we could only gather data locally, at the phone (all the phones were lacking in this area). Polycom also claimed to be able to send and receive instant messages, though the phone couldn't process messages sent from Microsoft clients.

SoundPoint IP 600, $435. Polycom, (800) POLYCOM, (925)924-6000. www.polycom.comMitel is one of only two legacy PBX vendors that participated in our tests (Siemens is the other). Mitel's 5055 is a no-nonsense business-class phone, and it might have scored better if it had some of the features that the company plans to add later this year, such as better diagnostic capabilities.Mitel's phone looks exactly like a typical business-class phone, with no hint of its IP talents. It has a two-line LCD display and buttons out the wazoo: There are rows of buttons across the top and down either side. There are four lighted call-appearance buttons, four buttons to control the display, and seven programmable buttons. In addition, the 5055 has extra buttons for speakerphone, transfer, hold, muting and headset.

Although it's display control was not as advanced as Polycom's, the Mitel phone was easy to operate--anyone who has used a corporate phone will be comfortable with it. As with the Polycom phone, the first line is activated as soon as the headset is taken off the hook. All the phones have message-waiting indicators, but Mitel's is the biggest and brightest--you could probably use it as a warning beacon for the local airport. The 5055 has only a half-duplex speakerphone, but Mitel says it plans to make full-duplex functionality standard by the end of the year.

We could use the typical TFTP options for downloading new software and configurations, but the 5055 doesn't include any diagnostics capabilities. Again, Mitel says it plans to add remote- and local-access to call-quality statistics by September.

Mitel is a well-known player in the PBX market, but it sells only one SIP PBX, the 3050 ICP, and that supports a maximum of 10 phones. The company says it will add SIP support to its higher end 3300 ICP in 2004.

Mitel Networks 5055 SIP Phone 2.0, $350. Mitel Networks Corp., (800) 648-3579. www.mitel.com

The functionality and ease of use of Siemens' optiPoint 400 were comparable to that of the Mitel 5055. The $440 retail price of the Siemens phone was highest of all the devices tested, edging out Polycom's $435 offering and a lot higher than Mitel's price of $350.On the bright side, if you're moving from H.323 to SIP, the Siemens phone supports H.323, though it does require a different software image. Featurewise, the Siemens phone can complete numbers dialed in memory and is the only phone besides the SipTone to support the G.723 codec. G.723 provides even greater bandwidth optimization than G.729, with 6,000 bps necessary to carry the audio. Of course, the flip side is that G.723 codecs also can incur even more latency than G.729 codecs thanks to higher compression rates.

It was easy to make calls with the optiPoint. It has a 48-character by two-line display, with most navigation done via two arrow keys and a Check key. Siemens did a nice job making navigation intuitive with this limited number of keys.

optiPoint 400 standard SIP 2.2, $440. Siemens, (800) 765-6123. www.siemensenterprise.comZultys tied with Mitel and Siemens for second place, but if you need encryption, the ZIP 4x4 is your only choice. It's capable of encrypting the audio stream when used with another Zultys phone.

The 4x4 sports 15 lighted feature keys, four of which are devoted to call appearances. None of the buttons on the Zultys phone are user-programmable, but we could make a number of them serve dual purposes through the use of a color-coded function key that acted as a shift key. The phone lies flat, but the LCD screen, which displays three lines of 20 characters each, can be tilted.

Zultys, like ipDialog and Snom, appears to be committed to SIP; the company offers SIP-based PBXs--the MX 1200 and the smaller MX 250--and uses SIP as the signaling protocol for all its products. Zultys' phone has some unique provisioning options, but they require that the phones be used with a Zultys PBX. For example, it's possible to create configuration files on the MX (which also functions as a TFTP server) by reading in each phone's MAC address with a bar-code reader. The company also claims that it can do a SIP-compatible "push" install of new software using a Zultys PBX. This means that you could schedule to reboot the phones, for instance, at 3 a.m., without end-user involvement.The 4x4 was one of the more expensive phones tested, coming in at $400 retail. For that price, though, you get five switched Ethernet 10/100 ports, including the port used to connect the phone to the network. The phone was also the only one to come with its own headset.

However, the 4x4 is the only phone lacking a Web interface, something Zultys says it will add by year's end, along with support for the G.729 codec. This meant that we had to make configuration changes on the phone itself or edit configuration files.

Zip 4X4, $400. Zultys Technologies, (408) 328-0450. www.zultys.com

The Snom200 is a small, low-profile phone without as many bells and whistles as its rivals, but it's one of the least expensive devices tested, with a retail price of $289. The Snom200 includes five lighted call-appearance buttons that can be reprogrammed for other functions. In addition, it sports a scrollable menu, as well as keys to control the speakerphone and to conference and redial.

Like the Siemens optiPoint, the Snom200 supports H.323, though it does not implement QoS (Quality of Service) support at Layer 2 (Layer 3 QoS is present, but that doesn't help the phone-to-wiring closet connection). We consider this a major weakness for a phone that is sharing voice conversations with data from a PC, and Snom's score reflected it.

However, we decided to give Berlin-based Snom a break, in part because it has some unique solutions for dealing with NAT (network address translation). The company says its SIP phones support both UPnP (Universal Plug and Play) and STUN (Simple Traversal of UDP through NAT; RFC 3489). We tested the Snom200's UPnP compliance, and it worked well (see "SIP and NAT: Not So Perfect Together,").Snom200 VoIP phone, $289. Snom Technology, (972) 745-1221. www.snom.comIPDialog is the only vendor in this review solely dedicated to producing SIP-based phones, and it offers the least expensive device, at $250 retail. However, the SipTone also has the skimpiest feature set of the phones we tested. For example, it has no extra call appearances, and only the minimum feature keys. It does include volume-control keys, but you're out of luck for one-button call transfers or conferences. Another big deficit is that the SipTone lacks support for Layer 2 or Layer 3 QoS.

On the plus side, the SipTone supports all three major codecs, and ipDialog says it supports silence suppression for every one of them as well (silence suppression helps conserve bandwidth by transmitting only audio data).

SipTone Ethernet Phone 1.2.0, $250. ipDialog, (408) 451-1430. www.ipdialog.com

Peter Morrissey is a full-time faculty member of Syracuse University's School of Information Studies, and a contributing editor and columnist for Network Computing. Write to him at [email protected].

Post a comment or question on this story.

For our phone-to-phone call testing, we used BroadSoft's BroadWorks product for the SIP infrastructure. First, we called every phone from every other phone. We also tested interoperability with Microsoft clients.For our three-party conference test, we made a call from the PSTN through BroadSoft's gateway, and attempted to transfer the call to every other phone.

For our message waiting indicator test, we left voicemail messages and then read them to see if the indicator turned on and off correctly. We also tested each phone's ability to check BroadSoft's voice-mail product.

Finally, for our call-pickup test, we put all the phones in a "call pickup group" using BroadSoft's Web-based provisioning software. We then called one phone in the group and attempted to pick up the call from each of the other phones by dialing the associated call-pickup *98 feature code.Network Address Translation presents a number of problems for SIP and VoIP, stemming from the fact that NAT addresses are not routable on the Internet.

This doesn't stop clients with NAT addresses from accessing a Web server using a simple protocol like HTTP, for example, because the NAT device substitutes its own external, routable return address before transmitting to the Web server. The Web server then sends a response to the NAT device's external address. Because the NAT device keeps track of the initial request, it knows to which internal NAT address to forward the packet when it arrives.

The same process, however, does not work for SIP, because of the way SIP deals with IP addresses. When a SIP client initiates a session with another client or server, it puts its IP address in the application layer of its initial request. This is because SIP is designed so that it can reroute responses to different paths than the requests (see "It's Time To Take a Look at SIP," for an in-depth explanation of the SIP protocol). When the receiver is sending back its response, it uses this return IP address (which it gleans from the application layer of the initial request) as the destination address of the IP packet that it sends back.In contrast, HTTP or SMTP rely on the source address in the IP layer for the response that is returned. This creates a problem if the client initiating the session is using NAT. The NAT address will be placed in the application layer when the client initiates the session, and the receiver will attempt to use this NAT address as the destination IP address of the response.

But because NAT is not routable, the response will not arrive. Even though a NAT device is smart enough to substitute its own external, routable address in the IP layer of the packets that it transmits, this intelligence does not extend to substituting its address in the application layer.

The other problem NAT poses is that, by default, it's impossible to initiate any connectivity from the Internet to a device with a NAT address. Although this has some security benefits, it can create confusion. If the Web server in the above example had a NAT address,

a client on another network would have no way to direct a request to the server because it would be using a nonroutable IP address. One way to solve this problem is to configure the NAT device manually to send all requests on Port 80 to a particular device on the internal NAT network. The external IP address can then be published as the address of the Web server. But this approach requires a high level of expertise to configure. In addition, it doesn't scale well if a lot of devices are involved. This is a big problem with SIP phones on a NAT network--they won't be able to receive calls.

Fortunately, better solutions exist:• Far-End NAT traversal: This deals with the NAT problem on the provider's network and is your best bet to use with typical home users. It deals with both of the problems outlined above and can eliminate most support issues.

A Far-End NAT traversal product resides on the same network as the SIP Proxy and intercepts all SIP messages before forwarding them to the SIP Proxy. It solves the return-address problem by putting the IP source address into the SIP header, which the proxy server looks at to determine where to send its response. The proxy server now sends its response to the NAT gateway's routable, external IP address, which then forwards it to the client.

The other problem is getting a SIP Invite message into a NAT gateway to initiate a call to a phone inside the network. If an external device wants to initiate a call to a device with a NAT address, it cannot route the request to the target device's private address. This can be fixed by having a device on the provider's network maintain an opening, sometimes called a pinhole, through the NAT device. It can't be done, however, until traffic is first initiated from inside the NAT network. Once that happens, a NAT traversal product on the ISP's network can trick the NAT device into maintaining an opening for return traffic for the specific pair of IP addresses and ports. It can then use that opening to initiate a connection back into the network. This is done by sending SIP notify messages into the network frequently enough to maintain the opening, or by causing the SIP client to register often enough to maintain the opening. BroadSoft provides this service using NAT traversal products from Kagoor Networks and Acme Packet.

• Universal Plug and Play: UPnP is a standard based on an industry consortium backed by Microsoft, Intel and others. It is designed to let devices in a home network discover one another's capabilities and inform one another of necessary configuration changes. All devices on a home network have to be UPnP-enabled, of course. In our scenario, an IP phone could discover the external, routable IP address of a DSL or cable-router NAT device and use that address in the SIP layer when it constructs an Invite message. It could also instruct the router to open up an IP address/port to allow access into the network from a particular SIP proxy server. The Snom phone we tested had this feature and could communicate with the NetGear NAT device on our network and find out its external address. The phone then used that external address in the SIP layer when it initiated a request, such as an SIP Invite. It also sent a message to the router to open up access from the proxy server's address so that calls could be initiated from outside the network.

• Simple Traversal of UDP Through NATs: STUN, which requires that the client understand STUN and that there be a STUN server available outside of the network, works by having the client send packets to the server, which looks at the source IP address that is used. It then informs the client. The client compares this address with its local IP address, and if they are different, can conclude that it is on a NAT network. It can then use the external IP address discovered by the STUN server in the SIP header.• Application Layer Gateway: Using an ALG involves building intelligence about specific protocols into a firewall so that it can make the necessary adjustments. For example, the ALG can rewrite the IP address in the SIP layer with its external, routable address before sending it out. It can then keep track of return packets and let them through. It also can be configured to allow specific access to devices behind it.

• Manual configuration: Some NAT devices allow manual configuration. In this case, it is possible to put in rules that would allow incoming traffic from the IP proxy's address on the SIP port (5060). However, this requires some technical expertise and isn't very scalable. It also doesn't solve the problem of NAT address as the return IP address. You would not want to ask a telecommuter to implement this solution nor attempt to support it remotely.Read more about Vonage and easing into a VoIP-SIP deployment

Our interview with The Hotel Commonwealth's Stewart Randall and Timothy Kirwan

You'll find our features charts containing detailed information on each of the phones we tested here

Infrastructure white papers and research reportsInfrastructure books

SIP Forum

"The Word Is Out on Instant Messaging"

"IBM's Notes Upgrades Focus On Collaboration, Costs, Stopping Spam"

"Voice Over IP Means Business""WorldCom Pins Hopes for Recovery on IP Services"

R E V I E W

SIP Phones

Sorry,
your browser
is not Java
enabled

----------->

Welcome to

NETWORK COMPUTING's Interactive Report Card, v2. To launch it, click on the Interactive Report Card ® icon

above. The program components take a few moments to load.

Once launched, enter your own product feature weights and click the Recalc button. The Interactive Report Card ® will re-sort (and re-grade!) the products based on the new category weights you entered.

Click here for more information about our Interactive Report Card ®.