This documentation relates to last stable version of Cipango.
visit the last unstable documentation home.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

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 (stateful, stateless...). 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.

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 CallHandler, TransactionHandler and SessionHandler responsible respectively for concurrency control, transactional state processing and SIP session management.

  • No labels