FreephoneWalkthru in IMS

7/25/2019 FreephoneWalkthru in IMS

http://slidepdf.com/reader/full/freephonewalkthru-in-ims 1/11

Walkthrough

SLEE Freephone Servicefor IN and IMS

22 SEPTEMBER 2!



W"L#T$R%&'$ ( SLEE FREEP$%NE SER)I*E SEPTEMBER 22+ 2!

Copyright and Disclaimers

*op,right - 2! %pen*loud Li.ited/ "ll right0 re0erved/

%pen*loud1 i0 a trade.ark of %pen*loud Li.ited/

Edinurgh $ou0e+ St 3ohn40 Innovation Park+ *o5le, Road+ *a.ridge *B6 7S+ &nited #ingdo.

7ocu.entation i0 provided 8a0 i08 and all e9pre00 or i.plied condition0+ repre0entation0 and 5arrantie0+

including an, i.plied 5arrant, of .erchantailit,+ fitne00 for a particular purpo0e or non infringe.ent+ aredi0clai.ed+ e9cept to the e9tent that 0uch di0clai.er0 are held to e legall, invalid/

The infor.ation in thi0 docu.ent i0 confidential and .eant for u0e onl, , the intended recipient and onl,

in connection 5ith and 0u:ect to the ter.0 of it0 contractual relation0hip 5ith %pen*loud/

"cceptance and;or u0e of an, of the infor.ation contained in thi0 docu.ent indicate0 agree.ent not to

di0clo0e or other5i0e .ake availale to an, per0on 5ho i0 not an e.plo,ee of the intended recipient+ or to

an, other entit,+ an, of the infor.ation contained herein/ Thi0 docu.entation ha0 the 0ole purpo0e of

providing infor.ation regarding %pen*loud 0oft5are product0 and;or 0ervice0 and 0hall e di0clo0ed onl,

to tho0e individual0 5ho have a need to kno5/

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 anymeans for any purpose without the express written permission of OpenCloud.

Strictly Confidential

The information in this document is confidential and only aailable under OpenCloud!s Non"

disclosure Agreement #NDA$. %t must not be distributed or disclosed to any &rd party. OpenCloud

reseres the right to change the 'roduct 'ortfolio information without notice or consultation.

No part of thi0 pulication .a, e reproduced or tran0.itted in an, for. or , an, .ean0 for an, purpo0e/

- 2! %pen*loud/ "ll right re0erved/ ii



W$ITEP"PER ( SLEE FREEP$%NE SER)I*E SEPTEMBER 22+ 2!

*ontent0SLEE Freephone Service for IN and IMS

