1. Concepts
  2. Developing Applications for Converged Application Server
  3. Overview of the SIP Servlet Container

Overview of the SIP Servlet Container

Figure 2-2 shows the logical layers of a Converged Application Server SIP Servlet Container. The five layers shown from the bottom are what are known as the SIP stack, the functionality of which is defined in RFC 3261 and the associated RFCs that extend the base protocol.

SIP, being a transaction-based protocol, has a well-defined transaction layer. SIP requests are always followed by one or more provisional Responses and one final response, with the exception of the ACK which has no response. The transaction machinery is designed to keep track of the provisional and final responses.

Figure 2-2 shows the message processing layers in the Converged Application Server SIP Servlet container which are the following from top to bottom: Dialog Management Layer, Transaction Layer, Message Parser, the Transport Layer, and the bottom layer comprising of Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Transport Layer Security (TLS).

Figure 2-2 Message Processing Layers in the Converged Application Server SIP Servlet Container

Message Processing Layers in the Converged Application Server SIP Servlet Container

SIP Dialog Handling

A dialog is a point-to-point session between two SIP endpoints that is uniquely identified by a dialog identifier. Not all SIP requests create dialogs. However, the ones that do create dialogs have a well-defined mechanism of establishing and tearing down the dialog (INVITE, SUBSCRIBE/NOTIFY, REFER).

The SIP stack shown in this diagram is not strictly in accordance with RFC 3261. It differs from the specification in that there is a layer called Transaction User (TU) above the Transaction layer, and the dialog management layer is not explicitly a layer in 3261. The “Dialog layer" is a very visible constituent of a SIP Servlet container because the dialogs correspond roughly to the SipSession objects. In Figure 2-2, the TU layer is actually split between the Dialog management layer and the big Container block.

The primary purpose of the Container is to host SIP Servlet applications that are written to the container's SIP Servlet API implementation. It exposes objects like SipServletRequest, SipServletResponse, different types of Sessions, facilities such as Timer, Logging, and so forth.

Although SIP is a human-readable, text-based protocol, and is well-defined in Request for Comment (RFC) 3261, writing SIP applications can be a challenging task. The SIP Servlet API is designed to simplify SIP application development. While the SIP Servlet API allows access to all the headers present in a SIP Request, it does not require applications to understand or modify all of them for correct protocol behavior. Also, there are some headers that are strictly off limits for applications. The SIP Servlet API defines the so-called "system headers" which are to be managed only by the container. These headers include the From, To, Call-ID, CSeq, Via, Route (except through pushRoute), Record-Route, and Contact headers. Applications can add attributes to the Record-Route header and Contact header fields in all request messages, as well as 3xx and 485 responses. Additionally, for containers such as Converged Application Server that implement the reliable provisional responses extension, RAck and RSeq are also considered to be system headers. The system header management performed by the container offloads a tremendous amount of complexity from applications.

The From, To, Call-ID, and CSeq message headers collectively identify a given SIP dialog. The SIP Servlet container keeps track of the dialog state and dialog-related data for the hosted applications. The SIP Servlet container is responsible for managing Record-Route, Contact, and Via headers because the network listen points, failure management, multi-homing, transport switching, and so forth are also handled by the container. Applications can participate in the routing decisions of a Request emanating from the container by explicitly modifying Request-URI or adding Route headers with pushRoute(). As a result, applications have no responsibility for resource management. The SIP Servlet API draws heavily from Java EE standardization and common practices, such as the declarative usage of container features such as security, mapping, and environment resources.

Perhaps the greatest advantage of the SIP Servlet API is the API itself. The SIP Servlet API abstracts a large number of complex SIP tasks behind intuitive constructs. The Proxy interface, representing the proxy functionality in SIP, is an excellent example. A proxy can:

  • Be stateful or stateless.

  • Recurse automatically (send Requests automatically) upon receipt of a 3xx SIP response code to the Contact address(es) contained in the Response header.

  • Use the Record-Route header to ensure that subsequent requests also go through it.

  • Act as a forking proxy to proxy to multiple destinations, either in parallel or in sequence.

With the SIP Servlet API, all of these options are simple attributes of the Proxy object. The container-managed Proxy deals with all low level details like finding a target set (based on Request-URI or Route headers), applying RFC rules if a strict router is upstream or downstream, creating multiple client transactions, correlating responses, choosing the best response, and so forth.