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.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Download Today
REPORTS
ANALYTICS
Follow 
