It's widely recognized that the telecommunications industry is riding the crest of change and evolution on the back of new access technologies such as 3G, GPRS, and Wi-Fi. Such IP-centric access mechanisms must also be considered in conjunction with the emergence of feature-enabling technologies such as VoIP, instant messaging, and presence. A whole new converged telecommunications world is emerging that requires an appropriate complementary IP-based infrastructure as opposed to the legacy, circuit-switched solutions of the past.

The disruptive effects that such an evolution is having on telecommunications service providers' revenue streams are also worth mentioning. The inevitable migration to IP-based services that can support converged applications has introduced a massively competitive marketplace where new network specialists such as Skype (www.skype.com) and Freewire (www.freewiretv.com/) are eating away at voice-related revenues and turned "voice" as a service into a commodity. As a result, to stay competitive, Service Providers are looking to alternative service offerings that can be developed in a relatively short space of time but that can fully utilize the flexibility of packet-switched networks, which also translates to new opportunities for Java developers.

The Session Initiation Protocol (SIP) protocol has emerged as the de facto standard for enabling converged voice and data applications in telecommunications. SIP servlets provide a key component to rapidly developing next-generation converged services, and SIP servlets will become more important as the next-generation technology emerges.

In 2003 when the SIP Servlets 1.0 standard was published (JSR 116), it soon became apparent that a technology was emerging that would change the telecommunications industry. SIP Servlets 1.0 provided the foundation for an exploratory technology step that allowed the rapid development of SIP-based telecom applications that would enable VoIP services as well as converged voice and data applications.

Using the well-established servlet model from J2EE, the adapted SIP servlet container inherits important functionality such as lifecycle management and configuration. SIP Servlets 1.0 also provides an appropriately abstracted API for SIP Servlet developers. The complexity of SIP is therefore abstracted away, providing functionality that doesn't require in-depth knowledge of the protocol's intricacies. The SIP Servlet 1.0 specification and API forms the basis of many application servers used in early IP-based telecom services deployments. Since it was first introduced, the technology has been widely deployed in a variety of both fixed and mobile networks, especially as part of the IP Multimedia Subsystem (IMS) reference architectures defined by the 3rd Generation Partnership Project (3GPP).

SIP Servlets 1.0 was a revolutionary step in providing a platform with application-level constructs. But as with any evolving technology, requirements and industry demands are extremely dynamic and it became apparent that SIP servlets needed an overhaul to maintain its technological advantage.

The Java Community is currently defining the newest-generation SIP Servlets 1.1 (JSR 289). In January 2006 an expert group was formed to deliver SIP Servlets 1.1 with the goal of producing a technology that built on the success of SIP Servlets 1.0. SIP Servlets 1.1 (JSR 289) would also forge closer technological alliances with J2EE and provide an appropriate vessel to carry SIP into NGN (Next-Generation Networks) and beyond. The objective was to overcome the problems encountered since the introduction of SIP Servlet technology. The result is the upcoming JSR 289 release.

Why a New Version?
It has become clear that the functionality of SIP Servlets 1.0 has been outpaced by the rapid evolution of the VoIP industry, but where exactly does it fall short? First, some background and an explanation of the problems that have been identified as a result of experiences with both SIP servlet container and application implementations.

As a starting point, the SIP Servlet 1.0 specification was a particularly revolutionary technology. Like so many early representations of technology, the fundamental concepts were good but continual refinement is required to improve the quality of the solution. The original text in the SIP Servlet 1.0 specification doesn't provide the explicit guidelines that container developers need to deliver consistent operations across a range of vendor platforms. Stronger language throughout the document is required to set tighter boundaries in a similar style to standards bodies like the Internet Engineering Task Force (IETF). The areas of confusion introduced into the specification have led to a wide variety of implementation variance. As a result, there is little chance of inter-vendor interoperation when porting applications between container implementations.

Application developers have also uncovered key areas in the SIP Servlet API that need to be tailored to provide more assistance. For example, a Back-To-Back User Agent (B2BUA) is one of the most commonly used constructs implemented using the SIP Servlet API. B2BUA involves two separate SIP user agents bound together to act as a single signalling entity (as opposed to a pure proxy). Most SIP applications written for the telecom industry today have some form of B2BUA functionality (e.g., pre-pay, conferencing). In version 1.0 of the API, the process of implementing simple B2BUA functionality was quite cumbersome when you consider how frequently it was used. This was primarily due to the complexity of managing the protocol sessions and state associated with B2BUA functionality.

