In addition to our Converge announcement, there were two more talks at JavaOne where SIP servlet-based converged application development frameworks were announced:

Version 1.1 of the SIP Servlet API introduced the awkwardly named session key based targeting mechanism. This blog explains what it is for, and what a bound box is. As it turns out, they are both pretty useful for a large class of telephony applications.

The SIP Servlet API is originally intended for writing applications to be deployed on network servers, e.g. application servers in SIP architectures.  However, there are no widely accepted standard API for writing applications for endpoint devices. Some applications fit naturally on network servers, but some applications are better suited to be deployed at endpoints. Can we leverage existing SIP Servlet containers and ECharts for SIP Servlets to develop and deploy endpoint applications?

I recently presented a paper Implementing Endpoint Services Using the SIP Servlet Standard at the Fifth International Conference on Networking and Services (ICNS 2009). I concluded that SIP Servlet API is indeed suitable for endpoint applications. The advantages include familiar programming paradigm and existing tools, code re-use, and fliexibility in moving applications from endpoints to servers. As well, the application composition mechanism can be used to support modularity. However, existing containers may have too big a footprint for some mobile devices. As well, containers need to deal with network topology using mechanism such as STUN or ICE. The full paper can be obtained here .

As part of this work, we have created maintenance branches in the SVN repository for the legacy code base for JSR 116. As discussed in an earlier blog entry, we will continue to work on any high-priority bugs in the maintenance branches, but will not add any new features.

• Application Convergence (HTTP and other Java EE technologies)
• Application Composition
• Helper functions for back-to-back user agents

In the few months since the release, a number of commercial and open-source containers have already claimed compliance with the new specification. The new standard has a lot of momentum, and we are anxious to take advantages of all these new capabilities.

Before long, we plan to migrate E4SS to provide support for JSR289 containers. At that time, we plan to stop development on the JSR116 version of E4SS, with the exception of high-priority bug fixes. If you anticipate that this will cause you any hardship, please let us know in the forums.

Discuss this article on the forums. (8 posts)