Buying a Car Can Be Like Buying a SIP Protocol Stack I recently bought a car. The decision was based on careful evaluation because I had no particular nostalgic allegiance to a specific make or model. I considered the following evaluation criteria: * It had to get me reliably and safely from one place to another. * It had to have a strong engine that was responsive at all speeds, regardless of the load inside the car or the incline of the terrain. All cars have engines, yet not all engines are the same. High quality, aesthetics, and user comfort had to be inherent in its design and manufacture. * It had to fit inside my garage, yet be roomy enough inside to accommodate my family. * It had to have all the features and functions associated with a modern, high-tech automobile. * Each of the controls for those functions had to be visible, so they were easy to use. I prefer an automatic transmission, but occasionally like the power and control of a stick-shift operation. * Of course, it had to have a good brand name. Apart from the fact that I wanted the admiration of my neighbors, I wanted to know that the company had a good track record of standing behind their product - whether it was for upgrades or maintenance. It was therefore easy to bring the shortlist down to just a couple of brands and models. Buying a protocol stack is different from buying a car. However, there are some similar decision parameters for purchasing both products. The Engine and Architecture: The engine is needed to efficiently run a car. Similarly, a protocol stack needs to be well-architected and designed so that its core engine will consistently deliver high performance under various load conditions. In the same manner that a car needs to be sensitive to the pressure on the accelerator, a protocol stack needs to be responsive to the call control/ service application. Trillium's Session Initiation Protocol (SIP) software leverages Trillium's proven and powerful TAPA(r) architecture intelligently to deliver the advantageous capabilities and functionalities that other protocol stack vendors would find nearly impossible to replicate. Following are a few examples of the benefits of using TAPA(r). Achieving Responsiveness: All stacks have operating system (OS) wrappers and efficient APIs that offer a common way for writing codes. One might therefore question the relevance of having a protocol stack architecture. In Trillium's case, the importance of TAPA(r) is demonstrated by its ability to bring in a high amount of responsiveness without the need to repetitively instruct the stack on what to do next. Trillium's SIP protocol stack leverages on TAPA(r)'s "tight" and "loose coupling" mechanisms between layers to enable efficient inter-layer and inter-module interaction. Every time the stack is invoked, it has the intelligence to process all the associated tasks, generate primitives and produce a SIP message. By leveraging on TAPA(r) intelligently, Trillium's SIP protocol stack can be comprehensively implemented in the following functional blocks: * The Call Control Handler * The Transport Connection Manager * The Registrar Server * The Network Server (which includes the Proxy Server and Redirect Server) * A Common DNS Module * A Radix Tree Library * A Common Timer Module * A Common ABNF Encoder/Decoder Module In order to generate a SIP message, all the aforementioned functional blocks are invoked intelligently without periodic intervention from the call-control application. Therefore, system developers can let their call-control application focus on its deliverables instead of spending cycles driving individual tasks that the SIP stack should execute. Not all stacks are implemented this way. Unlike Trillium's SIP implementation, other stacks are often organized as a set of libraries that require the call-control application to frequently interact with the APIs to invoke individual tasks. Returning to the car analogy, I would be irritated if I needed to switch the wipers on-and-off every time they needed to move. Trillium's SIP stack goes a step further by intrinsically generating several SIP headers, such as date/time stamps and accounting information, and essentially allow the "wipers" to move without cumbersome intervention. Database Implementation within the Protocol Layer: TAPA(r) supports a RADIX tree library. Trillium's SIP stack uses the RADIX functionality efficiently to support a database within the protocol layer. This enables the stack to maintain a database of users registered at a "Registrar" server, which facilitates system developers who will no longer need additional database functionality for typical small LAN environments unless there is a large scale of simultaneous user registrations. When they do encounter high-end applications that require a large external database, Trillium's internal database can simply be disabled, thereby enabling an upgrade path. Management of System Resources: TAPA(r) provides elaborate and powerful stack layer management capabilities that where leveraged in the SIP implementation. While at the network periphery, SIP "Proxies" are usually used by network designers to record and maintain extensive call-state information. Closer to the core, these proxies are normally stateless so that they function almost like switches. Trillium's SIP software has the powerful feature of automatically shifting to a stateless proxy, from a stateful proxy, when the system resources start becoming constricted. Call Distribution: TAPA(r) uses Service Access Points (SAPs), which are abstraction points for inter-layer communication. Since Trillium had this inherent capability in the core architecture, it could be used to perform call distribution. All incoming and outgoing calls in Trillium's SIP implementation are handled in a distributed fashion using SAPs. Incoming calls are distributed to the service users in a round-robin basis, while outgoing messages can be distributed across different transport servers, or even across different transport providers. This simple use of Trillium's SIP software's powerful core architectural capability makes it well suited to be used in high-load service provider environments without risking stack performance degradation. Comprehensiveness: Trillium's SIP stack can simultaneously perform different logical functions, such as User Agent, Proxy, Redirect and Registrar in the same instance of the code. System developers can quickly develop products by leveraging on the comprehensiveness of Trillium's SIP implementation and the minimal interaction it needs for call-control applications. For example, Trillium's SIP will perform forking and recursing on its own. Barring elaborate end-user requirements, it would be very easy to compile Trillium's SIP code on a target platform and have it ready to go with an entire Registrar implementation requiring minimal application development. The Basics: Trillium solutions must meet stringent requirements that live up to the high quality customer expect from the Trillium brand. Therefore, we ensured that the SIP software had: * High performance * Compact code size * High quality * Rich Application Programming Interfaces (APIs) * Powerful error handling and debugging capabilities * Tracing * Reporting of alarms, statistics and accounting * And several more. In keeping with Trillium's tradition of being a leading provider of communications software solutions, the company constantly upgrades and supports its products while consistently delivering superior services. So, as you can see, there are after-all some similarities between buying a car and buying a SIP protocol stack. The key is to carefully, dispassionately examine the facts and make an informed decision based on the findings. Written by Akhilesh Daniel Marketing Manager Trillium Digital Systems, Inc. an Intel company TAPA(r) is an acronym for Trillium Advanced Portability Architecture and is a Registered Trademark of Trillium Digital Systems.