Convergence /

VoIP vendors pass SIP test

Devices based on Session Initiation Protocol offer basic interoperability, but challenges remain for advanced features.

By Betsy Yocom, Kenneth Percy and Uwe Bilger
Network World, 08/27/01

In the first public test of Session Initiation Protocol - the challenger to the more established H.323 standard for voice-over-IP call control - vendors proved they could achieve basic interoperability with minimal tweaking.

But interoperability at more advanced levels proved more daunting. Only four products - Cisco AS5350 Universal Gateway, Indigo Software Proxy Server, Mediatrix APA III-4FXS and SS8 Networks Signaling Switch - achieved basic and advanced interoperability on all levels.

We found that some of the less mature SIP implementations lacked support for certain SIP commands, while some vendors didn't support advanced functions such as sequential and parallel forking and fax support. Some vendors chose not to participate in advanced tests, which were optional, because they didn't support the function or because their implementation wasn't ready for prime time.

The enterprise VoIP update
Open-door policy
Conduct of survey
The changing VoIP landscape (chart)
VoIP pros and cons (chart)
SIP interoperability (chart)

Vendor free for all: See how vendors' products interoperated with others'
(a PDF file).

Jumping through loops

The open SIP interoperability event was held at Miercom's test facility in New Jersey. A dozen vendors (including RADCom, which provided test equipment) offering 18 products participated. Vendors were asked to prove basic interoperability with two reference products - Pingtel's xpressa SIP phones, acting as SIP user agents, and the dynamicsoft Session Management Suite (SMS), a SIP proxy server.

Basic interoperability: User agents

Products tested: Cisco (two products), CyberTel, Difinium, Indigo Software and Mediatrix.

Definition: A SIP user agent is a SIP-enabled end-user device, which could be a phone, a PC, a cell phone or a unified messaging system. SIP supports setting up and tearing down media sessions between user agents, such as "invite" and "ack" (acknowledge).

Test: Vendors had to successfully demonstrate their products could place calls from one user agent to another (and vice versa) and hang up the call.

Basic interoperability: Proxy servers

Products tested: Indigo Software, Mockingbird Networks, NetCentrex, SS8 and Vovida.org.

Definition: A SIP proxy server receives SIP messages from user agents and acts on their behalf in forwarding or responding to those messages. Their function is not unlike a gatekeeper or call agent in other voice-over-IP environments. Also, proxy servers add services, features and scalability to SIP networks. The SIP proxy server typically includes a registration service and a SIP location database, in addition to the SIP proxy.

Test: SIP proxy servers had to demonstrate the ability to interoperate with user agents in a single SIP domain; with other SIP proxy servers in a multiple-hop network; and with public switched telephone network (PSTN) gateways in user agent-to-analog phone tests.

Basic interoperability: PSTN gateways

Products tested: Cisco, Mediatrix, Mockingbird Networks and Nuera.

Definition: SIP-based public switched telephone network gateways provide the interface between a SIP-based voice-over-IP network and the PSTN.

Test: The SIP-based gateways had to demonstrate the ability to process SIP calls to the PSTN; interoperate with other gateways in a multiple-hop network (SIP/IP trunking); and interoperate with gateways via ISDN (primary rate interface) trunking. (An Adtran Atlas 800 central-office switch and a Carrier Access channel bank were used to switch analog calls and trunks.)

Results for all basic interoperability tests

All vendors demonstrated basic interoperability with the Pingtel xpressa user agent and the dynamicsoft SMS SIP proxy server (see graphic).

However, this was typically not achieved out of the box. Some tweaking of code and other technology parameters was usually necessary. For example, during the prestaging, a few vendors had to change their SIP "invite" responses to operate with the Pingtel xpressa phones. Others had to load newer versions of their software to achieve the desired results.

Most vendors were testing with Version 3 of SIP, which was published in May. Differences in interpretations of the specification did arise, and in a few instances we noted backward-compatibility issues between vendors using an older version of SIP and vendors using Version 3. (SIP is supposed to be fully backward compatible with older versions.)

One problem concerned an outdated requirement on a user agent, which user agents based on the newer version of SIP did not recognize. When this requirement was off-loaded to a SIP proxy, interoperability between the user agents was achieved.

Two notable issues concerned lack of support of the SIP "options" request and problems with the SIP "record-route" command on some products.

