Cipango goals

Design goals of Cipango are the following:

• add SIP Servlet support to Jetty while staying as close as possible to Jetty architecture
• provides a foundation to process SIP messages with SIP Servlets being an option (the same way Jetty is able to handle HTTP requests with non-servlet handlers)
• focus on call-processing capabilities by using traditional telco patterns

Overall architecture

Cipango architecture is depicted on the following picture. The SIP processing layer is very similar to the HTTP one, with several classes extending their HTTP counterparts to add SIP capabilities.

Main classes of interest are the following:

• Server: this is the main class. It extends the Jetty Server and starts in addition all SIP components.
• ConnectorManager: manages all the SIP connectors which are interfaces on which Cipango sends and receives SIP messages.
• SipHandler: base interface for all SIP handlers.
• SipAppContext: derivation of WebAppContext which represents a SIP Servlets application.
• SipContextHandlerCollection: use to manage all deployed SIP applications. Responsible for the selection of the appropriate SIP application when handling an initial request. Application selection is actually performed by the Application Router.

SIP Processing

Cipango architecture originally evolved from a traditional (non-SIP) call processing platform we developed in a former life. As a result, SIP processing in Cipango remains very call-centric which is something we wanted to keep as it has proven a sound approach to simplicity, performance and reliability.

One of Cipango goals is to be able to host a variety of SIP elements. To support this goal, the SIP layer is organized as a pipeline of handlers. The first handler to be called after a message has been received is the Server which then delegates the actual processing to a configured chain of handlers. Depending on how this chain is configured, Cipango may run a variety of SIP elements, from stateless proxies to fully stateful SIP Servlets engine.

The architecture of Cipango configured as a Servlet engine is represented on the following figure:

The chain of handlers contains all stateful handlers needed to provide SIP Servlets support. It starts from the SipContextHandlerCollection in charge of application selection and includes CallSessionHandler, TransactionHandler and SessionHandler responsible respectively for concurrency control, transactional state processing and SIP session management.

Threading Model

JSR 289 does not specify a threading model for SIP Servlets Application Servers. Cipango uses a simple and flexible model based on SipApplicationSession. This means that only one thread can execute an activity (servlet doRequest or doResponse handler, servlet timer ...) related to a given SipApplicationSession at the same time.

This allows in particular to have a consistent model in proxy or b2b (back-to-back) applications. Indeed, in proxy mode upstream and downstreams legs belong to the same SipSession whereas in b2b mode, each leg belongs to a different SipSession. If these SipSession are created within the same SipApplicationSession, the behaviour is similar in both modes, i.e. all received message are processed in a sequential way at the servlet level. If you would like to handle incoming messages from different SIP calls concurrently in b2b mode, you only have to use a different SipApplicationSession for each SipSession.