Walkthrough

SLEE Freephone Service

for IN and IMS

22 SEPTEMBER 2010

WALKTHROUGH | SLEE FREEPHONE SERVICE

SEPTEMBER 22, 2010

Copyright and Disclaimers

Copyright 2010 OpenCloud Limited. All rights reserved.
OpenCloud is a trademark of OpenCloud Limited.
Edinburgh House, St John's Innovation Park, Cowley Road, Cambridge CB4 0DS, United Kingdom
Documentation is provided "as is" and all express or implied conditions, representations and warranties,
including any implied warranty of merchantability, fitness for a particular purpose or non infringement, are
disclaimed, except to the extent that such disclaimers are held to be legally invalid.
The information in this document is confidential and meant for use only by the intended recipient and only
in connection with and subject to the terms of its contractual relationship with OpenCloud.
Acceptance and/or use of any of the information contained in this document indicates agreement not to
disclose or otherwise make available to any person who is not an employee of the intended recipient, or to
any other entity, any of the information contained herein. This documentation has the sole purpose of
providing information regarding OpenCloud software products and/or services and shall be disclosed only
to those individuals who have a need to know.
Any entity or person with access to this information shall be subject to this confidentiality
statement. No part of this publication may be reproduced or transmitted in any form or by any
means for any purpose without the express written permission of OpenCloud.

Strictly Confidential
The information in this document is confidential and only available under OpenClouds Nondisclosure Agreement (NDA). It must not be distributed or disclosed to any 3rd party. OpenCloud
reserves the right to change the Product Portfolio information without notice or consultation.
No part of this publication may be reproduced or transmitted in any form or by any means for any purpose.

2010 OpenCloud. All right reserved.

ii

WHITEPAPER | SLEE FREEPHONE SERVICE

SEPTEMBER 22, 2010

Contents
SLEE Freephone Service for IN and IMS
What is the best way to create a call-control application
for IN and IMS?...................................................................1
What is a "multi-protocol" application?...........................................................1
Options for creating multi-protocol call-control applications.......................1
Options for a multi-protocol JSLEE application architecture........................2
Example: multi-protocol SLEE freephone service..........................................3
Initial architecture.........................................................................................3
Adding SIP using Java inheritance...................................................................3
Service class diagram..................................................................................4
Architecture..................................................................................................4
SIP Proxy usage...........................................................................................5
Service Building Blocks (SBBs)........................................................................5
Core logic in an independent SBB...............................................................5
Using a child SBB.........................................................................................6
References...........................................................................................................7

2010 OpenCloud. All right reserved.

iii

WHITEPAPER | SERVICE DELIVERY PLATFORM

DRAFT VERSION 01 | 26/06/2010

OpenClouds Rhino is a real-time application server

for agile development, deployment and efficient
management of person-to-person communication
services across current and next generation
technology. Rhino is a high performance, genuinely
carrier-grade service execution environment for
realizing a Next Generation Service Delivery
Platform (NG-SDP). It uses commercial-off-theshelf
(COTS) hardware and software to deliver service
layer agility to TDM and IP-based networks at a
radically lower price-point than traditional solutions
from network equipment providers.
OpenCloud headquarters are in Cambridge, United
Kingdom. R&D, Engineering and Support are
located in New Zealand, Spain and there are
OpenCloud branch offices in the United States,
Singapore and Japan.

For more information go to:

www.opencloud.com
http://developer.opencloud.com

2010 OpenCloud. All right reserved.

iv

SLEE Freephone Service for IN and IMS

September 22, 2010

SLEE Freephone Service for IN and IMS

What is the best way to create a call-control application for IN

and IMS?
The goal of this article is to present and discuss the best practices for creating call-control applications
that can be deployed in both IN and IMS networks. As an example, it uses the SLEE Freephone Service
to demonstrate how to create an application that can use more than one communication protocol, with
exactly the same application-logic implementation.
This article includes:
a discussion of what multi-protocol means, especially for JSLEE applications
recommended strategies for writing multi-protocol applications
possible architectures for JSLEE multi-protocol applications
a review of the initial architecture of the SLEE Freephone Service, to be used as an example of
converting to a multi-protocol application
an example of enhancing the SLEE Freephone service with an architecture that makes use of Java
inheritance to abstract the application's logic from the communications protocols implementation
an example of further enhancing the SLEE Freephone service using independent SBBs.

What is a "multi-protocol" application?

A common misunderstanding, especially as applied to the JSLEE standard, confuses protocol agnostic
with multi-protocol. Protocol-agnostic software performs its execution, independent of any protocol. Any
SLEE that meets the JSLEE standard criteria is considered protocol agnostic, because it is not dependent
on any protocol (communications or other) to provide its runtime environment.
In the communications context, there is no such thing as a "protocol-agnostic application". That is, two
peers, to be able to communicate with each other, need to agree and use a specific protocol that both
understand. Any call control application will have to "speak" a protocol. In JSLEE it can be any protocol.
For instance, in SIP Servlets

