SIP Servlet API

The SIP Servlet API is a specialized framework designed for creating SIP-based applications, extending the familiar Java Servlet model to the realm of SIP with the following key goals:

• Comprehensive SIP Signaling: It enables applications to handle a wide range of SIP signaling tasks, including functioning as a User Agent Client (UAC), User Agent Server (UAS), or a proxy server.
• Simplicity in Development: By delegating complex tasks like network listen point management, retransmissions, and header handling (e.g., CSeq, Call-ID, and Via headers) to the container, the API simplifies application development.
• Support for Converged Applications: It enables the development of multi-protocol applications that span diverse interfaces, such as web, telephony, and other Java EE components.
• Facilitation of Third-Party Development: The servlet model supports modular, third-party development through XML deployment descriptors, easing the transfer of application configurations between developers and deployers.
• Application Composition: The API allows multiple applications to act on the same SIP request or response, with each application operating independently based on its own rules.
• Carrier-Grade Reliability: By using container-managed session objects for data storage, the API supports high availability through persistence and replication of application data.

Let us remind you once again what a SIP servlet and a SIP container are.

SIP Servlet: A SIP servlet is a Java-based application component that is managed by a SIP servlet container to handle SIP signaling. Similar to other Java components, SIP servlets are platform-independent Java classes, compiled into platform-neutral bytecode that can be dynamically loaded and executed on a Java-enabled SIP application server. These servlets interact with SIP clients by exchanging request and response messages through the servlet container, which provides the necessary support infrastructure.

SIP Servlet Container: A SIP servlet container is a component of an application server that provides the network services required for handling SIP requests and responses. It determines which applications to invoke and in what sequence, manages the lifecycle of SIP servlets, and abstracts complexities such as network listen points, transport protocols, and security. A servlet container can be integrated into a host SIP server, added as a plugin via the server’s native extension API, or built into a servlet-enabled application server.

The container listens for incoming SIP traffic on specified network listen points, which are defined by a combination of transport protocol, IP address, and port number. The SIP specification mandates support for both UDP and TCP transport, with optional support for TLS, SCTP, and other protocols. Security restrictions, such as limitations on thread creation, may also be enforced to ensure stable operation and prevent resource conflicts.

It is important for understanding how the SIP Servlet API facilitates the development and management of applications.

Relationship with the HTTP Servlet API

The SIP Servlet API is closely related to the Java Servlet API, which is defined in the Java Servlet Specification. The Java Servlet API comprises two parts: a generic part under the javax.servlet package and an HTTP-specific part under the javax.servlet.http package. Similarly, the SIP Servlet API extends the generic servlet API and is defined in the javax.servlet.sip package. A SIP servlet container must support both the javax.servlet and javax.servlet.sip packages to maintain compatibility and functionality. The SIP Servlet API specification follows the structure of the Java Servlet Specification, incorporating elements that apply to both SIP and HTTP use cases. However, it adapts certain terminology and features to reflect the unique, non-HTTP nature of SIP applications. For instance, the term "servlet application" is used instead of "web application" to ensure relevance across both SIP and HTTP contexts. By leveraging the same foundational principles and programming models, developers familiar with Java EE can transition smoothly to SIP servlet development.

Differences from the HTTP Servlet API

Although SIP was partially derived from HTTP they differ significantly in terms of service functionality and application requirements:

Hosting Environment:

HTTP services, including HTTP servlet applications, are typically hosted on origin servers that generate the final response to requests. Proxying is generally not a primary function of these applications.

SIP applications, by contrast, heavily rely on intelligent request routing and often act as proxies to direct SIP messages effectively.

Communication Model:

HTTP is not a peer-to-peer protocol. Web applications never initiate requests, they only respond to incoming requests.
SIP, however, is a peer-to-peer protocol. SIP applications frequently need to initiate requests, such as:

• Sending a BYE request to terminate an incoming call.
• Initiating an INVITE to establish a new dialog (e.g., for a wakeup-call application).
• Triggering NOTIFY requests for presence updates.

Certain SIP applications, like a Back-to-Back User Agent (B2BUA), require both client and server functionalities, enabling them to exercise greater control over calls compared to simple proxying.

Additional Features in the SIP Servlet API:

The SIP Servlet API extends beyond the HTTP Servlet API by providing capabilities such as:

• Generating multiple responses, such as one or more provisional (1xx) responses followed by a final response.
• Proxying requests to one or multiple destinations.
• Initiating requests, not just responding to them.
• Handling and processing responses, as well as incoming requests.

Modified Use of Servlet Interfaces:
The SIP Servlet API leverages the original javax.servlet.Servlet interface but adapts its behavior: 

• The service() method is the entry point for application handling, just as in the HTTP Servlet API.
• For SIP traffic, only one of the request or response arguments is non-null at a time. For incoming requests, the response argument is null, and for incoming responses, the request argument is null.

Asynchronicity

Another important distinction between the SIP Servlet API and the HTTP Servlet API is the asynchronous nature of the SIP Servlet API's event model. Unlike the HTTP API, where applications are expected to respond immediately within the context of an incoming request, SIP servlet applications are not required to respond to requests during the event upcall. Instead, they can initiate other actions, return control to the container, or respond to the request later, as appropriate.

This asynchronous approach allows applications to handle long-running transactions without occupying container resources indefinitely. For instance, a Back-to-Back User Agent (B2BUA) can handle complex interactions without hogging threads while waiting for an extended operation to complete. The container manages timeouts for the application instance to ensure that resources are eventually recovered, even if the application fails to respond promptly.