Before you read this document, please make sure that you are familiar with basic terminology used in this page. Also, please read the overview section to find out in more details about what SipExchange can do for you. For more details on the architecture, please read the architecture section.
Table of Content
- SipExchange components
- SIP messaging
- Call processing
- Operations, administration, maintenance and provisioning (OAMP)
- External management application interface
- External call control
- Application portal
As explained in the overview section, SipExchange is a softswitch. In AIN/IN terminology, it is commonly referred to as the Service Switching Point (SSP). The primary function of the SSP is to set up and tear down call sessions between two parties. The functions of the SipExchange SSP are illustrated in the following diagram.
The process of setting up and tearing down calls involves a number major steps. Namely:
- Communication with the end users’ telephone equipment: In the case of SipExchange, the communication protocol is SIP. The SipExchange application uses the Jiplet Container for handling most of the messaging functions.
- Call processing: This is the heart of the SSP. It involves processing requests from calling users to set up calls. Call processing involves locating the user being called by querying the database and initiating the call to the called user. When the called user answers the call, the call processing module communicates the information to the calling user. Similarly when a user hangs up, the call processing module mediates the communications between the calling and called parties. The call processing module also alters the call sequence based on the features that the calling or called user has subscribed to. An AIN/IN SSP interacts with an external call control system that can direct the SSP on how to set up or handle the call. This aspect is explained in more details in the External Call Control section.
- Call detail record (CDR) generation: For accounting purposes, every call mediated by the SSP is recorded. A call detail record is produced that contains information like calling address, called address, duration of the conversation, etc. This information is stored in the database and can be accessed by administration and billing applications. The call processing module writes parts of the call record at different points of the call.
As illustrated in the above diagram, the SSP maintains a number of data tables that are required for processing the calls. The tables include subscriber information, location information and call detail records. There are management applications that administer these data. For example, an administration application allows system administrators to create, modify and delete subscribers. Similarly, a billing application may retrieve CDRs from the database to create invoices for the customers.
The following sections explain each of the components in more details.
The SipExchange communicates with SIP phones using standard SIP protocol. SIP is a very popular voice over IP (VoIP) protocol that is widely used for setting up voice, video and data sessions using the Internet. You can find more information about SIP protocol standards here. The SipExchange application uses the Jiplet Container for handling most of the SIP messaging. The jiplet container provides the infrastructure for SIP communications including encoding and decoding SIP messages, receiving and sending messages, transaction support, etc. The SipExchange basically provides the handlers (called jiplets or SIP servlets) that handle some of the messages as they are received by the system.
This is the core of the system. Call processing refers to processing requests from calling and/or called parties to set up and tear down call sessions. The SipExchange call processing component consists of a number of jiplets that receive messages from the jiplet container and provide the logic for handling the messages. For example, when a SIP INVITE message is received (a request from an user to place a call), it resolves the “To” party to a location where this user has registered. Then it proxies the INVITE over to that location.
The call processing modules provide the following services:
- Location service: When a user turns on his/her SIP phone, this service stores the location information so that calls to this party can be routed properly.
- Proxy service: When a call request is received by the softswitch, this service locates the called party and sets up the call. It also plays a part in tearing down the call. This service also provides the logic for any subscriber or domain features that the users have subscribed to. For example, if the user has subscribed to a “do not disturb” feature, this service checks if the user has enabled “do not disturb” before routing the call to the user. The SipExchange proxy service supports “external call control” features. For an incoming or outgoing call meeting a certain pre-specified criteria, the call information is communicated to an external call control server (called the SCP) . The SCP provides instructions on how to handle the call. This way, the SCP can provide the service or feature logic. The system can talk to many SCPs and each SCP can provide one or more features. For more details, see the External Call Control section.
- Presence service: Each user may have a set of contacts that he/she may want to keep track of (in order to get notified when a contact comes online or goes offline). The contacts appear in a phone supporting a contacts list. This service provides the business logic and handling of the SIP messaging between the server and the SIP phones.
In addition, the SipExchange server generates call detail records (CDRs) for every step of a call. The CDRs are stored in the database and can be accessed by billing and management applications.
The SipExchange service has to be administered and managed in order for it to work. There are two types of OAMP interfaces supported by the system. The are:
- Administration user interface: Using this user interface, system administrators can manage system parameters, domains, subscribers, roles, CDRs, etc. Only authorized system administrators can access this interface. This component also allows some reporting capability including ability to view and search CDR records, locations, etc. SipExchange provides a web-based user interface for administering the system.
- Subscriber user interface: Using this user interface, subscribers can manage the features that they have subscribed to. Users can change their own password, provide call forwarding information, enable or disable do not disturb, etc.
The call processing and OAMP components require data tables where subscriber and other information is stored. Both the OAMP and call processing modules access the tables to store and retrieve information. In most cases, the OAMP components write to the tables and the call processing component reads the database. But there are cases where the opposite is true. For example, a CDR database is written to by the call processing component and the CDR data is read by OAMP component. The following types of data are stored in the database:
- Subscriber information: information includes subscriber user id, name, password, contacts and subscribed features.
- Domain information: information includes domain names, domain parameters and features.
- System information: information includes system parameters.
- Call detail records: all call-related records are stored in a database.
- Location information: when a user logs in to the system, his/her location is stored in the database. When a user logs out or the location “expires”, the location is removed from the database.
The SipExchange applications allow some of the data described above to be accessed and managed by external management applications. SipExchange provides an Application Programming Interface (API) using which external applications can add or modify subscriber, domain and system information, access and manage CDRs, etc. A web services interface is provided that allows applications to:
- Invoke the services remotely. The applications do not have to be located in the SipExchange servers.
- A language-independent API allows applications to be created using Java, C++ or other languages.
As explained in the above sections, external call control enables features and services to be created independently of the SipExchange server. Features are created in an external entity called the Service Control Point, or SCP. Note that the SCP does not necessarily have to be in another computer. It can be located in the same Jboss application server where the SipExchange application is running.
The SCP has two components. They are:
- Communications layer: This is a software layer that communicates with the SipExchange SSP. To ease development in this area, the SipExchange server uses Jboss remoting service to implement this layer. Jboss remoting service provides many great features including encapsulation of the transport, load sharing, fault tolerance, etc. Therefore, no development is needed in this area.
- Service logic: This is where the service logic for features is implemented.
External call control and service logic creation are explained in more details in the External Call Control section.
Note that all the features provided by the SipExchange itself are implemented using the same principle of external call control.
As explained above, SipExchange provides user interface for system administrators and subscribers. These user interface functions are available from a portal site. The portal enables service providers to easily add additional functionality to the portal in addition to what SipExchange provides. The SipExchange user interfaces are portlets that are designed to run on the Jboss Portal. The service provider can add additional portlets to complement the functionality that SipExchange already provides. For example, the service provider can add an additional portlet from where potential subscribers can sign up for the service.
Some of the highlights of the Jboss Portal includes:
- The service provider can completely customize the look and feel of the portal site.
- The service provider can add additional components by deploying additional portlets.
- Jboss comes with a wide range of ready-made portlets for displaying news, weather and other information.
- Jboss allows service providers to add Google gadgets to the portal site.
- Jboss comes with a content management system that allows service providers to add additional information to the site easily.
- The Jboss portal comes with a dashboard that allows users to customize the look and feel and arrange the available portlets.