Exposing a Radisys Convedia Media Server feature as a Web Service using WebLogic SIP Server
Pages: 1, 2
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.
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:firstname.lastname@example.org. 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 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.
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:
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.
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:
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.
sip.xmlfile 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.
The following items discussed in this article can be downloaded:
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.
The following example is implemented by the application:
Marcelo Oliveira is a Software Engineer currently working for Cisco Systems in the Emerging Markets Business Unit.
Jeff Bean is a Technical Manager working for the BEA Global Alliances Group. He has 9 years of IT experience as a software developer, professional services consultant, and systems engineer.
Garland Sharratt is a Senior Director of Product Marketing at RadiSys.