by Marcelo Oliveira, Jeff Bean and Garland Sharratt
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.
In order to run the application described in this article, you must have access to:
Documentation for installing and configuring WebLogic Workshop and the WebLogic SIP Server domains is available in the Download area.
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:
This article presents a sample video streaming application that was written by BEA for the purposes of demonstrating how to do the following:
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.
The application consists of three major components:
WebAppfolder of the project. This Web service serves as an example for exposing streaming media as a Web service.
SipStreamingAppfolder of the project.
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 (
WebApp folder contains the Web service that is used to start new streaming sessions.
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.AnnouncementSession serve as the interface point between the SIP application business logic and the Web service front end.
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:
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
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:
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();
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); 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