An options request is comparable to a handshake in which SIP endpoints communicate what parameters are supported end to end and whether the called device is available to accept calls. While it did not interfere with their ability to interoperate functionally, many of the products tested did not support the options request or else implemented it incorrectly.

Problems with the record-route function, which was supported on the dynamicsoft reference proxy server, had a bigger impact. A record-route header is used to indicate routing between two user agents through a proxy server. Operating in record-route mode is important to maintaining "stateful" operation, in which the proxy maintains all subsequent signaling on that call. This signaling includes call detail recording information (used for billing) and firewall control, which are important network functions. Incorrect working of record-route could also prevent proper closing of a call.

According to dynamicsoft, some vendors do not now adequately support record-route because SIP lets you conduct an interoperable user-agent-to-user-agent connection without using a proxy server. A great deal of development is under way in the user-agent-to-user-agent environment, where record-route isn't an issue. It becomes more important, however, in larger networks that deploy SIP proxy servers.

We also assessed the quality of voice calls, which, while not part of SIP conformance interoperability testing, is important from a functional perspective. _All vendors demonstrated "toll quality" connections - assessed by Miercom engineers, based on a mean opinion scoring of 1 (poor) to 5 (excellent). A toll-quality call was rated 4 or above.

Interoperability with each other

After completing basic interoperability tests with the reference platforms, the vendors participated in a free-style event in which they attempted basic interoperability with each other. See these results by clicking here (a PDF file). Intervendor interoperability, again, was widespread although not at 100%.

Advanced interoperability

Four participating vendors - Cisco (via its AS5350 Universal Gateway), Indigo Software (via its Proxy Server), SS8 Networks (via its Signaling Switch) and Mediatrix via its APA III-4FXS - achieved basic and advanced interoperability on all levels.

Cisco could make the same claim for its ATA-186 Telephony Adapter and 7960 SIP phones, too. However, because neither supports call forwarding, that feature could not be tested at the advanced level. (Cisco supports call forwarding on its proxy server, not the user agent.)

Jumping through loops

On the Session Initiation Protocol proxies, we also tested the ability to handle spiral loops, which are necessary to move a call through several forwardings, including from one domain to another, without losing it. Only Indigo Software and Mockingbird Networks attempted the tests. However, differences in opinion among vendors about the proper outcome precluded a clear resolution of this interoperability test. Mockingbird and Indigo Software cited ambiguities in the SIP specification and the test methodology.

Back to top

Problems at the advanced levels concerned inadequate handling of sequential and parallel forking on the SIP proxies; and codec negotiation and fax support on the gateways. "Forking" is when a proxy server sends an "invite" request to more than one location.

We found: Three out of five SIP proxies (Indigo Software, Mockingbird Networks and SS8 Networks) successfully handled sequential forking. A call was transferred by the reference proxy and subsequently rung on three different user agents in sequence - a function that is necessary to successfully deliver "find-me/follow-me" support.

Only two out of five proxies (Indigo Software's and SS8 Networks') successfully demonstrated parallel forking. A call was transferred from the proxy to three different user agents - all at the same time. This feature is employed when a user wants calls to ring, for instance, on a cell phone, business phone and PC at the same time.

We also encountered some problems with codec negotiation. In one instance, a vendor's user agent expected to receive a codec list in all upper case. And when it was received in lower case from the Pingtel reference user agent, the call was set up, but a voice-over-IP media stream was not sent.

Fax support based on the T.38 specification was another issue. Cisco and Nuera demonstrated faxing based on pulse-code modulation, but no vendor successfully demonstrated interoperability based on the ITU-T's newer T.38 fax-encoding specification. Cisco and Mediatrix claim support for T.38, but they did not test it for interoperability. Problems with T.38 fax interoperability, however, are reportedly more often related to the codec implementation than to SIP call-control signaling. SIP defines only the signaling messages, and allows anything, including voice, fax or video, to go into the body of the message.

Conclusion

We found that SIP-based basic interoperability works, and works well. SIP is a relative youngster compared with the ITU's H.323 specification for voice-over-IP call control, and to achieve this level of interoperability so quickly via SIP is impressive.

But there's work to be done on the more advanced functions, and it's apparent that some conformance issues remain to be solved. Still, users can expect rapid development on SIP-based advanced functions as the business cases for implementing SIP become more pervasive.