As with HTTP servlets, SIP servlets have the concept of Sessions, which provide association for multiple actions. SIP servlets have application sessions that act as an umbrella for a specific application instance. Zero or more associated protocol sessions (SIP Sessions) can exist in an application session that loosely map to a SIP call. When a SIP servlet container receives a new SIP request, an application session and SIP session are automatically created. In certain circumstances, say a conferencing application, it's appropriate to associate new SIP protocol sessions with an existing application session instead of creating new sessions. In SIP Servlets 1.0 this is achieved using an Encode URI mechanism. The encoded URI is included in the SIP message and when it arrives at the SIP servlet container, it's routed directly to the appropriate application instance. This may seem like a useful mechanism but it has proven to be extremely troublesome and difficult to use (e.g., for distributing an encoded URI). Using an encoded URI also has the added drawback of skipping application composition. When the SIP servlet container gets an encoded URI in a SIP request, it routes the message directly to the targeted destination without evaluating the request for alternative application processing. This can create problems in application composition where, for example, you might have a security or prepay application that must be invoked first.

Convergence is a word often used in association with SIP servlets, and it's usually incorrectly conveyed. SIP Servlets 1.0 correctly introduced the concept of convergence, but that definition only covers half the story. It only defines and discusses convergence of SIP servlets with HTTP servlets that coexist in a single monolithic solution. While useful for some simple applications, this type of deployment isn't appropriate for large-scale deployments where integrating with high-throughput J2EE applications requires a clear boundary to separate performance and maintenance. The original SIP Servlet specification clearly lacked the ability to externally access SIP servlet resources within a Service Oriented Architecture/J2EE environment. This prohibits certain architectures and limits integration between different IT infrastructures and core telecom network infrastructures.

One of the most important and powerful features of SIP servlets is the application composition model. Application composition refers to the ability of a SIP request to visit multiple servlet applications as part of a larger combined solution or service. SIP Servlets 1.0 uses much of the functionality inherited from HTTP servlets, where incoming requests for service are judged on the XML configuration contained in the deployment descriptor. On reflection, this kind of static, hard-wired, and complex configuration of applications isn't entirely appropriate for the real-time world of telecommunications application composition. A more flexible approach is needed that allows a dynamic decision-making process; possibly a process based on related activities and external triggers that have occurred (e.g., access to external data source).

SIP is now an extremely mature protocol with a plethora of extensions and modifications. SIP Servlets 1.0 is based on one of the later versions of RFC 2543, which was later made obsolete by RFC 3261. It's understandable that, since the creation of SIP Servlets 1.0, the requirements demanded of the protocol have progressed. Over the past few years a number of new SIP methods have been introduced (e.g., UPDATE) along with extensions that provide important functionality (e.g., the SIP PATH header in RFC 3327). These modifications need to be incorporated into future releases of the standard to provide the level of functionality required for today's telecom VoIP applications. It's also fair to say that SIP's evolution has led to a number of mismatches in the SIP Servlet API that need to be resolved.

Clearly, there are a number of key areas in the SIP Servlet API that need modification too. An expanded list of all the requirements, both large and small, clearly indicates that JSR 116 was ready for a major overhaul.

What's New in SIP Servlets 1.1?
Given the advances in telecommunication applications, it was clear that SIP Servlets 1.0 was ready for a spring cleaning. SIP technology had been widely adopted in telecommunication architectures and with appropriate modifications would provide a central core standards platform. However, to address some of the shortcomings in the initial standard, there are key features that will appear in SIP Servlets 1.1 because of the problems identified.

As we said, the application composition model used in SIP Servlets 1.0 wasn't flexible enough to support emerging telecom applications. To overcome these hurdles, SIP Servlets 1.1 will incorporate a radically new application composition and routing scheme that provides additional functionality and flexibility. Figure 1 shows how applications are composed and routed in SIP Servlet 1.0.

The request enters the SIP stack (1) and is passed to each application loaded in turn (2-4). When a SIP request is passed to an application, it's validated against the deployment descriptor XML file. The container will check to see if the specific application (a SIP Servlet Archive or sar file) is interested in servicing the SIP request. If it does it's triggered, but if the application isn't interested it's simply passed to the next one in the chain.