Developing SIP Products In A Dynamic And Competitive Marketplace

Amir Zmora
Product Marketing, SIP Products
Technology Business Unit
RADVISION  

SIP - A Powerful Protocol

During the last few years SIP has been adopted by many vendors who choose to add SIP-based product to their portfolios. This is primarily because SIP delivers powerful extensibility and enhanced features such as Presence and Instant Messaging to voice and video over IP solutions. Additionally, the ubiquity of SIP enables not only the set up and tear down of voice and video sessions but also enables the implementation of different value added applications.

For all of these reasons SIP is in the position of becoming a widely deployed protocol as the IP communications market continues to grow and evolve.

The Challenges in Developing SIP-Based Products

Nevertheless, there are drawbacks and threats that may jeopardize this potential. SIP interoperability has not yet been finalized and even though there was a great deal of improvement in this respect, there is still a long way to go. Additionally, the protocol and its related Internet drafts are constantly changing. While these changes are necessary to extend the protocol's functionality and sometimes modify existing functions, these new versions are not necessarily backwards compatible.

Since SIP is still an evolving protocol there is intensive standardization work done at the IETF in developing and updating SIP-related drafts. For example in 2002 there were 210 distinct SIP working group Internet drafts, 83 SIPPING working group drafts, and 34 SIMPLE working group drafts (not counting version changes - 00, 0...). This intensive standardization work, which is necessary in order for SIP to provide the functionality expected, makes it tedious for one to follow the evolution of the protocol.

Two Strategies - Go It Alone or Third Party Developers Toolkit

A company wanting to develop different SIP equipment such as SIP phones, Gateways, SIP Servers, etc, will need to make a decision between two strategies - (1) doing it themselves, meaning building in-house a SIP standards-compliant protocol stack as infrastructure upon which they will build their application or (2) choosing an off-the- shelf, standard compliant, commercial SIP Protocol Stack from a third party vendor.

Taking the "do it yourself" approach will require constant follow-up on standardization activity and active participation with the various IETF workgroups in order to be up to date with the hundreds of drafts and updates to the SIP standard. Additionally, keeping the product current with the evolving SIP standard will require additional engineers who to modify and enhance the protocol implementation.

All the above activity and costs are required to develop a standard component (the SIP understructure), and none of the above activities will lead to features that will differentiate the product from its competition. What's a who different set of activities that might not be properly addressed if the development team is busy building the SIP-sack in-house.

On the other hand one could take the second option of using a commercial SIP Protocol Stack. Protocol stack vendors maintain an active role in different standardization bodies, keep their products up to date with changes in the protocols, and attend all market interoperability events such as SIPit.

By choosing a toolkit/SIP stack from a third-party vendor, organizations can free-up their development resources to focus on building applications that have differentiated features, thereby focusing on the company's value proposition, not the base SIP protocol implementation and libraries.

The result of such a choice would be faster time to market and the development of products that are interoperable and standard compliant, and therefore competitive in the market place, giving the company a competitive edge in developing SIP-based solutions, applications and products.

Choosing a Toolkit That's Right For Your Needs

However, one of the issues that companies worry about when choosing an off-the-shelf solution is the possibility of losing flexibility. In order to eliminate this threat one should seek a solution that provides multiple API layers, enabling the user to choose between a high level interface that hides protocol complexity and a lower level interface that enables access to messages and headers as well as monitoring state machine function. The user should be able to seamlessly switch between these levels of flexibility. Providing such flexibility is not necessarily straightforward and therefore requires years of experience in protocol stack design so choose carefully.

The Migration From Home-Grown Solutions to Third Party Toolkits

Looking back at the history of other protocols such as SS7 and H.323, massive deployment of products based on these protocols started only after companies who first built their own protocol implementation began moving en mass to commercial solutions. We certainly saw this in the H.323 development space. Moving from a homegrown solution to a toolkit solution represents a maturity in the market as if moves from experimentation to actual production.

The same trend is starting to be seen today in SIP as the protocol and market matures, driven by market conditions that require increased efficiency and more competitive products. The continuance of this trend towards third party toolkits and support will provide valuable in enabling the accelerated deployment of interoperable and feature rich SIP networks and solutions.