Setting up an IMS development environment (Part 1)

ReplyUncategorizedfvrier 16th, 2011Eric Macioszczyk If you are interested in being an actor in the development of converged IP Multimedia applications for fixed and mobile communications, you cant ignore IMS architecture. The adoption by operators is already done, at least for their fixed lines offering based on VoIP technology and the use of residential gateways (ADSL or FFTH box). For the mobile network, the limited bandwidth available to mobile terminals (like UTRAN devices) made the deployment of such a complex (and costly ?) architecture less obvious. With the emergence (and deployment) of LTE and its natural integration into a full IP world, it seams clear that its time now to fully set up a real converged architecture and to benefit from IMS promises in term of service deployment. From a subscriber point of view, the advantage of an architecture capable of providing a set of converged and adapted services for all his numerous terminals (mobile, smart-phone, PC, IPTV, tablet, etc ) is quite straightforward and IMS is one solution for that. Having said that, lets come back to the subject of this post. Being a trainer in IMS and multimedia technology, I always tried to illustrate my talks by giving the opportunity to my attendance to use real equipments and to discover by themselves all the technical details they need for their job. Moreover, my activities in multimedia platform integration and application development requires having a real environment at my office for testing purpose. So, how can we set up a complete environment based on IMS architecture, allowing developing, integrating and testing real multimedia services ? Lets first try and summarize elementary function blocks needed for that:

IMS core network: includes P/I/S-CSCF and HSS. Will allow user registration and the invocation of provisioned services. SIP Application Server: will host services available to subscriber. A service execution environment (SLEE-like) allows the execution and the interaction of different applications. Media Server (MRF): allow to play, record and interact with media flow. May be split into a control (MRFC) and processing (MRFP) part. Service Enabler: this element is referenced in the IMS architecture as a basic service made available to other service platforms to create rich and mashed multimedia application (example of enablers: presence service enabler, location service enabler, etc ).

Document server (XDMS: XCAP Document Management Server): this server will contain shared documents accessible from application servers and service enablers (address book, presence rules, service configuration, etc ). Access Network: allow to gain access to IP network and IMS core network. Multimedia terminals: should ideally implement all interfaces required to exercise services and establish rich multimedia communications (SIP, RTP, MSRP, XCAP, etc ..). Will be at least capable of registering in the IMS network and make multimedia calls. IDE (Integrated Development Environment): allow to write, compile and deploy applications in your preferred language.

IMS development environment Well, now we have the picture. This is a very simplified one as you may have noticed that I limited service platform to simple SIP Application Servers. We will see in the next post how to instantiate each of these elements.

Setting up an IMS development environment (Part 2)

No commentsUncategorizedfvrier 17th, 2011Eric Macioszczyk As described in a previous post (here) IMS service architecture relies on a certain number of functional blocks allowing subscribers to access and exercise multimedia services. When developing such services it could be interesting to have access to an environment as closed as possible to what may look like a real deployment. Though simulation environment exists (Ericsson SDS: Service Development Studio, discontinued ?) and can cover some of your basic use cases you might prefer to get physically access to all unitary functional block. This is my personal choice and even if it requires a significant effort in integrating components all together it appears for me as being the more comfortable solution. For the IMS core network, my choice naturally went to the OpenIMS core developed by Faunhofer Institute. It offers enough stability, robustness and possibilities for most of my needs. Based on OpenSER open source product (now opensips) its installation, configuration and customization are quite straightforward and well documented. Great job guys ! You need to compile the sources locally and modify default configuration parameters to get it accessible from external servers. Separating basic functional blocks (I/P/S-CSCF and HSS) into distinct servers is possible even though having them running on a single machine is pretty convenient. Note that even in that case functional blocks remain opened and allow you to get access to all standard interfaces as defined by the IMS architecture. If you are interested in setting it up I recommend you to visit the site of openimscore project.

OpenIMS core For the XDMS part, which I remind you plays the role of document server and is accessible via XCAP protocol (based on usage of HTTP), Im using an open source

solution called openXCAP (http://openxcap.org/). As said in the web site, OpenXCAP is an open source fully featured XCAP server . I use it to remotely store contacts list of users and presence rules. At that time of writing this post, the only Service Enabler I set up is a Presence Server based on openSIPS solution (http://www.opensips.org/). It accepts presence publication and subscription, and handles user defined presence rules. Note that openXCAP has been designed for a direct integration with openSIPS as SIP presence server. As IMS clients, choice is unfortunately very limited today. Im trying to use solutions targeted for different types of Operating Systems and terminals. Even if restricted, current solutions showed me up how far we still are from a full interoperability between terminals themselves and service implementation (like presence and XCAP servers). Having said that, here are the clients I use today: uctimsclient (designed for OpenIMS core), (http://uctimsclient.berlios.de/), Mercuro (running on Windows but unfortunately seems to be discontinued) and imsdroid (http://code.google.com/p/imsdroid/) which is a client running on Android (tested on a HTC). For the AS and MRF components Im using several open source solutions depending on the functionalities I want to implement. The most satisfying solution (I mean the one which best corresponds to my needs) is the Mobicents/JBoss environment (http://www.mobicents.org/products.html). Im not a big fan of JAIN-slee as this is rather destined to pretty complex solutions but servers based on SIP servlet (JSR289), Media Framework (JSR309) and Sh Diameter interface are a good start for multimedia application development. I will come back on this hot topic very soon. No doubt !

Setting up an IMS development environment (Part3) Service Plan

ReplyUncategorizedavril 7th, 2011Eric Macioszczyk As the purpose of this setup is to provide me with an environment for demos and applications integration, its time now to think of which element could be easily used for service plan functions. My needs can be summarized as follows:

being able to set up basic service enablers like presence or location service have media resource function available have a full development and execution environment which can be easily integrated with the IMS core: o SIP, Diameter and MSRP APIs o allowing converged Internet/IMS application development o providing service routing management capabilities o interfacing with media servers

After many attempts and integration works I finally came to the following architecture:

Service Plan architecture

Opensips is set up as presence server and iFC has been created in the HSS for that purpose Asterisk is used for quick implementation of some basic functionalities like Voice Mail, IVR, etc .. Mobicents / JBoss + eclipse IDE is used as Service Development Platform and implements the following APIS: o SIP Servlet JSR281 o Media Framework JSR309 o Diameter Sh Application Mobicents Media Server is the Media Server made available to all applications running into the Mobicents/JBOSS platform.

What is still missing regarding initial objectives is the MSRP APIs since Mobicents does not support it yet (planned for mid 2011?). I will detail in my next post the internal application architecture running in the Mobicents/JBOSS server