Table of Contents
- Jboss J2EE server
- MYSQL database
- Call processing module
- Object persistence, enterprise tier services and web services
- SipExchange Portal and portlets
- External call control service logic
The SipExchange server uses the component model of development that is supported by the J2EE architecture. The SipExchange server runs as a JBOSS enterprise application and packaged as an Enterprise Archive (EAR). The software contains various loosely-coupled components that are coupled together into an EAR and deployed as a single application. The components include Enterprise Java Beans (EJBs) for enterprise-tier services, JPA for object persistence, jiplets (SIP servlets) for handling SIP messaging, portlets for the web-based user interfaces, web services for external application access and Jboss remoting for supporting external call control.
The following diagram illustrates the system architecture in more details:
The following sections describe the components in more details.
The Jboss server acts as a container for the SipExchange application. It provides the framework and various services that SipExchange uses. Some of these services include:
- Object persistence and object-relationship mapping: Most of the persistent information like subscriber profiles, location information and call detail records used by the SipExchange application are handled by the Java Persistence API (JPA) that is managed by the Jboss EJB container.
- Enterprise-tier services: SipExchange provides services layer that are used by the front-end modules like the web-based user interface and the SIP call processing engine. The services are provide using the J2EE session beans that the Jboss EJB container provides.
- Mail service: Jboss provides a mail service that the application uses to send emails to system administrators and subscribers.
- Web services: SipExchange exposes some of the enterprise tier services as web services which enables external applications to administer the system. The Jboss web service container hosts the SipExchange web service.
- Portal: The Jboss portal provides the infrastructure for the web-based user interface. The user interface is provided using a set of portlets.
- Security services: SipExchange uses the Jboss security infrastructure for user authentication and authorization.
- Communications service: SipExchange supports external call control using which service providers can provide their own custom call-processing features. At different points of a call, the SipExchange server determines if the call needs to be processed by an external entity. These points are called triggers. When a trigger is encountered, the SipExchange application communicates with an external entity to get an “advice” on how the call is to be handled. The communication between the SipExchange server and the external entity (also called the service control point, or SCP) uses the Jboss remoting service.
- SCP service: Jboss can also host the SCP service although this is not necessary. Some of the standard features that SipExchange provides are handled by an internal SCP that is hosted by the Jboss server.
The MySQL database is used for storing the persistent SipExchange objects. Although we have only tested with the MySQL server, it is possible to use a different database for storing persistent objects.
Call processing involves processing SIP messages for the purpose of setting up and tearing down SIP sessions. It also implements subscriber and domain features like call forwarding and address translations. SipExchange supports AIN/IN-like external call control capabilities. During processing of a call, external Service Control Point(s) (SCP) gets notified at various points of the call and can provide direction to the call processing module on how to go forward with the call. The communication to the SCP is also handled by the call processing module.
For handling SIP messaging and to handle the call processing and external call control logic, the SipExchange application uses the jiplet container service. The Jiplet Container is another open-source project from CafeSip that provides a servlet-like development and runtime environment for handling SIP sessions and messaging. The jiplet container runs as a Jboss service. The SipExchange applications use the jiplets (or SIP servlets) to process calls. In addition, the SipExchange application uses the container-managed authentication (CMA) feature of the jiplet container to provide subscriber authentication & authorization and implements its own realm. The jiplet container uses the NIST JAIN SIP stack as the underlying SIP stack. The stack is an open-source implementation of the JAIN-SIP API specified by JSR-32. The jiplet container allows the SIP stack to be replaced by another SIP stack if necessary.
The SipExchange jiplets handle the following functionality using separate jiplets for each of the functions:
- Registration and location service: This jiplet manages the locations of the subscribers who register with the SipExchange server. The location information is stored in persistent objects and can be retrieved even when the application is restarted.
- Proxy service: This jiplet manages sessions. It routes inbound calls to the appropriate registered subscribers. It also handles the outbound call setup functions initiated by the registered subscribers. It also detects call triggers and handles the messaging with the SCP as explained above. In addition, it generates call detail records (CDRs).
- Presence service: This jiplet handles the presence functionality. The presence functionality allows users to get notified when an user registers or unregisters.The SIP phones use this function to provide a buddy list similar to the ones provide by popular instant messaging providers like Yahoo and Skype.
SipExchange also provides its own realm implementation for authenticating subscribers. The subscriber information can be provisioned using SipExchange Console – a web-based administration user interface for administration.
The SipExchange application requires to persist various information that can be accessed from the jiplets while processing calls and by administration applications. An example of such information is the subscriber information. The system administrators add new subscribers to the system and provision their SIP address(es), other personal information and feature information. The jiplets handling calls from/to this subscriber access (and in some cases, modify) the information. The Java Persistence API (JPA) is used for the persistence functionality required by the SipExchange applications.
The persistent objects are front-ended by an enterprise-tier service layer that are built using session beans built using the EJB 3 specifications. The Jboss EJB3 container manages these EJBs and provide remote & local access capabilities, declarative security and web services capabilities among other things. The following types of information is persisted by the system and made available as services to remote applications and other SipExchange modules:
- Subscriber information: contains subscriber information including his/her domain, authentication information, and subscribed features (triggers).
- Domain information: contains information about the domains provisioned in the system.
- Role information: roles work in conjunction with the subscriber information and provide a way of defining subscriber privileges (authorization).
- Location information: when a subscriber logs in, the location of the user is recorded so that when there are calls directed to this user, they can be routed accordingly.
- Presence information: contains the buddy lists for the subscribers.
- Call detail records: Each call made to/from subscribers is recorded for billing/accounting purposes. These records are generated during call processing and can be accessed by management/accounting applications.
SipExchange provided a portal for all the user interface capabilities. Administrators can manage the system using web-based user interface. Subscribers can manage their profiles,view their usage and administer their features. The user interface is broken up into smaller modules based on their functionality and provided as portlets. The portlets are designed to run on the Jboss Portal which is a very flexible portal solution and allows the service providers to complete customize the user interface.
There are two types of portlets that are provided by SipExchange. They are:
- SipExchange Console for system administration: This is a single portlet for administration SipExchange. It provides an interface to administer domains and subscribers. It also provides capabilities for tuning system parameters and administering the call detail records. It has reporting capabilities like locations and call detail record reporting.
- Subscribe operations: A set of portlets that subscribers can use to modify their preferences, view their contacts lists, manage call lists and tune their subscribed features.
As stated in the earlier sections, the SipExchange application allows external entities to perform call control. SipExchange uses the Jboss remoting service for communication between the SipExchange application and an external entity(s). The Jboss remoting API allows communication via standard TCP/IP sockets, SSL sockets, RMI, etc., and it is totally transparent to the applications. The call control service logic can be installed as a service either in the same Jboss server, as an independent standalone application, or it can be installed as a service in another independent Jboss service.
All the SipExchange standard features are implemented using this mechanism and are installed as a service running in the same Jboss server.