Service composition in IMS using Java EE SIP servlet containers

Service composition in IMS using Java EE SIP servlet containers

Written by: Torsten Dinsing, Göran AP Eriksson, Ioannis Fikouras, Kristoffer Gronowski, Roman Levenshteyn, Per Pettersson and Patrik Wiss

 Download PDF file

The IP Multimedia Subsystem (IMS) gives operators, service providers and developers the ability to create new services using standard session initiation protocol (SIP) routing. To further enhance and complement IMS service creation, Ericsson Research has developed a composition engine that uses core IMS mechanisms, Java EE SIP servlet containers, and service composition technologies.

The authors describe an approach for composing new services using the composition engine and functionality exposed by, for example, SIP applications in a Java EE application server, a service delivery platform (SDP), or standardized IMS enablers.

Introduction

In consumer-driven markets, stiff competition forces operators to complement standard mass-market services with personalized consumer offerings. And because consumer interest is always shifting to new areas, operators should consider increasing their capability to offer a broad range of personalized services rather than invest heavily in one specific service. Therefore efficient service creation becomes a critical factor for system-integration projects that implement individualized consumer offerings. Time to market (TTM) is also increasingly important.

SIP servlet container in IMS

The SIP servlet container, defined in a draft version of JSR289, contains and manages SIP applications and provides access to session initiation protocol (SIP) mechanisms via a Java API.

Java Platform Enterprise Edition (Java EE) is a scalable middleware platform used in the telecom domain. A Java EE application server (AS) is the platform on which the SIP servlet container is deployed. The AS provides network services over which SIP requests and responses are sent and received.

An AS in IMS is connected to the serving call session control function (CSCF) via the IMS server control (ISC) interface. Initiating SIP requests, received by the AS from the CSCF, are passed on to the container. The container identifies the SIP application in question by querying an entity called the application router (AR). The container then dispatches the request to the selected SIP application. Provided the SIP application does not terminate the request, the container queries the AR again for the next SIP application to invoke.

By pushing a route onto the SIP route header (in much the same way as the CSCF routes to an IMS application server), the application router may also instruct the container to route the request to a SIP application deployed on another server.

JSR 289 explicitly avoids specifying the inner working of an application router (AR). In the sections below, we discuss a flexible and dynamic composition engine implementation.