it must be the SIP protocol

A multi-protocol application, executes the same (or equivalent) function in more than one protocol.
For example, an application that works with CAP and SIP to allow deployments in IN and IMS networks,
respectively, would be considered multi-protocol.

Options for creating multi-protocol call-control applications

Common options for creating multi-protocol call-control applications include:

Strategy

How it works

Comments

Independent
Implementations

Create different versions of the

application for every protocol that it
supports.

Due to differing the environments, this

option usually requires recreating the
application from the scratch every time
a new protocol needs to be supported

Protocol
Conversion

Create the application using a specific

protocol, with an external protocol
gateway to convert from that protocol
to others.

A typical example is the IM-SSF

developer.opencloud.com

Commercial in Confidence

node of the IMS architecture. This

component allows operators to give
IMS users access to existing Intelligent
Network (IN) services. The IM-SSF
node converts between ISC (the
protocol used in the IMS network,
between the S-CSCF and a SIP-AS)
and CAP (the protocol used in the GSM
network, between the MSC and the

SLEE Freephone Service for IN and IMS

September 22, 2010

services layer). This approach lets an

application built in a specific protocol be
supported in others but the features
of the protocol-conversion component
limit services, and create overhead.
1

Protocol
Abstraction
(API)

Creates the application using APIs to

abstract the underlying protocol (or
group of protocols).

Java Call Control (JCC) is an example

of an API that aims to abstract
various call control protocols. An API
implementor converts the API into
actions in specific protocols. This
approach uses the minimum common
denominator across all the protocols it
abstracts which usually invalidates
the usage of specific features of some
protocols.

Protocol
Abstraction
(Core Logic)

Creates an implementation that itself

abstracts the underlying protocol (or
group of protocols).

The application (or a component of the

application) creates logic independent
of any protocol, and then defines
a common API to access different
protocols. This approach gives the
application total control over protocol
usage, and lets it use specific features
of different protocols.

For communications, core-logic and API protocol abstraction

Multi-protocol communications applications usually define a state machine for the core logic
of the application, which lets the protocol component control transitions. They also have a
protocol-common API, which defines a set of actions for the core logic to invoke in protocolspecific components.

Options for a multi-protocol JSLEE application architecture

JSLEE offers various approaches to designing an architecture for a multi-protocol service. All, however,
essentially involve a common part handling the service logic (core part) and other specific parts for
protocol-related implementations. Possible design solutions include:

Solution

How it works

Recommended?

Independent
Services

Compose many services inside the SLEE, with a core service

responsible for the common logic, and other services responsible for
specific protocols. They communicate with each other by firing events
and sharing a common state in a null activity or a profile.
For example, a service responsible for the SIP protocol might receive
an Invite event, create the call state, and fire an event. The core
service receives the event, and executes actions associated with it,
persists the state, and fires an event back to the protocol-specific
service.

Java Inheritance

Use an object-oriented approach, such as inheritance, to abstract the

protocol from the core part of the service. The core is not aware of
which communication protocol the service uses, which can be any
protocol the developer creates an implementation for.
Typically this means that a BaseSBB class defines:
the application core logic which includes the state machine,
state persistence, and interaction with other protocols; and the
protocol-specific SBB class extends the BaseSBB class

developer.opencloud.com

Commercial in Confidence

Some
advantages
to the
architecture,
but big
overhead
in
events
processing.

For
applications
with
simple
state
machines
only.

SLEE Freephone Service for IN and IMS

September 22, 2010

methods the protocol-specific logic call, such as callStarted or

callNotAnswered
an interface that represents actions the protocol-specific SBB class
perform, such as rejectCall or forwardCall.
The SLEE sees this solution as one service for each protocol.
Service Building
Blocks (SBBs)

Use an independent SBB, exposed by a local interface, to define the

core logic of the application. The local interface defines methods
that the protocol-specific part calls. This architecture makes use of
the component-based programming model, composing services and
reducing orchestrating overhead.

This
is the
recommended
solution.

Also create an SBB for each protocol the application supports, to handle
protocol specifics and methods that represent actions that the protocolspecific logic performs and exposes through the local interface.
The SLEE sees each protocol-specific application as a service, where
the root SBB has the protocol implementation, and a child SBB with the
application logic. This is a clear use case of component re-usability in
JSLEE.

Example: multi-protocol SLEE freephone service

As an example, we'll change the SLEE Freephone Service into a multi-protocol application. To start,
it supports CAP we'll add support for SIP as well, by changing the application (instead of using an
abstracting protocol).

Initial architecture
Diagram 1 shows the service SLEE components-based architecture and service dependencies. The service
has a root SBB which depends on a profile specification and uses four resource adaptors: Diameter, SMPP,
CDR, and CGIN Unified RA. Ideally you should be able to plug in a new call-control protocol resource
adaptor (SIP in our case) without changing the logic or core functionality of the application.

Diagram 1. Service's original SLEE architecture (basic view)

