The SIP Servlet API enables applications to perform a complete set of SIP Signaling functions. The SIP Protocol specification defines different types of high level SIP roles, namely User Agents (UAs) which include UA Clients, UA Servers, and Back-to-back user agents (B2BUAs). The SIP protocol also defines the roles of Proxies, Registrars, and Redirect Servers. The SIP Servlet API is a allows any of these roles to be coded as SIP Servlet application.

SIP is an extensible protocol, which is one of its strengths. Applications can extend the base protocol to add new features as necessary. In fact, there are a number of RFCs that define extensions to the base Internet Engineering Task Force (IETF) RFC 3261 SIP: Session Initiation Protocol. The SIP Servlet API is also designed to allow developers to easily extend functionality. This is accomplished by dividing up the SIP processing between the container functions the applications. Most of the base protocol processing is performed by the container, leaving some of the higher level tasks for the applications to perform. This clever division is what lends a great deal of power and flexibility to the SIP Servlet API.

The SIP Servlet container handles "non-application-specific" complexity outside of the application code itself. Concerns like network connectivity, protocol transactions, dialog management and route processing are required by virtually all applications, and it would be enormously wasteful and error-prone to require each application to implement this support. With the SIP Servlet API, all of these tasks are managed by the container, leaving applications to provide higher level functions.

As an example, consider a SIP Proxy component:

1. A SIP Servlet within the SIP Servlet container receives a SIP request object and proxies it. A SIP Proxy must add its own Via header to the request; the header is required by the base SIP protocol to indicate which entities were traversed by the request. The Via header also stores the branch identifier which acts as the transaction identifier.

   Because the maintenance of transactions and their associated state machine is maintained by the container, it is the container that actually inserts the Via headers into the SIP Request.

2. The downstream SIP entity which next receives the request sends the response back along the path built up by the SIP entities in the path of the request that have inserted themselves into the Via or Record-Route headers.

3. The container gets the response, removes the Via header it inserted in the original request and then processes the response. The application code does not need to manage the Via header, which simplifies application development.

There are many cases in which Converged Application Server handles that sort of mundane, but essential, protocol detail.

The SIP Servlet API specification is closely aligned with the Java Platform, Enterprise Edition (Java EE) specifications, and it is expected that containers that host SIP Servlet applications also make Java EE features available to developers. The most notable of these features is the HTTP Servlet container. There are many use cases in which a converged application, using both SIP and HTTP functions, is required, from conferencing and click-to-call applications to Presence and User Agent Configuration Management applications. Converged applications can also combine other protocols such as Diameter to perform advanced functions such as modifying subscriber profile data.

Figure 2-1 illustrates that javax.servlet.http and javax.servlet.sip converge in the SIP Servlet API.

The SIP Servlet API enables multiple applications to execute on the same request or response, independently of one another. This is another very powerful feature of the SIP Servlet API. The promise is that application developers are able to write applications providing features that are independent of each other, but can be deployed to the same host SIP Servlet container. The applications can be “composed" (or sequenced) to provide a service on a call. This composition is facilitated by the container. See "SIP Servlet API Service Invocation" for more information.

Application data stored in container-managed session objects can benefit from replication and failover. Almost all applications that perform some useful functions require some state between different Requests and Responses. Some state information is mandated by the SIP protocol itself, such as the transaction state machine with its Server and Client Transactions, and the Dialog state machine.

The container also has a notion of message context which encapsulates the SIP level state, and the concept of Sessions, which are the SIP Servlet API constructs. Applications can save their own state in the Session objects maintained by the container. A carrier-grade container will replicate this state such that the call becomes fault tolerant of a container instance, as is done in Converged Application Server.