Call Flow Scenarios for the Mobicents SIP Servlets Click to Call Application

Introduction

At university, I (co-)teach a fourth year computer science course called Realtime Multimedia in packet-based networks (RTMM). The course is a good fit for students who have done an introductory undergraduate course in networking and it goes a bit further to discuss the practical challenges involved in the delivery of time-sensitive, realtime media over networks such as the Internet. We examine protocols such as RTSP, SIP, SDP, RTP, RTCP and others and have fun with bandwidth calculations for different media codecs. The course aims to give students an appreciation for the "openness" of the Internet and the philosophy which is central to it which is intelligence at the endpoints. 

In addition to the practical component, the course has always had a strong emphasis on service creation. For this purpose, we used to employ the Asterisk PBX, but recently we have moved to the Mobicents Platform. Mobicents comprises several application services, among them the SIP Servlet container. SIP Servlets is a standard API for the creation of SIP applications based on the Java servlet model. It enables the convergence of SIP and HTTP to create interesting, web-integrated, multimedia applications.

In order to get acquainted with the servlet programming model and to understand the interactions that occur in the container, I recently assigned my students the task of studying the Click to Call servlet application. This application supports the establishment of SIP calls from a web page and controls voice sessions in Back to Back User Agent mode. The task is to examine the application from literally every angle and to generate a set of call flow diagrams that illustrate what is happening between the different parties involved.

As should happen in education, both my students and I learned a lot from the exercise. We were able to generate quite a few scenarios and to understand clearly what was going on using a combination of the source code, Wireshark, Twinkle SIP Client (we found that this client worked really well as it allows you to configure and use two SIP accounts at once) and good ol' server logs.

In this article, I have attached the scenario images for the various use cases of the application that we managed to come up with. Enjoy!

Scenario 1: UA1 Registers and Deregisters

In Scenario 1, the user agent registers by sending a SIP REGISTER request to the container. In order to determine what to do with the request, the container performs application selection which involves determining the list of servlet applications that must be invoked to handle a request. The container requests the DAR (Default Application Router) for a list of applications to invoke in order to handle the request. The list is ordered by priority (in this article, we will assume that click to call is the only application that has been deployed).

The list of applications is retrieved from a text file that is stored in the dars folder of the servlet container. This results in SimpleApplication (the name of the click to call servlet application) being returned to the container. Note that SimpleApplication is a servlet application that contains a SIP servlet called SimpleServlet. A servlet application is allowed to contain one or more SIP or HTTP servlets.

The container delivers the request to SimpleServlet (which is the servlet indicated in the configuration of the application [sip.xml] as the main servlet for this application) which processes the event in its doRegister() event handler. Once received, the servlet sends a 200 OK in response. The same thing happens when the user agent de-registers.

As a side note, according to the servlet model, requests and responses are handled by doRequest() and doResponse() methods respectively (see SIP servlets specification Section 2.2 and 2.3). These methods then pass on the events to corresponding event handlers such as doRegister() for REGISTER requests and doOptions() for OPTIONS requests. 

Scenario 2: UA1 Calls UA2 Directly

In Scenario 2, user agent 1 (caller) attempts to call user agent 2 (callee) directly. Hhowever, at this stage, there is not servlet application that has been configured to process the request. Though SimpleServlet has a doInvite() event handler in the code, it is a dummy handler that does not do anything. Furthermore, the INVITE method is not defined as an active event for SimpleApplication according to DAR rules. According to the SIP servlets specification (see SIP Servlets specification Section 5.6), instead of returning an application name, the DAR returns null to the container and nothing happens. Eventually, the session is invalidated.

Scenario 3: Establishment of a call from the Browser

By registering a second user agent and navigating to the click to call web interface (\click2call) we can establish a call from the browser. With two user agents registered, the option of calling is provided  by the call link. When this link is clicked, an HTTP GET request is sent toward the container. The request contains query string parameters (the portion after the ? in the URL) that identify 'to' and 'from' addresses for the call.

