Simplify your media application development with …...White Paper Simplify your media application development with JSR 309 October 2008 Comverse Proprietary Page 3 of 3 Table of Contents

Comverse October 2008

Simplify your media application development with JSR 309

White Paper

White Paper Simplify your media application development with JSR 309

October 2008 Comverse Proprietary Page 2 of 2

Copyright and Trademarks

© 2004–2008 Comverse. All rights reserved. This document contains proprietary and confidential material of Comverse and its affiliates and is protected by U.S. and international laws relating to intellectual property. Any unauthorized reproduction, use, or disclosure of this material, or any part thereof, is strictly prohibited. This document is solely for the use of Comverse employees and authorized Comverse customers.

Comverse, its logo, the spark design, Kenan, and Netcentrex are registered trademarks of Comverse Technology, Inc. or its subsidiaries in the United States and may also be registered in other countries. Other denoted product names of Comverse or other companies may be trademarks or registered trademarks of Comverse, Inc. or its subsidiaries, or their respective owners.



Table of Contents

1. Introduction 5

2. JSR309 or a need for a new common way to control the Media Server 5

3. Media Platform vendors can develop a JSR309 driver using their existing

media server protocol 6

4. A straightforward way to control all media processing capabilities 8

5. Multimedia Services developed as any Java EE application 9

5.1 Sample1 : Multiparty audio and video conferencing demo 9

5.2 Sample2 : Video surveillance and Alert demo 13

6. Summary 14



List of Figures

Figure 1 – JSR309 with OMP: Architecture overview 7

Figure 2 – Multiparty audio and video conferencing demo 10

Figure 3 – Video Surveillance and Alert Demo 13



1. Introduction

Media servers have always been associated with clearly defined business models and they are still supporting critical applications for service providers. Carriers are now moving increasingly to VoIP and IMS. This evolution is exposing media servers to a very wide array of new features, interfaces and protocols.

Although media servers are increasingly presenting richer features, application developers face the challenge of drilling down to the proprietary protocols and libraries.

There is therefore the need for an abstraction layer that is generic and not specific to a particular Media Server. This generic API would be agnostic to underlying protocols and therefore free application developers from the need to master Media server specific APIs.

This is the objective of the JSR309.

This document provides application developers an overview and the benefits of the JSR309 API and several samples to illustrate this API and its simplicity of use.

2. JSR309 or a need for a new common way to control the Media Server

The development of multimedia services has significantly evolved during the last few years. Media Server vendors’ proprietary languages have been dropped in favour of VoiceXML, which has been completed by CCXML to add missing call control capabilities. Both are standard script-based languages which allow multimedia services to be deported to a Web application server and developed in almost the same way as any web application.

In a second step, Session Initiation Protocol (SIP) has become the standard common protocol between the telephony network components. With SIP, a new model for media server control is growing in popularity: Multimedia services can be deployed on SIP Application Servers (AS) communicating with the network directly in SIP.

However the control protocol between the AS and the Media Platform is still not standard. Firstly, SIP allowed developers to invoke a few simple media capabilities like scripted IVR applications in VoiceXML with the underlying protocol Netann (RFC 4240). But as it was not sufficient enough for more complex services requiring mid-call controls such as multiparty conferencing, several other media-control SIP-based protocols have emerged from different vendors: MSCML, MSCP, MSML+MOML, etc.

Developing multimedia services for the SIP model therefore requires dealing with the complexity of one or more of these protocols. Java SIP Application Servers such as Oracle Communications Converged Application Server already provide the SIP Servlet API (JSR 116 / 289) to simplify the development of SIP based applications. But it’s still not that easy to integrate those media-control protocols. This leads to a more complex, skill-to-build development process and no more cross operability if the target application must run on different media platforms.

The solution was to abstract all these protocols with a standard API layer, handling all the media server operations in a standard way. That’s exactly the



main objective of the upcoming JSR309: a protocol agnostic API between AS and Media platforms.

3. Media Platform vendors can develop a JSR309 driver using their existing media server protocol

Since there is no need for a common Media Platform standard protocol, Media Platform vendors can develop their JSR 309 driver reusing their existing protocol and extend it when necessary with commands that match with their Media Platform’s internal mechanism.

By limiting the JSR309 implementation impact on the Media Platform, it’s easier and faster to develop a JSR309 driver than to integrate any standard media-control protocol.

There is now no need to rely on other vendor’s standard protocols which may restrict the control of some media capabilities or add overheads.

There are other advantages to add an API on the AS side instead of leaving applications dealing directly with the protocol: The driver indeed guarantees that the protocol is respected; it sends only the media commands that can be processed according to the media execution states and most of the error cases can be handled directly on the AS-side without asking the Media Platform. As a result, this significantly reduces the complexity and among of messages that are carried between those two components limiting the signaling traffic, reducing the processing complexity on the Media Platform side and redundancy with the AS side.