For a detailed view of the architecture, please see https://developer.opencloud.com/

devportal/display/OCDEV/SLEE+Freephone+Service+for+IN+and+IMS.
Diagrams generated using the Dependency Graph tool.
Review the source code
You may also want to download and review the original source code for the SLEE Freephone
Service.

Adding SIP using Java inheritance

The basic Freephone service can be made multi-protocol using a Java inheritance based architecture.
Below are diagrams and explanations of a revised:
developer.opencloud.com

Commercial in Confidence

SLEE Freephone Service for IN and IMS

September 22, 2010

Service class diagram with core logic abstracted from the protocol
Architecture with reusable components
SIP Proxy usage details of how the SIP Proxy service fits into the architecture.
This implementation is fine for services that have simple state machines and don't require component reusability.
Review the source code
For a complete understanding of how this example works, please review the source code
for this Java-inheritance-enhanced version of the SLEE Freephone service.

Service class diagram

Diagram 2 shows an example of how the Freephone service implementation could be changed to make
the core service logic independent from the communications protocol.

Diagram 2. Service class diagram with SBB class inheritance

This version of the application changes the SBB, moving the core service logic to an independent class
a superclass, which exposes methods representing the application state and performing the application
logic. The superclass also specifies abstract methods that subclasses need to implement. These methods
represent actions performed at the protocol level, such as rejecting a call. By abstracting these actions
from the applications logic, the application is independent of the protocol.
In the SLEE, the subclasses represent the service SBBs and, because they need to be root SBBs to
receive the initial events, each one will be the root SBB of a service. The deployment descriptors have
also changed, to accommodate the new implementation.

Architecture
Diagram 3 shows the service's new SLEE architecture.

developer.opencloud.com

Commercial in Confidence

SLEE Freephone Service for IN and IMS

September 22, 2010

Diagram 3. Service's SLEE architecture using Java inheritance (basic view)

For a detailed view of the architecture, please see https://developer.opencloud.com/

devportal/display/OCDEV/SLEE+Freephone+Service+for+IN+and+IMS.
Diagrams generated using the Dependency Graph tool.
Diagram 3 shows a clear example of the SLEE's component-based architecture. As another example of reusability in this implementation, the Freephone SIP SBB reuses the SIP Proxy SBB bundled with the SIP
examples to receive and send messages. The SIP Proxy SBB in turn interacts with the SIP Registration
and SIP Location of User Agents. (In the future the Proxy SBB could be replaced, for example, with a
B2BUA.)

SIP Proxy usage

Diagram 4 shows in more detail of the SIP Proxy usage.

Diagram 4. Service's SLEE architecture using Java inheritance, with detailed SIP
components

Service Building Blocks (SBBs)

The Java-inheritance-enhanced implementation of a service can evolve to a more components-based
architecture. For example, you could more clearly separate functionality, to make protocol-specific SBBs
reusable by other services. Below are examples of changing the architecture using separate SBBs for core
logic and child SBBs.
Review the source code
For a complete understanding of how this example works, please review the source code
for this SBB-enhanced version of the SLEE Freephone service.

Core logic in an independent SBB

Diagram 5 shows the class diagram of an example implementation. The core logic of the service was
moved to an independent SBB. This SBB is used as a child SBB of protocol SBB implementations. The
protocol SBBs use the Child SBB Local Object to notify it of state change and implement a listener
interface which the Child SBB calls back to perform protocol specific actions.

developer.opencloud.com

Commercial in Confidence

SLEE Freephone Service for IN and IMS

September 22, 2010

Diagram 5. Service class diagram with child SBB

Although the class diagram seems to present a more complex implementation, the additional
development effort is nominal. Moreover, this architecture creates a more future proof implementation.

Using a child SBB

Diagram 6 shows the service's SLEE architecture using a child SBB. The diagram demonstrates clearly the
dependencies between components. No components have more than one depender.

Diagram 6. Service's SLEE architecture with child SBB (basic view)

For a detailed view of the architecture, please see https://developer.opencloud.com/

devportal/display/OCDEV/SLEE+Freephone+Service+for+IN+and+IMS.
Diagrams generated using the Dependency Graph tool.

developer.opencloud.com

Commercial in Confidence

SLEE Freephone Service for IN and IMS

September , 2010

References
Ref
Notes
1
Cosmadopoulos, Y., Kulkarni, M., SIP Servlet API Version 1.1, http://www.jcp.org/en.jsr/detail?
id=289, August 2008
2
IETF RFC 3261, SIP: Session Initiation Protocol, http://www.ietf.org/rfc/rfc3261.txt, June 2002
3
3GPP TS 23.218, IP Multimedia (IM) session handling; IM call model; Stage 2, http://
www.3gpp.org/ftp/Specs/html-info/23218.htm, December 2008
4
John-Luc Bakker, Telcordia Technologies, Inc., JSR21: JAINTM JCC Specification, http://jcp.org/en/
jsr/detail?id=21, June 2002

developer.opencloud.com

Commercial in Confidence