SIP Phones Dirty Little Secret

The dirty little secret of VoIP phones is not
that they dont work. Nearly all of them do, if you just want to make a basic phone call. But if you are a VoIP provider, particularly in the business space, trying to develop a richly featured service that will meet the needs of a wide range of customers, your phones need do more than call completion. It was hoped that VoIP phones, and SIP phones in particular, would be the answer to such prayers: a flexible, programmable minicomputer on an IP network that can be made to do almost any calling feature anyone can dream up. And thats exactly what they are, unfortunately. The very flexibility of the phones, and the standard they are built on, is both their advantage and their downfall.

Most SIP phones make calls, can even put them on hold or forward them, but beyond that, each phone has to be tested and certified rigorously against the service providers network. If there are any changes or upgrades, to the networks or the phones, the testing has to start all over again.

There are caveats on every piece of equipment, says Don Lewis, vice president of partner support for CommPartners, a wholesale hosted-PBX provider based in Las Vegas. We run a 61-point certification program. And CommPartners is not alone. Hosted PBX service providers worldwide are finding that they have to open their own interoperability testing labs in order to qualify phones for their networks.

Even Cisco Systems Inc., perhaps the most established VoIP vendor, cant always be counted on to adhere to strict standards in its phones, service providers say.

We have been talking to carriers about this and IP Centrex vendors over the last six months, and they are all in the same boat, says Jerry Mistrot, program director of tekVizion Labs at tekVizion PVS Inc. They have the bandwidth to support the four or five gold [phone] partners. This means that while they may be courted by vendors seeking testing of the latest endpoint technology, if it does not generate revenue for the IP Centrex provider, they are not going to do it.

New Global Telecom Inc. (NGT), one of the larger wholesalers of IP Centrex, operates its own lab. Among the functions the service provider tests is redundancy. Redundancy is built into everything we do, including the path to the CPE, says Glen Pearson, director of operations. The phone has to have a concept of redundancy, so if it cant talk to platform A, it can talk to platform B.

To help its wholesale customers troubleshoot issues, NGT publishes testing results, telling them how to configure the units and what to expect from each, including their limitations. We include the top 10 questions to ask if it is not working, says Pearson. Eventually a service provider has to draw the line. I can say I support 25 pieces of equipment, but coming from years of technology, I know thats not possible, says Mark Richards, president of VoX Communications, a subsidiary of eLEC Communications Inc., because it really is impossible when you try to make them play together.

SIP FLEXIBILITY

The flexibility of SIP is a double-edged sword that gives phone vendors many opportunities to differentiate themselves, and to frustrate their customers. There are different ways to send DTMF digits when dialed (in-band or out-of-band), different packet sizes, different sampling rates, different codecs, and those are just the basic choices.

SIP brought a lot of people together on the same page in compression algorithms, but there are unfortunate subtleties, even within SIP, so that everyone does things a little differently, says Richards, and it is that little difference that makes the interoperability problem.

There is some established CPE that has been in the market for several years. A lot of people look at Cisco SIP phones and their load as the model, but thats not to say that others have not taken a look and said there is a better way to do it, says NGTs Pearson. That creativity is not without problems. There are issues with some of the newer players, Pearson continues. They dont have quite the experience and resources as Cisco to do regression testing to confirm that their redundancy works. CPE vendors are all looking to get things to market quickly and testing is where the time line gets shortened which is why we have a product lab, he adds.

One area that tends to be problematic, Pearson says, is sending information on how you communicate using RTP (realtime protocol), such as what codec are you going to use, the IP address of the endpoint, how you will handle DTMF. Those are usually the areas that create the problems. The biggest choice is which codec will be used, he says, and two endpoints have to agree on a codec in order to communicate.

Also the nimbleness of newer providers means the fixes come even faster than the new products. If a bug is found in a Cisco phone, for example, you go back to Cisco and they acknowledge the bug and say they will work on it, but it takes time because they are a large organization, says Pearson. With newer providers releasing frequent updates if you have one load, you will get one result, and, if you have a newer load, you will get a different result. NGT often chooses whichever software updates works best for a particular customer.

PART OF THE PROBLEM OR PART OF THE SOLUTION?

Why havent service providers put together their own basic implementation specifications that would standardize to some extent the interface between phones and the network? There are very few of us, its a very competitive space, and we all are trying to do a land grab to move people off PSTN to this new model, says CommPartners Lewis, offering an explanation.

There are some efforts to deal with the issue. tekVizion opened its labs specifically for IP Centrex providers dealing with these issues. The company has the most recent versions of software from leading vendors, such as BroadSoft Inc., Sylantro Systems Corp. and Tekelec Inc. (VocalData), installed and running to test end devices. This is a vendor-driven service, but does provide data on various devices. Service providers also are pushing the IP Centrex vendors to certify more endpoints against their software.

The solution is adhesion to open standards, says Richards. Its one thing to put a standard out there, and another to say I am a very big provider of equipment, and I want to do it my way.

Finally, one industry group, the SIP Forum, is launching an effort to deal with the CPE issue. A new working group, led by Rohan Mahy, chair of both the SIP and SIPPING working groups in the IETF, is developing specifications for endpoints. In addition the group is developing test protocols to verify that CPE meets each specification.

Called feature packs, for now, the specs will choose various SIP primitives, or basic capabilities, that should be included in a phone and how those primitives should beimplemented. Feature Packs do not specify user-visible features, says Mahy, but rather what primitives need to be on the phone and turned on. Some of the IETF specs give multiple choices, but the Feature Packs will specify that each item must be implemented in one way. They will say, You must do B. If you want to do A also, fine, but you must do B, says Mahy. Otherwise it is not compliant. Ensuring that basic capabilities are included and turned on in a phone will go a long way toward interoperability, Mahy says.

The first Feature Pack will be based on the features that are almost always present in established phones and terminal adapters today, Mahy says. The only exceptions are new entrants that implement lot of that but leave one or two things out because they dont understand that they are valuable or their first couple of customers did not require that primitive.

In addition, the working group will develop a series of tests for vendors to use to certify that their products are compliant with a particular Feature Pack. The idea here is, if you say you are compliant with a particular Feature Pack, this Feature Pack effectively represents a brand, a service mark, says Mahy. The forum is not implementing formal certification because that can bring legal entanglements and also discourages inclusion of as many endpoint makers, large and small, as possible. Certification testing is expensive, and small providers or makers of free endpoint software might not be able to afford such testing, he suggests. Whether proposed self-testing will satisfy the needs of service providers remains to be seen; at the least, it will provide a checklist of features so service providers can know quickly what basic capabilities are present in the endpoint.

The plan follows the IETF model for standards, says Chris Gatch, CTO, Cbeyond, a business VoIP service provider based in Atlanta. They publish the specs that the Internet is built on, and there are no tests for being SIP compliant. I think that model is well-established and works.

The SIP Forum effort is way overdue and absolutely fundamental in moving to VoIP service, says NGTs Pearson. Having tools to test against standard is absolutely huge. That always [has] been one of big issues, is how [to] test without throwing people at it; becomes very problematic to be sure that test A is same as test B, and you have an apples-toapples comparison.