Jiplet vs. SIP Servlet

We have received many emails and queries about the topic “jiplet vs SIP servlet” – queries like what are the similarities and differences, what is our motivation for not implementing a standard, etc. So we have come up with this web page that explains this topic in details.

What is a SIP Servlet?
SIP Servlet is a specification created by the Java Community Process (JCP). The SIP Servlet API is specified by JSR 116.  The API has been created by an committee consisting of telecommunications and VOIP system providers like Siemens, DynamicSoft, Nokia, etc. JSR 116 enables application developers to create SIP applications using a high-level Java API and deploy them in a servlet container. It is an extension of the Java Servlet API created by Sun Microsystems and is very popular for web applications. A HTTP servlet is a Java class that handles HTTP requests from browsers. Similarly a SIP servlet is a Java class that handles SIP messages from SIP user agents. The SIP Servlet extends the servlet API provided by Sun.

The SIP servlet and the Jiplet are very similar. A jiplet is a servlet in the sense that it is a Java class that handles SIP messages from the SIP user agents. It does not currently extend the Java servlet API but the API is very similar to the servlet API. However, there are differences between the SIP servlet and the Jiplet API. The most notable difference is that the Jiplet application use the low-level JAIN-SIP API to format and parse SIP messages, route the messages to SIP user agents, manage transactions and dialogs whereas the SIP servlet has its own API for doing the same. We think that the JAIN-SIP API is a more versatile API for this kind of stuff and therefore adopted the JAIN-SIP API instead. Therefore, applications using the jipet architecture will be able to take advantage of all the low-level message handling supported by JAIN-SIP. We do plan to implement the high level message handling API specified by the SIP Servlet API in the next releases.

What are the similarities between the SIP Servlet and the Jiplet API?
When we started this project, we were planning to implement the SIP Servlet API as a framework for very sophisticated SIP application that we want to develop. However, we deviated because we thought that the API is too high level when it comes to SIP message handling and would hinder development of powerful SIP applications. We may, at some point implement JSR116 if there is a large amount of interest. Even at this point, there are a lot of similarities between the two. Namely:

  1. The SIP Servlet and Jiplet classes are very similar. Both have init(), destroy() and do…() methods that has similar usage.
  2. The Jiplet supports scoped variables like the servlet API.  We have added a few additional scoped variables that the SIP Servlet specification does not have because we thought that it would make the jiplet API more useful.
  3. The jiplet supports other features offered by the servlet API including forwarding and logging. The Jiplet logging API is more extensive compared to the Servlet API.
  4. The Jiplet supports deployment descriptors similar to the SIP Servlet. The structure of the XML document is very similar.
  5. The servlet mapping specified by the SIP servlet is identical with the jiplet. The jiplet defines a new concept called context-level mapping to provide better support for hosting.
  6. The security constraint specified by the servlet API is very similar to that of the Jiplet. The jiplet supports container-managed SIP authentication and authorization.
  7. The jiplet will implement support for resource and EJB handling similar to those specified by the servlet API in upcoming releases.

What are the differences between SIP servlet and the Jiplet API?
It is somewhat difficult to compare the two as the SIP servlet is a specification and the Jiplet is a actually a finished software product. The jiplet container comes with a lot of features that are not part of the SIP Servlet API specification because the API is primarily geared towards defining the API rather that the container implementation. Indeed, it will be more appropriate to compare a SIP Servlet implementation with the jiplet container. Our goal is to refine the jiplet container to make a container of choice for SIP server-side development using Java and the J2EE environment. From the first release of the software, the jiplet container supports plugging in the container as a part of the JBOSS J2EE server. In general the differences between the two are:

  1. The SIP Servlet API specification (yes, even the specification) is distributed under a commercial license whereas the Jiplet Container is released under the Apache Open Source License. The SIP Servlet specification license puts in a lot of restriction of how the specification is implemented and used. The Apache license, on the other hand, gives you complete freedom to download, user, modify, sell or do whatever you want.
  2. The SIP Servlet API specifies its own high-level API for formatting, parsing, sending and receiving SIP messages. The jiplet container uses the JAIN-SIP low-level API for the same. We think that the JAIN-SIP API is a more powerful API (although it is more difficult to learn) and is more suitable for powerful SIP applications.
  3. If you are using SIP servlets, you can switch containers. That is, instead of using a container from vendor X, you can use a container from vendor Y and your application will remain unchanged. That is not the case with the jiplet container since the jiplet container does not implement a standard API. SIP application vendros switch containers for two reasons: (1) price and license restrictions of the container and (2) the performance of the container. The jiplet container is FREE and uses open-source license and you cannot beat that. In addition, you can easily switch the underlying JAIN-SIP stack used in the jiplet conatiner if you need improved performance (although we think that the NIST JAIN-SIP stack we use is a high performance stack) because that is where most of the performance-related issues are involved.
  4.  In our opinion, the SIP Servlet API is somewhat weak with regards to the support for hosting. Although the Java servlet specification has a reasonable support for hosting (multiple contexts)  in the web environment, it may not be sufficient for the telecommunications environment and the SIP servlet specification does not extend this. We envision that with increasing popularity of SIP, there will be application service providers who will host SIP servlet (or jiplet) for their customers. In the upcoming releases, the jiplet container will implement a comprehensive set of hosting-related features including robust security mechanisms, isolation of applications, application quotas, resource limits, etc.
  5. The jiplet container comes with a JMX interface for managing the container from an external management application whereas the SIP servlet does not define any management interface leaving it open to the implementation.
  6. The jiplet container define realms (or authentication and authorization databases) whereas the SIP servlet leaves this open to the implementation.
  7. The jiplet container comes with a web-based management console for dynamically managing contexts and realms. The SIP servlet leaves this open to the implementation.
  8. The jiplet container logging API uses LOG4J whereas the Java servlet API comes with a somewhat inadequate logging mechanism. LOG4J support printing of logs of various severity levels including traces. It also defines how the log messages are handled – sent via e-mail, saved to rotating log files, etc.

Where is the roadmap of the jiplet project?
We do not have any roadmap as such but we do have a general direction.

  1. We will receive input from the SIP user community as to what features they want to see. Depending on the interest level, we will add them to the jiplet container. We would like the jiplet container to be a community project rather than implementing a spec formulated by a committee.
  2. We will accept contributions from the SIP software community. Since the jiplet container is open-source, any software developers can download and modify the software. They can add new features and contribute it back to the project. You do have to follow certain standards and guidelines and it entirely up to the discretion of the lead developer as to whether we accept the contribution.
  3. We will monitor SIP Servlet and other leading projects and try to keep up with the features these tools add.

In short, we want to build the jiplet container in the open-source model of software development.

VN:R_U [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Leave a Reply