Look what Java and SIP can do
 (SIP)Java = ∞
Home     News     Projects     Downloads     Support     Contact
SipExchange Home

Terminologies

SipExchange Architecture

SipExchange Basics

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

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:
  1. Communication with the end users' telephone equipment: Inthe case of SipExchange, the communication protocol is SIP. The SipExchange application uses the Jiplet Container for handling most of the messaging functions.
  2. 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.
  3. 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 databases that are required for processing the calls. The databases contain subscriber information, location information and call detail records. There are management applications that manage the databases. 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.

SIP messaging

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.

Call processing

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 make 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:
  1. 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.
  2. Proxy service: When a call request is received, 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.
  3. Presence service: Each user may have a set of contacts that he/she may want to keep track of (to see if they are present in the system or not). The contacts appear in a phone supporting a buddy 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.

Operations, administration, maintenance and provisioning (OAMP)

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:
  1. Administration console: 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.
  2. Self-provisioning console: 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. SipExchange will provide in an upcoming near-term release a web-based user interface for self-provisioning.    

Databases

The call processing and OAMP components require databases where subscriber and other information is stored.  Both the OAMP and call processing modules access the database to store and retrieve information. In most cases, the OAMP components write to the database 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:

  1. Subscriber information: information includes subscriber user id, name, password, contacts and subscribed features.
  2. Domain information: information includes domain names, domain parameters and features.
  3. System information: information includes system parameters.
  4. Call detail records: all call-related records are stored in a database.
  5. 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.

External management application interface

The SipExchange applications allow some of the databases described above to be accessed 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 SOAP interface is provided that allows applications to:
  1. Invoke the services remotely. The applications do not have to be located in the SipExchange servers.
  2. A language-independent API. Allows applications to be created using Java, C++ or other languages.

External call control

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 instance where the SipExchange application is running.

The SCP has two components. They are:
  1. 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 provides many great features including encapsulation of the transport, load sharing, fault tolerance, etc. Therefore, no development is needed in this area.  
  2. 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 document.

Note that all the features provided by the SipExchange itself are implemented using the same principle of external call control.

Search this website 


Send questions or comments about this web site to webmaster@cafesip.org.
Copyright © 2005, CafeSip.org.
Licensed under the CafeSip License.
The CafeSip.org projects, web site and web facilities have been sponsored by QUIK Computing