This is sent to the HTTP servlet portion of the servlet application called SimpleWebServlet (see the application's web.xml file). The servlet creates and sends a SIP INVITE request in its doGet() event handler toward the SIP address indicated in the 'to' parameter of the URL. Before it does so, it inserts the address of the caller in the application's context which will be used at a later stage. Application context is shared by all servlets (SIP or HTTP) in a given servlet application.

Depending on the user agent, it will probably generate a TRYING provisional response. This is received in the SimpleServlet's doProvisionalResponse() event handler which just logs the event to the console. The same thing goes for the TRYING response.

Note that when the servlet creates and sends a request, it itself is behaving as a user agent. When it does so, the container is required to keep dialog state according to SIP rules. This when the provisional requests are received, routing happens directly and application selection is not performed.

The callee answers the call and sends a final 200 OK response which is received in the doSuccessResponse() event handler. The servlet then creates and sends a SIP INVITE to the caller using the address stored in the servlet context. Once the second 200 OK is received, then ACKs are sent to both parties and communication begins.

Scenario 4: Teardown of the call from the Browser

The call can be ended using the browser by clicking the 'end' link in the click to call interface. This request works in a similar fashion to the 'call' link in Scenario 3. The doGet() event handler of the web servlet parses the request to find 'bye' attached as a query string parameter. Using a Call object, it sends BYE requests to both parties in sequence. Both parties respond with 200 OK responses. Each is received in the doSuccessResponse() event handler of the SIP servlet.

Scenario 5: Teardown of the call from User Agent 1

The call can also be ended through the phone instead of the browser. A BYE request is sent to the container from a phone. This request is known as a subsequent request since it is a request that is sent as part of an already established SIP dialog. Such requests are not subject to application selection either and are routed using the container's state to the appropriate servlet (see Sip Servlet specification Section 15.6). The doBye() event handler of the SIP servlet sends a BYE to the remote party (callee) and sends a 200 OK to the caller. The remote party also sends back a 200 OK.

Scenario 6: Teardown of the call from User Agent 2

 This call flow is similar to the above, with the order of events reversed.

Scenario 7: User Agent 2 rejects the Incoming Call

Following the initial call flow steps in scenario 3, it is possible for the callee to reject the incoming call. So instead of accepting the request with a 200 OK, the callee sends a 603 DECLINE in response to the INVITE. This is received in the doErrorResponse() event handler of the SIP servlet. This event handler is responsible for handling all 4xx, 5xx and 6xx error responses (see SIP servlets specification Section 2.5). The servlet removes its state about the call and the container sends an ACK on the application's behalf to the caller.

Scenario 8: User Agent 1 rejects the Incoming Call

Though it does not make much sense from the real world point of view, the caller can reject the incoming call that is initiated from the browser. Note that the ACK to the callee is never sent in this case since ACKs are only sent when both the caller and the callee have answered the calls created by the application. Therefore the callee keeps retransmitting 200 OK responses to the servlet until it times out. A 500 Server Internal Error results from a BYE being sent for a session that was never fully established.

Scenario 9: Call is ended in Browser before UA 2 answers

Following from Scenario 3 again, it is possible for the call to be ended from the browser before the callee answers the call. By clicking the 'end' link in the click to call interface, a BYE is sent to the callee. The callee will respond with a 487 Request Terminated, which is ACKed by the container. Technically, a CANCEL should be sent instead of a BYE. A discussion on this is related here.

Scenario 10: Call is ended in Browser before UA 1 answers

As a follow up to Scenario 9, the caller may opt to end the call before the call is answered on their SIP phone. The interactions are essentially the same as those in Scenario 9.

Scenario 11: UA 2 does not answer the call

In this scenario, the call is initiated through the browser, but the callee ignores it until the request times out. The container sends an ACK on the application's behalf.

Scenario 12: UA 1 does not answer the call

In the last scenario, the callee does not answer the call. The caller's user agent sends a BYE, but since the ACK was never sent to the callee, the callee's user agent responds with a 481 Call Leg does not Exist. This accords with the SIP RFC Sections 21.4.19 and 15.1.1.

Conclusion

The Mobicents SIP servlets container is a powerful platform for the development of web integrated, Internet telephony applications. By combining both HTTP and SIP servlets, interesting applications can be developed. Servlet applications can share a context so that seamless communication can be supported across all servlets in the application, be it HTTP or SIP. The container handles much of the tedious work of managing state. 

Application selection also forms the basis for complex service construction in a simple prioritised manner. The platform allows developers to handle requests using a simple doRequest(), doResponse() model that hides some of the complexity of the underlying SIP protocol. 

The click to call application is a simple example that effectively communicates the servlet model to provide beginners with the tools they need to enable them to develop converged applications of their own.

An HTTP based Bulk SMS API for Mobicents

Recently, I have been working on a Bulk SMS Service implemented within Mobicents that allows external systems to communicate with it via HTTP. The service, in fact, is two services in one. The first service is a network-hosted address book that allows users to manage their own contact lists. For this, the service makes use of the Mobicents XDMS which comes with native XCAP resource list  support. The second service is the actual SMS service that receives requests to send SMSes. Each request must specify a list of recipients that can be specified individually or as a group that contains several members. This post describes the version 1.0 of the API that I have created and how it behaves. In a subsequent post, I will be providing details of the actual implementation and how extensions will be factored in for version 1.1.

Basic Structure and Parameters
All requests are HTTP GET requests. The basic structure of the request that is sent to Mobicents is as follows:

http://hostname:port/mobicents?username=foo&password=bar&type=[document|group|contact|sms] &op=[add|edit|del|send] [&parameters]

In the above request format, the hostname and port number are those of the Mobicents instance that is running the service. The “mobicents” subpath maps onto the Mobicents HTTP servlet connector that is associated with the service.
The mandatory parameters are:

• username - The username of the user.
• password - The password of the user.
• type - The type of data that is being managed. Legal values are “document”, “group” and “contact” for managing contact list documents, contact groups and individual contacts respectively, and “sms” for generating functions.
• op - The type of operation that is being attempted. Legal values are “add”, “edit” and “del” for managing contact information, and “send” for sending SMSes.

Contact List Management
A contact list refers to a document that is hosted on a document management server that contains user contact details. An HTTP request from an external system can be made to manage such documents. The structure of the request must accord with the following:

http://hostname:port/mobicents?username=foo&password=bar&type=document&op=[add|del]

A contact list document can either be created or deleted. When a new contact list is created, a single contact group named “Ungrouped” is automatically created in the user’s contact list. The add operation is idempotent, meaning multiple executions do not change the state of the document from how it is when it is initially created. The delete operation can be executed on non-empty documents, that is documents that contain contacts in the Ungrouped group or other groups.

Group Management
An HTTP request from an external system can be made to modify a contact group that a user has defined. The structure of the request must accord with the following:

http://hostname:port/mobicents?username=foo&password=bar&type=group&op=[add|edit|del] &group=group [&newgroup=newgroup]

An group management request is indicated by assigning the value “group” to the type parameter. Contact groups can be added, edited and deleted. It is assumed that each contact group has a name and consists of zero or more contacts. There is an additional parameter that can be specified when the name of an existing group is being edited:

• newgroup - The new name being allocated to an existing group.

Next, some examples are given of how these requests should be structured for given operations.


To create a new contact group called Friends, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=group&op=add&group=Friends

To change the name of the contact group called Friends to Close Friends, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=group&op=edit&group=Friends&newgroup=Close%20Friends

To delete the contact group named Friends, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=group&op=del&group=Friends

Contact Management
An HTTP request from an external system can be made to modify the details pertaining to a given contact. The structure of the request must accord with the following:

http://hostname:port/mobicents?username=foo&password=bar&type=contact&op=[add|edit|del]&name=name&number=number [&parameters]

Contacts can be added, edited, deleted and removed from a group or multiple groups. In addition to the general mandatory parameters listed previously, contact management requests must specify a name and a contact number since these parameters identify a contact uniquely. There are other parameters that can be specified depending on the type of operation that is being attempted.

• group - The group name that a contact currently belongs to, is to be inserted into or is to be removed from. 
• newname - The new name to be allocated to an existing contact.
• newnumber - The new contact number to be allocated to an existing contact.

Next, some examples are given of how these requests should be structured for given operations.


To add a new contact named John Doe with mobile number 0786346927, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=contact&op=add&name=John%20Doenumber=0786346927

In this case a group is not specified, so the contact is allocated to the Ungrouped group in the contact list. To change John Doe’s name to Peter Doe, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=contact&op=edit&name=John%20Doe&number=0786346927&newname=Peter%Doe

To change John Doe’s mobile number to 0786346920, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=contact&op=edit&name=John%20Doe&number=0786346927&newnumber=0786346920

To delete John Doe entirely from the contact list, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=contact&op=del&name=John%20Doe&number=0786346927

To add a new contact named Alice Wonderland with mobile number 0786346928 to a contact group called Friends, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=contact&op=add&name=Alice%20Wonderland&number=0786346928&group=Friends

To remove Alice Wonderland from a contact group called Friends, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=contact&op=del&name=Alice%20Wonderland&number=0786346928&group=Friends


User Profile Management
This document does not define any user profile management methods. It is anticipated that version 1.1 of the API document will define and support them.

SMS Generation
An HTTP request from an external system can be made to send an SMS through Mobicents. The structure of the request must accord with the following:

http://hostname:port/mobicents?username=foo&password=bar&type=sms&op=sendto=nums&group=group&text=text [&report=bool]
The SMS service has the same mandatory parameters defined is Section previously. It also defines the following parameters:

• to - The number or list of numbers to send the SMS to.
• group - The contact group of list of groups to send the SMS to.
• text - The body of the SMS message.
• report - A boolean flag for SMS delivery reports.

When sending an SMS, either the to parameter or the group parameter must be specified, or both. If the SMS is intended for multiple recipients, the contact numbers must be separated by the ’+’ character in the to parameter. Likewise, if the SMS is intended for multiple groups, the group names must be separated by the ’+’ parameter in the group parameter. Only the values “true” and “false” are valid for the report parameter. Assigning the value “false” to the report  parameter is the same as not setting this parameter in the request at all. Next, some examples are given of how these requests should be structured for given operations.

To send an SMS to a user with the mobile number 0786346927, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=sms&op=send&to=0786346927&text=This+is+the+text

To send an SMS to the numbers 0786346927, 0786346928 and 0786346929, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=sms&op=send&to=0786346927+0786346928+0786346929&text=This+is+the+text

To send an SMS to the numbers 0786346927, 0786346928 and 0786346929 and request a delivery report, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=sms&op=send&to=0786346927+0786346928+0786346929&text=This+is+the+text&report=true

To send an SMS to a contact group called Friends, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=sms&op=send




To send an SMS to the mobile numbers 0786346927, 0786346928 and 0786346929 in addition to a contact group called Friends, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=sms&op=send&to=0786346927+0786346928+0786346929&group=Friends&text=This+is+the+text


In such cases, Mobicents is responsible for ensuring that an SMS is not sent more than once to a group contact that is already explicitly listed in the to parameter.

To send an SMS to the groups Friends, Close Friends and Family, the following request is issued:

http://hostname:port/mobicents?username=mos&password=1234$&type=sms&op=send&groups=Friends+Close%20Friends+Family&text=This+is+the+text


Error Conditions
There are a number of operations that can lead to error conditions. They are gracefully handled by Mobicents. Mobicents defines exceptions that are thrown when the processing of a request can lead to an error condition.


Too Few Parameters - This error condition arises when the request that is received is missing one or more of the mandatory parameters that have been defined previously. In response to this, Mobicents will send an HTTP response back to the requesting system with the following message: “HTTP Error 432: Missing Mandatory Parameter in the request - Check API manual”. For example, the following request will generate such a response:

http://hostname:port/mobicents?password=bar&type=contact&op=add&name=name&number=number

Parameter missing a value - This error condition arises when the request that is received is missing a value for any parameter that is specified in the request. In response to this, Mobicents will send an HTTP response back to the requesting system with the following message: “HTTP Error 433: Malformed URL - Missing Parameter Value - Check API manual”. For example,
the following request will generate such a response:

http://hostname:port/mobicents?username=foo&password=bar&type=&op=add &name=name&number=number&group=Friends

Unknown Parameter - This error condition arises when the request specifies a value that is not part of the pre-defined values for the service. In response to this, Mobicents will send an HTTP response back to the requesting system with the following message: “HTTP Error 434: Unknown Parameter in the request - Check API manual”. For example, the following request will generate such a response:

http://hostname:port/mobicents?username=foo&password=bar&type=sms&op=send&group=Friends&text=This+is+the+text&ussd=true


Invalid Request - This error condition arises in a number of different cases where the request is not formatted correctly for the type of operation that is being attempted. A request that violates any of the following rules fits into this category:

• When creating a document, the only legal operations are add, edit and delete. 
• When adding a new group, the group name must be specified.
• When editing a group, both an existing group name and new group name must be specified.
• When deleting a group, the group name must be specified.
• When adding a new contact, both the name and the contact number must be specified.
• When editing a contact’s name, both the existing name and new name must be specified.
• When editing a contact’s number, both the existing number and the new number must be specified.
• When deleting a contact, both the name and the contact number must be specified.

In response to any of these conditions, Mobicents will send an HTTP response back to the requesting system with the following message: “HTTP Error 435: Illegal operation - Check API manual regarding: [error message]”.

Creating a Hello World SLEE application (Ubuntu version)

The development of a SLEE application, though not extremely complex, can be a bit tedious when it comes to creating the directory structure and XML file descriptors. To assist SLEE developers, the Mobicents core team has created tools for the development of SLEE applications in the Eclipse Java IDE. Tutorials do exist already on the Internet and there are a few blog posts that describe the process. This tutorial is essentially a copy of those, but specifically customised for the Ubuntu environment and the Helios version of Eclipse. [download]

Thesis Abstract - Take One

Normally, you don't write the Abstract until you have actually done the thesis. Go figure. But I have decided to give it a jab and put something down for the time-being. Obviously, I will be returning every now and again to shape it up, but this is what I have in mind for now:

Abstract -- The next generation network (NGN), as specified by the International Telecommunication Union (ITU), seeks to guarantee that the network of the future will provide users of telecommunication systems with seamless access across disparate networks, to the applications and services they need and use in everyday life. The IP Multimedia Subsystem (IMS) as defined by standards bodies such as the 3GPP (3rd Generation Partnership Project), ETSI (European Telecommunication Standards Institute) and others, is an important part of the NGN, particularly from the perspective of providing the services architecture that executes and delivers services based on user requests. The decomposition of these services into their constituent parts provides IMS engineers with the advantage of code re-usability and a more flexible platform upon which to develop complex services. Work in this area has led to the definition (outside of the standards) of a service capability interaction manager (SCIM) and a service broker which are responsible for handling the interactions between service components and managing access and third party exposure to these components respectively. The aim of the work related in this thesis has been to investigate in detail the service architecture of the IMS and to identify and validate the shortcomings, if any, of the current architecture for the delivery of complex services through service orchestration. The work applies only to the composition of services that are hosted on SIP (Session Initiation Protocol) application servers which is one of the three target environments specified by IMS. In agreement with related work, this thesis finds that the current architecture is not fully supportive of these functions without some extra interventions. A novel architecture that extends the currently proposed model is subsequently presented using the Mobicents platform which is based on the JAIN SLEE standard that, unlike related work, re-uses existing IMS standards and mechanisms and is compared and contrasted with contemporary designs such as Parlay X, GSMA One API and OMA NGSI.

Innovation Awards - IntelliDesk CRM System based on Open Source Software

Summary-- The Technology Innovation Agency (TIA) in South Africa is an agency of the Department of Science and Technology that seeks to support young innovators in scarce-skills disciplines such as natural sciences, engineering and information technology. A bi-annual competition is held at all the tertiary institutions where independent panels choose three of the best proposals in each institution. Successful competitors are then sent to a two-day crash course where they are taught the basics of how to write a business proposal and are mentored by experts in business administration. In the last stage of the competition, the national stage, the innovators must compete against others for the chance to win ZAR 300,000 (USD 41,000) as the winners of the National Innovation Competition.

Two of my colleagues and I entered the competition late in 2009 with two hopeful business proposals. One proposal was for a "Mobile Trainer" that combines an application that interfaces with a mobile phone's GPS and accelerometer to track the training progress of an athlete. The information that is generated would also be posted onto a website and help create an online community that provides support and comparative statistics to help novice or recreational athletes.

The second proposal that we came up with was "IntelliDesk" which is the proposal that would end up earning us second position in the first round of the competition. IntelliDesk is a telephony-enabled, web-integrated customer relationship management software that is based on open source software that generalises to many business cases. The basic idea is to create an online master database that stores customer profiles. The main way this database is created is through a person interacting with a website that allows them to store information about themselves and also to determine which business entities are allowed to have access to their information.

A local installation of IntelliDesk is setup at the premises of our customers that allows them to download and store user profile information and match these details against the callerid (or sms) of a calling user. The information is put up on a web interface so that the agent at the business side can briefly scan through the information before answering the call. This information is important in dealing better with the user and helps the agent offer a customised service to their clients.

In South Africa, and indeed in other parts of the world, such systems already exist. However, more often than not, these are in-house systems that are installed at call centres or restaurants that serve the interests of that business only. What IntelliDesk offers is a general purpose interface to user profiles that can be utilised by several businesses so that the user does not need to create a 'presence' at each conceivable call centre or restaurant, but one set of information can be shared across many businesses and the power is in the hand of the user who dictates who can access and who cannot access their information.


The System

Poster depicting IntelliDesk architecture for the national competition

IntelliDesk is built from open source software. The telephony portion is handled by Asterisk, an open source PBX. The website is hosted on an Apache web server and PHP files are used as a scripting language for both Apache and Asterisk (through Asterisk AGI support).

Photos of national trials

The venue for the national competition taken from the taxi (Moses Mabidha stadium, one of the World Cup stadiums)

The IntelliDesk setup: Asterisk interface on laptop, two wifi phones, a wifi AP and an analogue phone connected to the Asterisk server (behind the white box) with a Digum card installed

I was basically the eye-candy for our demo stall

Fred and Z showing someone how the system works

Fred (right) showing the Director General of Science and Technology (left) and the chairperson of the Technology Innovation Agency (middle) how the system works

Our consolation prize for not winning the competition

Mobicents Based IM Service with outsourced Billing Using Ericsson Charging SDK

Abstract - Mobicents is a Java based platform that implements the JAIN SLEE standard that delivers a wide range of multimedia services for various application domains. It is an umbrella name for a set of enablers that includes presence, media services, sip servlets and diameter, besides a JAIN SLEE server which provides the application execution environment. The power of the platform comes from its focus on enablers that can then be utilised to develop complex services. This is enhanced by its emphasis on open standards such as those that are being standardised by bodies such as the IETF, 3GPP, ETSI TISPAN and ITU. In this example, the Mobicents SIP function will be used along with a diameter stack to implement a relatively simple billing system for billing SIP based instant messages. Mobicents will be used here as a diameter client which communicates with a diameter server in the form of the Ericsson diameter emulator.

Design

SIP Portion

JAIN SLEE is an event based architecture that allows for service development to be based on an hierarchical and priority based model that defines a root service building block (SBB) which is linked to one or more child nodes (child SBBs). When a root SBB registers for certain events, such as SIP events, the SLEE event router delivers those events, either those from external resources such as SIP softphone running on s user's computer, or those that are generated by itself, to that root SBB. The root SBB can then dispatch that event or a new event to one of its children for further processing. The hierarchical design of the SIP based portion of the service is illustrated below:

Figure 1. Service Design showing root node and children

Diameter Portion

The diameter support in Mobicents is composed of a Diameter stack, a mulitplexer and message validator. The stack is the most important aspect of the diameter infrastructure as the stack provides the mechanisms necessary for message sending and receiving, peer management and session management. The multiplexer allows multiple applications to share a single diameter instance. Lastly, the message validator validates the messages that are sent or received to ensure that they are formatted appropriately. The Mobicents Diameter environment is summarised in the figure below:

Figure 2. Mobicents Diameter environment. Source: [1]

Ericsson Diameter Emulator

The third piece of the puzzle consists of the Ericsson emulator which is a java based implemenation of the diameter protocol.  The emulator is designed to behave in a similar manner to Ericsson's PPS 3.6 system which is a prepaid commercial system developed by Ericsson. Any system which interacts with the emulator properly is guaranteed to work with the commercial version. Ericsson also released an SDK which exposes an API for programmers to use in order to develop Diameter clients or servers of their own quickly.

Outline of the system

With our root SBB and children it is possible to locate user's locations and use the SIP proxy to send messages to SIP endpoints. The Diameter function can be used to implement a Diameter client for sending Accounting requests and receiving accouting answers. The figure below gives an outline of the desired system:

Figure 3. Outline of the system showing main entities.

The system in action

Step 1: We register two SIP clients to the Mobicents SIP Registrar.

Step 2: Using one SIP client, we send a SIP instant message (MESSAGE) to the second SIP client, indicating the caller's URI

Step 3: The SIP MESSAGE is intercepted by the root SBB as configured. The root SBB extracts the callee's SIP URI from the FromHeader in the SIP message and sends a Diameter Accounting Request (ACR) to the Diameter server, inducating the user's MISDN and the service details which will be matched against a tarriff database on the Diameter server.

Step 4: The Diameter server receives the ACA and examines the request. If all is well, the server will respond with an Accounting Answer (ACA) with a 2001 response code (DIAMETER_SUCCESS) to the root SBB. Otherwise, the server may send an error message or a negative 4241 response code (INSUFFICIENT_BALANCE).

Step 5: At the root SBB, the Diameter response is examined. If the result is positive, the root SBB attaches the SIP proxy so that the message can be sent to the callee. If a negative response is received, a SIP message is routed back to the caller indicating the nature of the error.

Conclusion

Mobicents, as a heterogeneous services platform, allows developers to build services based on technology enablers that can be deployed independently or in concert with each other to provide complex services. The emphasis on open source and open standards allows for ease of use and interoperability with other implementations, which makes it easy to tie into existing solutions a customer may already have. The example described here is not complex, but shows what can be done when enablers are pooled together to build intersting services.

Enablers and SCIMs for IMS

Services architecture in NGNs

With the advent of realtime Internet applications especially in the mobile domain and the proliferation of social networking platforms like Facebook, MySpace and Skype, operators are finding themselves in difficult terrain. Not only have revenues decreased from voice calls and text messages due to VOIP and chat services, but now their networks are being degraded to the status of "bit pipes" for access third party services. These services are normally free or are being offered for a nominal prices, and thus their popularity. Thus operators have to come up with advanced services to entice customers to stay within their "walled gardens".

Next generation networks that are now be rolled out by the majority of operators in Europe and America such as the IMS are three tiered architectures separating the access, control and application layers (ASs), with services being deployed through application servers located in the upper layer. Criteria known as initial filter criteria (iFC) are used by the Service Call Session Control Function (S-CSCF) in conjunction with user profile information obtained from the Home Subscriber Server (HSS) to direct user requests to the targeted AS. This type of interaction is summarised in the diagram below:

Sh is the Diameter protocol

ISC is SIP

Cx is Diameter protocol

Ut is XCAP

Towards enablers for NGNs 

This monolithic way of service provisioning in the IMS works for some cases, but is based on predictable rules and does not cater for dynamic conditions such as date and time or some result that can only be determined at runtime, that may be interesting to incorporate in the service model.

Organisations such as the Open Mobile Alliance (OMA) and the 3rd Generation Partnership Project (3GPP) are also radically changing the way in which services are being developed in such networks. These organisations are defining and standardising basic technologies that exist in the network and can be re-used among several different applications. These are called service enablers by the OMA and service capabilities by the 3GPP. We will call them enablers here for simplicity. Examples of enablers include presence, conferencing and instant messaging.

This move will eliminate redundancy in the application domain and will make the development of services quicker and easier. Developers will no longer need to have intimate understanding for example of the SIP Presence specification, but will simply need to use easy APIs exposed by the presence enabler to manipulate presence information. Not only this, but the use of enablers can also help operators provide complex and interesting services such as multi-player gaming and multi-party multimedia conferencing by pooling the enablers together to provide such services.

In order to provide complex service, some node in the network is required which is able to handle the interaction between and dynamic interleaving of these enablers. A special group in the 3GPP was setup that would investigate the architecture of such a node. The name service broker (SB) or service capability interaction manager (SCIM) was given to this node. It was suggested that the SCIM would sit between the ASs and the S-CSCF. The figure below shows the modified services architecture of the IMS, with the SCIM included.

1. ISC interface (SIP) is used between the SCIM and the S-CSCF

2. ISC interface is used between the SCIM and the ASs

3. The ISC interface is used between different SCIMs in the network

In general, the SCIM must be able to perform service interaction management through interaction logic that tells it how to coordinate between different enablers and which enablers to invoke and at what time. As yet, there is no technical specification that details the exact operation of this node, and so there is a need for experimentation in this area.