JSR309 is not an API for a specific protocol. Implementing JSR309 features that are not already supported by the current protocols can be created either by extending an already existing protocol or creating a new proprietary protocol. Media Platform vendors are therefore able to choose from the full range of solutions the one that is best for them!

For example, Comverse used its existing Media Platform MSML interface to develop a JSR309 driver, and complemented it with some extensions to support advanced JSR309 features. Being able to reuse the existing media control interface allowed us to significantly reduce the time to develop the driver.

The AS-side part of our driver used the SIP Servlet API (JSR116) since MSML commands are carried on SIP INFO. This API has been also a key for a fast driver development. However, the JSR309 is not dependent on the SIP Servlet API. Other implementations could use for instance H.248 as the protocol through the Media Platform.



Figure 1 – JSR309 with OMP: Architecture overview

Following the above guidelines, it is possible to develop a JSR309 driver very rapidly. This first version of the Comverse driver has made our Media Platform, OMP, already compatible with the JSR309 EDR Core-Media based applications and supports the following features:

• Control of the audio/video stream resources. Provides applications with early media capability.

• Mixing of multiple multimedia streams, independently on each media with features such as

o Mute / secret capability

o Different video layout (display of 1, 4 or 9 participants)

• Media stream sources such as

o Play announcements, multimedia files (file:// and http:// protocols), tones

o Play RTSP sources

• Multimedia stream processing

o Transcoding, transizing, transrating … media stream adaptation such as: dynamic video frame rate, bit rate or picture size adaptation per output multimedia stream

o Mixing and media insertion of: audio, video, picture …

• Media stream sink



o Record, store, cache

o Detect events like DTMF

• Interactive media streams

o With play, record and DTMF detection.

4. A straightforward way to control all media processing capabilities

On the multimedia service developer side, this API provides a very powerful way to access all advanced media processing functions of today’s Media Platforms, regardless of the Media Platform vendor.

Developers will obviously need time to learn all the tips and tricks of JSR309. But developing basic media services can be done with a few lines of code.

For instance, for a service announcement, the application would just have to complete the following main actions:

• Initialize the API by giving it the Media Server URI

• Create a Network Connection for the incoming call

• Create a Media Group which adds the Media Server’s IVR functions to the application

• Connect both together

• Call the play command by specifying the media file URI.

• The end of the play file will be reported through an event listener.

Of course, as for every SIP AS hosted telephony service, developers still have to handle the incoming calls and other media related events carried in SIP (DTMF in SIP INFO, Video Fast Update, re-INVITE) via the SIP Servlet API. This call management part has not been simplified. But it is not the aim of the JSR309 and for developers already familiar with this java SIP layer it should be very easy!

The JSR309 API therefore greatly complements the SIP Servlet API. It simplifies this programming model by giving a new object model to directly control the media server. There is no longer any need to deal with the protocol through the media server which is behind it.

The simplicity of the application doesn’t prevent the JSR309 API from being a complete solution.

The JSR309 API allows more than just call control and basic media processing features. For IVR-like applications, VoiceXML scripts can still be used. Even advanced media processing functions such as speech recognition, text to speech or multiparty conferencing scene construction with logo, streaming, images or text inlay are already available.

This API has also been designed to be very flexible and extensible. It offers low level objects like players, recorders, mixers and connections that developers can manipulate or combine together to obtain all the multimedia capabilities. As everything is just object based, new features can be added very easily without breaking the core model. A higher level API is already planned and will add composition of the low level objects



such as conference or IVR dialog objects that should simplify the creation of these commonly used multimedia applications.

5. Multimedia Services developed as any Java EE application

In addition, JSR309 applications are directly integrated into the widespread Java EE environment and take advantage of all these services and useful API.

Consequently, multimedia services can be developed with the same tools as any java applications and are deployed in the same way as any java application server services.

Any java SIP application running on java SIP server can use this API. It just needs the generic JSR309 library and the Media Platform vendor’s specific driver. Some configuration may be needed. It’s the case for the Comverse driver which uses a SIP Servlet, a CommonJ Timer and WorkManager that need to be referenced in the application’s file descriptors. That’s all! The application is then able to create the JSR309 Media Session Factory, the entrance point to all the JSR309 API objects.

try { MscontrolFactory.getInstance().setPathName("com.comverse"); Properties msfProperties = new Properties(); msfProperties.setProperty("ms_uri", "< MS URI >"); msfProperties.setProperty("as_uri", "< AS URI >"); MediaSessionFactory theMediaSessionFactory = MscontrolFactory.getInstance().createMediaSessionFactory(msfProperties); } catch (MscontrolException e) { (...) }

Moreover, a very interesting feature of this API is the ability to develop multimedia applications converged with web applications and with no additional effort.

5.1 Sample1 : Multiparty audio and video conferencing demo

How does it work? The conference organizer creates a conference in the conference web page. Optionally he can specify a conference master which is identified by its SIP URI. He notifies the participants in advance of the conference using his traditional communication tools (email, SMS, etc) and gives them the necessary dial-in information: the service number as the conference identifier, conference time and the required PIN code.

Participants simply dial the conference service number sent by the organizer and access the conference through an interactive voice/video portal.

This audio and video conferencing application provides different functions which include:

• Video layout is automatically updated according to the number of participants (1, 4, 9 simultaneous videos).

• Conferencing sessions are PIN-code protected.

• Participants’ names are recorded and played when they enter the conference.

• Participants can hide their video or quit the conference with a DTMF key.



• The conference master can control the audio and/or video muting of the other conference lines using DTMF keys or they can close the whole conferencing session.

• Furthermore, using the web control interface, it is also possible to create new conferencing sessions and monitor them by displaying the current participants. This leads to the same level of bridge supervision, and in a few clicks, to have control over any participant: muting/unmuting of the line or video, terminating the call or removing the participant from the conference session.

How has it been developed with the JSR309 API

Figure 2 – Multiparty audio and video conferencing demo

The SIP part of this application has been created using a single SIP Servlet that handles all the signaling traffic between the AS and the network; the web part has simply been developed using the HTTP servlet / JSP model. Any other Java EE API or framework that web developers are familiar with can be used without limitation.

Both parts share the same java objects: a list of Participants and another of Conference Sessions. With JSR309, the Media Platform control is done by simply calling the right methods on the corresponding JSR309 objects. A Participant object contains 2 JSR309 objects:



• A NetworkConnection that stands for a user on his phone. It is used to send its SDP to the Media Platform and to retrieve the Media Platform’s one.

• A MediaGroup which is joinded to the NetworkConnection. It controls the Media Platform IVR functions (prompt, collect, record) for this particular user.

A Conference Session object stores the list of participants and contains 3 JSR309 objects:

• A Mixer that controls the Media Platform stream mixer providing audio/video conferencing capabilities.

• A VideoRenderer which is a Mixer resource used to change the conference video layout.

• A MediaGroup which is joined to the mixer providing in this case prompt and record functions for the whole conference.

On reception of an INVITE, the SIP servlet instantiates a participant object. This creates the participant’s NetworkConnection and MediaGroup, joins them together and asks the NetworkConnection to exchange the incoming call’s SDP offer with the Media Platform:

try { myMediaSession =

ConferenceServlet.theMediaSessionFactory.createMediaSession(); myNetworkConnection =

myMediaSession.createContainer(NetworkConnectionConfig.c_Basic); myMediaGroup =

myMediaSession.createContainer(MediaGroupConfig.c_PlayerRecorderSignalDetector);

myNetworkConnection.join(Joinable.Direction.DUPLEX, myMediaGroup); myNetworkConnection.modify("$", new

String(sipServletRequest.getRawContent())); //send the user’s SDP to the Media Platform

} catch (Exception e) { (...) }

In order to reply to the incoming call, the SDP answer is retrieved from the NetworkConnection this way:

String SDPanswer = myNetworkConnection.getRawLocalSessionDescription();

The MediaGroup is then used to play multimedia files, retrieve the 4-digit conference PIN number and record the participant’s name:

URI welcomeMessage = URI.create("http://myserver.com/welcome.wav”); URI recordedName =

URI.create("file:///tmp/records/”+myNetworkConnection.toString()+”.wav”);

(...)

myMediaGroup.getPlayer().play(welcomeMessage, {RTC.SigDet_StopPlay}, Parameters.NO_PARAMETER);

(...)

myMediaGroup.getSignalDetector().receiveSignals(4, null, RTC.NO_RTC, Parameters.NO_PARAMETER); (...) myMediaGroup.getRecorder().record(recordedName,

{RTC.SigDet_StopRecord}, Parameters.NO_PARAMETER);



The ‘RTC.SigDet_Stop…’ parameter asks the Media Server to stop playing or recording when any DTMF is pressed. Different conditions and actions are available for this Run Time Control (RTC) mechanism that allows a fast reaction without requiring the intervention of the application.

Of course several other parameters exist for these basic media commands such as a record max duration, but they are not showed here.

The MediaGroup joined to a conference session’s mixer can do the same media function, except collecting DTMF. It is used to announce the arrival of a new participant by playing his or her recorded name to the others. Furthermore, listeners have to be set in order to receive events or asynchronous method results from the MediaGroup or the NetworkConnection. For instance, the following shows the participant's signal detector listener that receives notifications on DTMF pressed during the conference. If the participant presses a ‘*’ DTMF, then his or her video will be hidden or displayed to the others. This is done by simply changing the direction of the participant’s network connection video stream joined with its conference session’s mixer among ‘receive only’ and ‘duplex’,: (...)

myMediaGroup.getSignalDetector().addListener(new SignalDetectorListener()); (...)

class SignalDetectorListener implements MediaEventListener<SignalDetectorEvent> { public void onEvent(SignalDetectorEvent anEvent) { if(anEvent.getError().equals(ResourceConstants.e_OK)) { try { (...) if (anEvent.getSignalString().equalsIgnoreCase("*")) { isVideoMuted =! isVideoMuted; //boolean that stores if the video is hidden or not if(isVideoMuted) { myNetworkConnection.getJoinableStream(StreamType.video). join(Joinable.Direction.RECV, myConferenceSession.getMediaMixer()); } else { myNetworkConnection.getJoinableStream(StreamType.video). join(Joinable.Direction.DUPLEX, myConferenceSession.getMediaMixer()); } } (...)

} catch (Exception e) { (...)

} } else { //It's an error event (...)

} } }



The service call flow has been implemented by defining different behaviors for the event listeners’ call back depending on the participant states. At any time, the HTTP servlet and JSP pages can access to the participants and conference sessions objects and call the JSR309 methods in the same way. Only a few days were needed to develop this application.

5.2 Sample2 : Video surveillance and Alert demo

How does it work? The video surveillance application allows subscribers to keep an eye on their home or family (video surveillance, baby monitoring, ...) by accessing personal cameras via a video portal, viewing all cameras simultaneously or selecting one particular camera.

In addition, it is complemented by the alert option: when a movement is detected, the user is called on his or her mobile and sees an image presenting the move detection which triggered the alert; The customer then connects to the live video feed of the camera by pressing a key to view all cameras simultaneously or one particular camera.

Figure 3 – Video Surveillance and Alert Demo



6. Summary

JSR309 API gives to the java SIP application servers the missing, easy to use, standard way to add media capabilities to their JSR116-based telephony application. Since it proposes an abstract layer above existing media control protocols, media platform vendors should be able to rapidly create a driver.

This API doesn’t aim to replace the commonly used VoiceXML web model, but to offer additional functions that are still missing. It simplifies the integration of the multimedia services call control on the AS side, a function that usually requires heavy telephony skills. AS hosted applications can now directly invoke basic media capabilities without having to use VoiceXML scripts. Multiparty conferencing services using mid-call controls and DTMF interactions are also supported. All of this is integrated in the robust standard Java EE platform which allows the development of converged web-telephony applications and helps create new innovative multimedia services.

Even if developers still need to have solid knowledge on the telephony basics regarding the call management and a good understanding of the protocol-level SIP Servlet API, this new API is the key to simplifying media application programming.



About Comverse

Comverse is the world’s leading provider of software and systems enabling network-based multimedia enhanced communication and billing services. The company’s Total Communication

SM portfolio includes a rich range of Messaging, Billing, Content,

Converged IP Communications and Handset Software solutions. Over 500 communication and content service providers in more than 130 countries use Comverse products to generate revenues, strengthen customer loyalty and improve operational efficiency.

Comverse Converged IP Communications provide IP-based voice, video solutions that enable communication service providers to deliver fixed and mobile services to consumer and enterprise markets.

Our portfolio is based on expertise from the acquisition of Netcentrex™ and provides advanced VoIP, IP Centrex, Multi-Play, IMS solutions with FMC capabilities and the Open Media Platform. Our deployments represent over seven million Voice over IP lines in commercial service.

Comverse Open Media Platform is a Unique SRF/MRF/IP Media Solution. OMP addresses all fixed and/or mobile operators’ media resource requirements for all networks thanks to its unique combination of Intelligent Peripheral (aka Specialized Resource Function (SRF)), Media Resource Function (MRF) and IP Media Server on the same platform.

For more information on our products and services, visit our website at www.comverse.com or contact us at [email protected]

Copyright ©2008 Comverse, Inc. All Rights Reserved. Comverse its logo, the spark design, Kenan and Netcentrex are registered trademarks of Comverse Technology, Inc., or its subsidiaries, in the United States and may be registered in other countries. Other denoted product names of Comverse or other companies may be trademarks or registered trademarks of Comverse, Inc. or its subsidiaries, or their respective owners. The materials presented here are summary in nature, subject to change and intended for general information only.

Documents

Simplify your media application development with …...White Paper Simplify your media application development with JSR 309 October 2008 Comverse Proprietary Page 3 of 3 Table of Contents