Dev2Dev > Articles

---

Exposing a Radisys Convedia Media Server feature as a Web Service using WebLogic SIP Server

by Marcelo Oliveira, Jeff Bean and Garland Sharratt
12/20/2006

Abstract

As telecom networks converge with IT networks, we are beginning to see requirements for controlling telecom network elements from an IT Service Oriented Architecture (SOA). As telecom networks become more IP-based, media servers such as the RadiSys family of Convedia Media Servers become integral to any IP-based communications solution. BEA Weblogic SIP Server can be used to expose media-rich communications features such as streaming video as Web services, allowing applications such as Content Delivery or IVR to be created as a composition of SOA-based IT services and SIP features rather than as monolithic applications themselves.

This article presents a sample SIP servlet-based application built using BEA WebLogic Workshop that leverages WebLogic SIP Server to drive any products in the RadiSys family of Convedia Media Servers, which include the CMS-1000, CMS-3000, CMS-6000, and CMS-9000. The application we demonstrate makes use of Media Sessions Markup Language (MSML) to play a video announcement, a feature that is fairly unique to this family of media servers.

Hardware and Software Requirements

In order to run the application described in this article, you must have access to:

• A RadiSys Convedia Media Server, provisioned with sample video clips that will be streamed to SIP clients. The Convedia Media Server is a hardware-based solution that needs to be configured and made available within the reaches of your test network. RadiSys may be able to make a remote server available to you upon request for the purposes of this article. If interested, please contact
• Windows Messenger 4.7 will be used as the SIP client for receiving the streamed video. Windows Messenger 4.7 is available for download here. Windows Messenger 4.7 was selected because this precise version of Windows Messenger fully supports SIP in a fairly transparent fashion.
• WebLogic Workshop version 8.1
• WebLogic SIP Server version 2.2

Documentation for installing and configuring WebLogic Workshop and the WebLogic SIP Server domains is available in the Download area.

Introduction

Media server control is vital to any SIP-based multimedia application involving complex content delivery for multiple parties. While WebLogic SIP Server can be used for the call control and session management aspects of an application that uses SIP, a media server is needed for any media processing required by the application. Here are some examples of the tasks this media server can perform:

• Voice and video conferencing, including mixing of multiple audio streams and switching between active video streams
• Playing and recording of audio and video
• DTMF (Dual Tone MultiFrequency) capture and recognition
• IVR, including VoiceXML parsing and browsing

This article presents a sample video streaming application that was written by BEA for the purposes of demonstrating how to do the following:

• Expose the functionality of a SIP-based application using Web services in the Workshop platform.
• Build WebLogic SIP Server applications using WebLogic Workshop
• Achieve interoperability with a Convedia Media Server using MSML to play video clips to a SIP client.

The application provides a Web service facade that allows the application functionality to be easily used by other applications. The intention is that this Web services facade can be connected to the larger Service Oriented Architecture to expose the media server features to the larger enterprise.

For example, in the application presented here, video clips could be purchased by IMS subscribers using a mobilized content portal also connected to the SOA. After the purchase, the selected content could be streamed on demand to the subscriber's IMS device using SIP and RTP. Streaming is a key feature that allows the end user to start viewing the video almost immediately, without having to wait for the whole file to be downloaded.

Application Architecture

The application consists of three major components:

• The Web application provides the Web service façade. This is present in the WebApp folder of the project. This Web service serves as an example for exposing streaming media as a Web service.
• The SIP application provides the third-party call control flow logic of managing the video streaming session between the end user's SIP device and the media server. This is present in the SipStreamingApp folder of the project.
• The SIP proxy/registrar application acts as the SIP registrar and as the outbound proxy for the SIP clients and application servers. It proxies incoming requests according to the registrar stored information. This is a jar file that is provided for you.

Web application

The installation instructions detail how to create a SIP domain to support development of SIP servlets in Workshop. This allows us to expose the application functionality as a Web Service with a couple of mouse clicks. In addition, the direct support for XML beans in the IDE makes it trivial to work with the XSDs of the MSML language. Here, we include the subset of those schemas required for the application.

For the purposes of logical separation, the Workshop project is divided into two relevant folders: the Web application folder (WebApp), and the streaming application folder (SipStreamingApp). The WebApp folder contains the Web service that is used to start new streaming sessions.

Streaming application