(hat is the best way to create a call"control applicationfor %N and %)S*...................................................................+

(hat is a ,multi"protocol, application*...........................................................+

Options for creating multi"protocol call"control applications.......................+

Options for a multi"protocol -S// application architecture........................0

/xample1 multi"protocol S// freephone serice..........................................&

Initial architecture/////////////////////////////////////////////////////////////////////////////////////////<

Adding S%' using -aa inheritance...................................................................&

Service cla00 diagra.//////////////////////////////////////////////////////////////////////////////////6

"rchitecture//////////////////////////////////////////////////////////////////////////////////////////////////6

SIP Pro9, u0age///////////////////////////////////////////////////////////////////////////////////////////=

Serice 2uilding 2loc3s #S22s$........................................................................4

*ore logic in an independent SBB///////////////////////////////////////////////////////////////=

&0ing a child SBB/////////////////////////////////////////////////////////////////////////////////////////>

5eferences...........................................................................................................6

- 2! %pen*loud/ "ll right re0erved/ iii



W$ITEP"PER ( SER)I*E 7ELI)ER? PL"TF%RM 7R"FT )ERSI%N ! ( 2>;>;2!

%pen*loud@0 Rhino i0 a realAti.e application 0erver

for agile develop.ent+ deplo,.ent and efficient

.anage.ent of per0onAtoAper0on co..unication

0ervice0 acro00 current and ne9t generation

technolog,/ Rhino i0 a high perfor.ance+ genuinel,

carrierAgrade 0ervice e9ecution environ.ent for

realiing a Ne9t 'eneration Service 7eliver,

Platfor. CN'AS7PD/ It u0e0 co..ercialAoffAthe0helf

C*%TSD hard5are and 0oft5are to deliver 0ervice

la,er agilit, to T7M and IPAa0ed net5ork0 at a

radicall, lo5er priceApoint than traditional 0olution0

fro. net5ork euip.ent provider0/

%pen*loud headuarter0 are in *a.ridge+ &nited

#ingdo./ R7+ Engineering and Support are

located in Ne5 Gealand+ Spain and there are

%pen*loud ranch office0 in the &nited State0+

Singapore and 3apan/

For .ore infor.ation go toH

www.opencloud.com

http177deeloper.opencloud.com

- 2! %pen*loud/ "ll right re0erved/ i

http://www.opencloud.com/

http://developer.opencloud.com/





SLEE Freephone Service for IN and IMSSeptember 22, 2010

developer.opencloud.com Commercial in Confidence 1

SLEE Freephone Service for IN and IMS

What is the best way to create a call-control application for INand IMS?

The goal of this article is to present and discuss the best practices for creating call-control applicationsthat can be deployed in both IN and IMS networks. As an example, it uses the SLEE Freephone Serviceto demonstrate how to create an application that can use more than one communication protocol, withexactly 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 agnosticwith multi-protocol. Protocol-agnostic software performs its execution, independent of any protocol. AnySLEE that meets the JSLEE standard criteria is considered protocol agnostic, because it is not dependenton 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, twopeers, to be able to communicate with each other, need to agree and use a specific protocol that bothunderstand. Any call control application will have to "speak" a protocol. In JSLEE it can be any protocol.

For instance, in SIP Servlets 1 it must be the SIP protocol 1 .

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

IndependentImplementations

Create different versions of theapplication for every protocol that itsupports.

Due to differing the environments, thisoption usually requires recreating theapplication from the scratch every timea new protocol needs to be supported

ProtocolConversion

Create the application using a specificprotocol, with an external protocolgateway to convert from that protocolto others.

A typical example is the IM-SSF

node1 of the IMS architecture. This

component allows operators to giveIMS users access to existing IntelligentNetwork (IN) services. The IM-SSFnode converts between ISC (theprotocol used in the IMS network,between the S-CSCF and a SIP-AS)

and CAP (the protocol used in the GSMnetwork, between the MSC and the


https://developer.opencloud.com/devportal/display/OCDEV/SLEE+Freephone+Service

https://developer.opencloud.com/devportal/display/OCDEV/SLEE+Freephone+Service+for+IN+and+IMS#Footnote1










services layer). This approach lets anapplication built in a specific protocol besupported in others — but the featuresof the protocol-conversion componentlimit services, and create overhead.

ProtocolAbstraction(API)

Creates the application using APIs toabstract the underlying protocol (orgroup of protocols).

Java Call Control (JCC) 1 is an exampleof an API that aims to abstractvarious call control protocols. An APIimplementor converts the API intoactions in specific protocols. Thisapproach uses the minimum commondenominator across all the protocols itabstracts — which usually invalidatesthe usage of specific features of someprotocols.

ProtocolAbstraction(Core Logic)

Creates an implementation that itself abstracts the underlying protocol (orgroup of protocols).

The application (or a component of theapplication) creates logic independentof any protocol, and then definesa common API to access differentprotocols. This approach gives theapplication total control over protocolusage, and lets it use specific featuresof different protocols.

For communications, core-logic and API protocol abstractionMulti-protocol communications applications usually define a state machine for the core logicof the application, which lets the protocol component control transitions. They also have aprotocol-common API, which defines a set of actions for the core logic to invoke in protocol-specific 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 forprotocol-related implementations. Possible design solutions include:

Solution How it works Recommended?

IndependentServices

Compose many services inside the SLEE, with a core serviceresponsible for the common logic, and other services responsible forspecific protocols. They communicate with each other by firing eventsand sharing a common state in a null activity or a profile.

For example, a service responsible for the SIP protocol might receivean Invite event, create the call state, and fire an event. The coreservice receives the event, and executes actions associated with it,persists the state, and fires an event back to the protocol-specificservice.

Someadvantagesto thearchitecture,but bigoverheadineventsprocessing.

Java Inheritance Use an object-oriented approach, such as inheritance, to abstract theprotocol from the core part of the service. The core is not aware of which communication protocol the service uses, which can be anyprotocol 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 theprotocol-specific SBB class extends the BaseSBB class

Forapplicationswithsimplestate

machinesonly.








• methods the protocol-specific logic call, such as callStarted orcallNotAnswered

• an interface that represents actions the protocol-specific SBB classperform, such as rejectCall or forwardCall.

The SLEE sees this solution as one service for each protocol.

Service BuildingBlocks (SBBs)

Use an independent SBB, exposed by a local interface, to define thecore logic of the application. The local interface defines methodsthat the protocol-specific part calls. This architecture makes use of the component-based programming model, composing services andreducing orchestrating overhead.

Also create an SBB for each protocol the application supports, to handleprotocol specifics and methods that represent actions that the protocol-specific logic performs and exposes through the local interface.

The SLEE sees each protocol-specific application as a service, wherethe root SBB has the protocol implementation, and a child SBB with theapplication logic. This is a clear use case of component re-usability inJSLEE.

Thisis therecommendedsolution.

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 anabstracting protocol).

Initial architecture

Diagram 1 shows the service SLEE components-based architecture and service dependencies. The servicehas 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 resourceadaptor (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 codeYou may also want to download and review the original source code for the SLEE FreephoneService.

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:

https://developer.opencloud.com/svn/examples/1.1/freephone/trunk/freephone-v.0.3/

https://developer.opencloud.com/devportal/display/OCDEV/SLEE+Freephone+Service+for+IN+and+IMS





https://developer.opencloud.com/devportal/display/RD/4+dependency-graph










• 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 re-usability.

Review the source codeFor a complete understanding of how this example works, please review the source codefor 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 makethe 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 applicationlogic. The superclass also specifies abstract methods that subclasses need to implement. These methodsrepresent actions performed at the protocol level, such as rejecting a call. By abstracting these actionsfrom 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 toreceive 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.









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



Diagram 3 shows a clear example of the SLEE's component-based architecture. As another example of re-usability in this implementation, the Freephone SIP SBB reuses the SIP Proxy SBB bundled with the SIPexamples to receive and send messages. The SIP Proxy SBB in turn interacts with the SIP Registrationand SIP Location of User Agents. (In the future the Proxy SBB could be replaced, for example, with aB2BUA.)

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 SIPcomponents

Service Building Blocks (SBBs)

The Java-inheritance-enhanced implementation of a service can evolve to a more components-basedarchitecture. For example, you could more clearly separate functionality, to make protocol-specific SBBsreusable by other services. Below are examples of changing the architecture using separate SBBs for corelogic and child SBBs.

Review the source codeFor a complete understanding of how this example works, please review the source codefor 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 wasmoved to an independent SBB. This SBB is used as a child SBB of protocol SBB implementations. Theprotocol 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.

https://developer.opencloud.com/devportal/display/RD/Sample+SIP+Applications














Diagram 5. Service class diagram with child SBB

Although the class diagram seems to present a more complex implementation, the additionaldevelopment 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 thedependencies between components. No components have more than one depender.

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














SLEE Freephone Service for IN and IMSSeptember , 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 20023 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


https://developer.opencloud.com/devportal/display/OCDEV/SLEE+Freephone+Service+for+IN+and+IMS#FootnoteMarker1

http://www.jcp.org/en.jsr/detail?id=289



http://www.ietf.org/rfc/rfc3261.txt


http://www.3gpp.org/ftp/Specs/html-info/23218.htm



http://jcp.org/en/jsr/detail?id=21








http://www.ietf.org/rfc/rfc3261.txt







FreephoneWalkthru in IMS

Documents