Exposing a Radisys Convedia Media Server feature as a Web Service using WebLogic SIP Server
Pages: 1, 2

SIP Call Flows

Here are the SIP call flows for the demo use cases outlined in the Appendix. These call flows show the SIP and MSML messages used to interact with the media server and with the SIP client to stream a music video. The proxy is not included in these flows.

Stream video file to end user X:

This example assumes the precondition that the Web service streamContent has been invoked to stream the video file JessicaSimpson_WithYou.mov to the end user URI sip:marcelo@imsdomain.com. The following diagrams will depict the call flows that are then generated by the application interaction with the Convedia Media Server and the SIP client.

The first step on the third-party call control message flow is to collect the SDP offer from the media server. This is accomplished by sending an INVITE to the media server without specifying any SDP payload. Notice on the diagram below that the SDP offer received from the media server is not directly passed to the SIP client on the initial INVITE request, as would be normally expected on a third-party call control scenario. The streaming application server had to modify the SDP offer because of incompatibilities between the SIP client and the media server on the SDP negotiation.

Figure 2. Collecting SDP from the media server

Figure 3 shows the response of the end user SIP user agent to the INVITE request containing an SDP offer for audio and video. Note that the SDP answer received from the SIP client on the OK response had to again be modified by the streaming application server because of end-to-end incompatibilities. The streaming application server had to reintroduce the fmtp attribute for QCIF as part of the video media description which was dropped by the SIP client when providing the answer.

Figure 3. End user SIP user agent response

After this point, an additional re-INVITE transaction is initiated by the media server that we won't be showing as a similar procedure is performed by the streaming application server.

As soon as the SDP negotiation is completed, the streaming application server instructs the media server to start streaming the provisioned video clip to the SIP client. The MSML commands used are displayed on the diagram below:

Figure 4. MSML between WebLogic SIP Server and the RadiSys Convedia Media server

From this point on, the video clip will be streamed over RTP from the media server to the SIP client until the video finishes playing or until the end user terminates the SIP dialog by hanging up the video session. Figure 5 shows the default behavior of the system when the video finishes playing. Notice the MSML events sent from the media server to the streaming application server and the reaction of the application server to terminate the two dialogs used for that video session.

Figure 5. MSML between the media server and the streaming application server

SIP Servlet Best Practices

Special attention should be paid to the best practices that are followed by the application. In the interests of time and simplicity, not all best practices are implemented here. Moreover, the SIP servlet specification is fairly young and some best practices are still in development. However, detail was paid to the following key practices:

1. The Web service interface is separated from the business logic according to the best practices of Web service application development. The streaming logic is implemented by the classes from the package com.bea.appserver.streaming. This enables both the SIP application and the Web service tier to refer to the same objects, establishing SIP/HTTP convergence.
2. Streaming and dialog state are managed outside the SIP servlet, in the business logic. Since SIP servlet technology is new, and since the streaming itself is presented over a VoIP session, the temptation is to forget about separating presentation and business logic. However, recognizing that the SIP servlet is part of the presentation layer is key. This enables sharing of relevant information between the SIP and Web tiers. This also enables independently extending the application with new Web interfaces or SIP call flows.
3. The application respects the larger SIP network. Notice the deployment descriptor sip.xml file explicitly refuses to route SIP REGISTER requests, therefore acknowledging that the SIP servlet may be deployed alongside an existing registrar. In fact, we provide this registrar and proxy functionality separately. This hints that SIP servlets should be granular, modular, and logically separated to ensure optimal flexibility in service creation and deployment.

• Streaming Application .EAR file
• Streaming Application WebLogic Workshop Project
• Installation Instructions for the Streaming Application
• Proxy/Registrar Application

Summary

This article presents a sample application that illustrates a SIP application developed with WebLogic SIP Server 2.2 and WebLogic Workshop 8.1. It demonstrates interoperability between the Convedia Media Server and WebLogic SIP Server, and best practices around building SIP-based applications. It also shows how to expose the application functionality as Web services, so that they can be composed into more complex workflows in an SOA architecture. We hope you enjoy the sample, and we look forward to receiving your feedback.

References

• More on XMLBeans, which is bundled with WebLogic Server