The SipStreamingApp folder contains the com.bea.appserver.streaming package, which is the business logic behind the video streaming functionality itself, including the call flow logic implemented by SIP servlets to receive and send SIP messages and state control classes for managing the call flows. The classes com.bea.appserver.streaming.AnnouncementManager and com.bea.appserver.streaming.AnnouncementSession serve as the interface point between the SIP application business logic and the Web service front end.

The AnnouncementManager class is a singleton, with the sole purpose of aggregating all the ongoing streaming sessions. The AnnouncementSession class encapsulates the whole streaming behavior, and maintains the information about which clip is supposed to be played and to whom. It abstracts completely from the protocol details, which are pushed into the DialogHandler implementation classes: DialoutClientDialogHandler and ServerDialogHandler. The Listener design pattern is used throughout on the application architecture. The Listener pattern fits the event-driven nature of the application very well and is used to communicate information from the DialogHandlers to the corresponding AnnouncementSession class.

The video clip streaming functionality is implemented as a Back to Back User Agent (B2BUA) supporting third-party call control. With third-party call control, the application creates two correlated dialogs for managing the streaming session, one between the application server and the media server, and another between the application server and the end user's SIP device. The DialOutClientDialogHandler class is used to manage the session with the SIP clients while the ServerDialogHandler class manages the sessions with the media server.

It is important to mention that although third-party call control applications are ideally able to leave the SDP negotiation to the endpoints, in our case we had to play a role in the SDP negotiation. This is because we identified differences between the SDP implementations of Windows Messenger and the media server. These differences required the application to modify some of the SDP elements as they were exchanged between Windows Messenger and the media server. Interoperability is always an issue with SIP, and Weblogic SIP Server provides an ideal venue for massaging SIP for interoperability purposes.

Figure 1 shows a simple class diagram for the SipStreamingApp section of the application:

Figure 1. Object diagram of the SipStreamingApp application (click for a large version)

Note that SIP call flow logic is abstracted from the business logic of managing the streaming sessions. SIP dialogues are managed by the DialogHandler implementation classes. Likewise, SIP dialogues that are initiated by an incoming request to the com.bea.appserver.conferencing.ConferenceServlet class also go through the state mechanism implemented in the DialogHandler. By maintaining its own internal state, the DialogHandlers are able to easily implement SIP call flows.

The code section shown below summarizes the logic needed to start streaming a new video clip using the system architecture shown in Figure 1.

AnnouncementManager mgr = AnnouncementManager.getInstance();
AnnouncementSession annc = new AnnouncementSession(to, file);
mgr.addAnnouncement(annc);
annc.startStreaming();

Driving the media server

The rich features of the Convedia Media Server, such as playing a video clip and managing conferences, are driven through MSML, an XML-based language transmitted in the body of SIP messages. The streaming application uses these protocols to play video clips to end users over RTP. It has to send requests to the media server, interpret responses, and handle events related to a specific streaming session.

The fact that MSML is defined by XML schema files allows us to use XMLBeans to facilitate the generation and parsing of the MSML content. It allows us to perform complex media operations without having to worry about the details of parsing the XML and adhering to the schema. It also provides a first layer of abstraction for media server control and allows the developer to really focus on the business logic of the application to be created.

As the project distributed with this article was built for WebLogic Workshop 8.1, all you have to do is copy the protocol definition XSD files to the schema folder of the project, and the necessary files will be automatically generated for you, without you ever having to invoke the XMLBeans compiler. Partial schema files for MSML are provided as part of the project and are located on the schemas folder. The code segment below illustrates how the generated XMLBeans classes could be used by the application to generate the protocol content:

// First build the MSML command
MsmlDocument doc = MsmlDocument.Factory.newInstance();
Msml msml = doc.addNewMsml();
msml.setVersion("1.1");
Dialogstart start = msml.addNewDialogstart();

PlayDocument playDoc = PlayDocument.Factory.newInstance();         
Play play = playDoc.addNewPlay();
play.setCleardb(BooleanType.TRUE);
play.setBarge(BooleanType.TRUE);
play.setIterations("1");
            
Audio audio = play.addNewAudio();
audio.setUri(announc[0]);
Playexit exit = play.addNewPlayexit();

Send send = exit.addNewSend();
send.setNamelist("play.amt play.end");
send.setEvent("app.prompt");
send.setTarget("source");

start.set(playDoc);
start.setType(DialogLanguageDatatype.APPLICATION_MSML_XML);
start.setTarget(connectionId);

String payload = "<?xml version=\"1.0\"?>\r\n";
payload += doc.toString();

The next step on the media handling abstraction would be to define a media control API for generic media server control.

Pages: 1, 2

Next Page »