The following sections describe the components in more details.

JBOSS J2EE server

The JBOSS server acts as a container for the SipExchange application. It provides the basic infrastructure and various services that the SipExchange application uses. Some of these services include:

1. Support of persistent objects (container-managed persistence or CMP): Most of the persistent information like subscriber profiles, location information and call detail records used by the SipExchange application are handled by the JBOSS EJB Container. The front-end access (or the facade) to the persistent objects are implemented as session beans which the JBOSS server hosts.
   
2. Mail service: JBOSS provides a mail service that the application uses to send emails to system administrators and subscribers.
3. Web container: The JBOSS servlet container provides the infrastructure for the web-based applications.
4. SOAP services: SipExchange exposes a SOAP interface for external applications to access the persistent objects for the purpose of administering from an external management application. The JBOSS web service hosts the SipExchange SOAP service.
   
5. Communications service: The SipExchange supports external call control using which you can provide your own custom 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 "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.
   
6. SCP service: The JBOSS can also host the SCP service although this is not necessary. Some of the standard features that SipExchange provides will be handled by an internal SCP service that is hosted by the JBOSS server.

MYSQL database

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 module

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 service inside the JBOSS server. 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 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 this SIP stack to be replaced by another SIP stack if necessary.

SipExchange jiplets and realm

The SipExchange jiplets handle the following functionality using a separate jiplet for each of the functions:

1. 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.
   
2. Proxy service: This jiplet manages sessions. It routes incoming calls to the appropriate registered subscribers. It also handles the call setup functions initiated by the registered subscribers.  It also detects call triggers and handles the messaging with the SCP. In addition, it generates call detail records (CDRs).
   
3. Presence service: This jiplet handles the presence functionality. This part has not been implemented yet and is slated for an upcoming release.
   

The proxy jiplet (called the SipExchangeProxy) also provides its own realm implementation for authenticating subscribers. The subscriber information can be provisioned using SipConsole - a web-based administration user interface.

Persistent storage module

The SipExchange application requires various information to be persistent that can be accessed from the jiplets while processing calls and by management 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. EJBs are used for the persistence functionality required for the SipExchange applications. Entity beans are used for container-managed persistence. A common practice is to provide front-end session beans that in turn access and manipulate the entity beans. The SipExchange applications follow the same practice and have a set of session beans using which call processing and administration components access these objects.

The following types of information is persisted by the system:

1. Subscriber information: contains subscriber information including his/her domain, authentication information, and subscribed features (triggers).
2. Domain information: contains information about the domains provisioned in the system.
3. Role information: roles work in conjunction with the subscriber information and provide a way of defining subscriber privileges (authorization).
   
4. 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.
5. Presence information: contains the buddy lists for the subscribers. This part has not been implemented yet and is slated for an upcoming release.
6. 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.

Web-based Applications

There are two web-based applications (contexts) that are a part of the SipExchange application. They handle the user interface which is web-based. The contexts are:

1. SipConsole: This is an administration utility to administer domains and subscribers. It also has reporting capabilities like location and call detail record viewing. This application will be enhanced in the upcoming releases to provide more comprehensive administration and maintenance capabilities.
2. SubConsole: This is a web-based user interface for subscribers. Subscribers can access the system and modify their preferences or tune their subscribed features. This part has not been implemented yet and is slated for an upcoming release.

External call control service logic

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 instance or it can be running as an independent standalone application, or it can be installed as a service in another independent JBOSS instance.

The SipExchange standard features are all implemented using this mechanism and are installed as a service running in the same JBOSS instance.

External Management Interface

SipExchange exposes some of the persistent information explained above to external management applications so that the external applications can view/modify the information. A SOAP service is used for this purpose. The SOAP service provides a WSDL using which external applications can generate SOAP clients using standard open-source packages like Apache Axis. This part has not been implemented yet and is slated for an upcoming release.