利用Weblogic SIP Server将Radisys Convedia Media Server特性作为Web服务公开

　　摘要

　　随着电信网络与IT网络的汇聚，通过IT面向服务架构（Service Oriented Architecture，SOA）控制电信网络元素的需求逐渐显现了出来。电信网络越来越倾向于以IP为基础，一些媒体服务器，例如RadiSys的Convedia Media Server家族，已成为了任何基于IP的通信解决方案的完整组成部分。 BEA Weblogic SIP Server可以把富媒体通信特性（例如流式视频）公开为Web services，这就允许将Content Delivery或者IVR等应用程序创建为基于SOA的IT服务和SIP特性的复合体，而不是单体应用程序。

　　本文介绍了一个使用BEA WebLogic Workshop构建的基于SIP servlet的示例应用程序，该应用程序利用WebLogic SIP Server来驱动RadiSys的Convedia Media Server家族中的产品，其中包括CMS-1000、CMS-3000、CMS-6000和CMS-9000。本文演示的应用程序利用Sessions Markup Language（MSML）播放视频通告。这个特性在该媒体服务器家族中是独一无二的。

　　软硬件需求

　　要运行本文所介绍的应用程序，必须具备以下条件：

　　提供了示例视频剪辑的RadiSys Convedia Media Server，这些视频剪辑将流式传输给SIP客户端。Convedia Media Server是基于硬件的解决方案，需要配置，并确保其在测试网络的范围之内可用。就本文的目的，RadiSys能够根据请求使远程服务器可用。 如有兴趣，请联系 ');// --> sales@convedia.com。

　　Windows Messenger 4.7 作为SIP客户端接收流式视频。Windows Messenger 4.7可以从 这里下载。之所以选择Windows Messenger 4.7，原因是Windows Messenger的这个版本恰好可以通过一种相当透明的方式完全地支持SIP。

　　WebLogic Workshop 8.1

　　WebLogic SIP Server 2.2

　　有关安装和配置WebLogic Workshop以及WebLogic SIP Server域的文档，请点击此处 下载。

　　简介

　　媒体服务器控制对于任何涉及复杂内容的多方传输、基于SIP的多媒体应用程序都是至关重要的。虽然可以用WebLogic SIP Server来对使用SIP的应用程序进行呼叫控制和会话管理，但还是需要一个媒体服务器来提供该应用程序所需的媒体处理。下面是媒体服务器能够执行的任务的一些例子：

　　语音和视频会议，包括混合多个音频流以及在多个活动的视频流之间切换。

　　播放和录制音频及视频。

　　DTMP（双音多频）采集和识别。

　　IVR，包括VoiceXML解析和浏览。

　　本文展示了BEA编写的一个视频流示例应用程序，用于演示如何完成以下任务：

　　在Workshop平台中使用Web Services公开基于SIP的应用程序的功能。

　　使用WebLogic Workshop构建WebLogic SIP Server应用程序。

　　使用MSML为SIP客户端播放视频剪辑，实现与Convedia Media Server 的互操作性。

　　该应用程序提供了一个Web服务门面（facade），使得其他应用程序可以轻松使用此应用程序的功能。目的在于使这个Web服务门面可与规模更大的SOA（Service Oriented Architecture）相连接，从而把媒体服务器的特性公开给更大的企业。

　　例如，在本文介绍的应用程序中，IMS订阅者可以利用同样连接到SOA的移动内容门户购买视频剪辑。购买之后，选定内容就会按要求通过SIP和RTP流式传输到订阅者的IMS设备中。流式传输是使终端用户能够立刻开始欣赏视频的关键特性，这样用户就不必等待整个文件全部下载完成。

　　应用程序架构

　　该应用程序由三个主要组件组成：

　　Web应用程序提供的Web服务门面位于项目的WebApp文件夹。该Web服务示范了如何把流媒体作为Web服务公开。

　　SIP应用程序，提供第三方呼叫控制流逻辑，管理终端用户的SIP设备与媒体服务器之间的视频流会话。它位于项目的SipStreamingApp文件夹。

　　SIP 代理/注册器应用程序，充当SIP注册器（registrar）以及SIP客户端与应用服务器的出站代理。它根据注册器存储的信息代理传入请求。该应用程序以jar文件的形式提供。

　　Web 应用程序

　　安装说明详述了如何创建SIP域，从而为在Workshop中开发SIP servlet提供支持。这允许我们可以通过一组鼠标点击操作把应用程序的功能公开为Web Service。此外，IDE中对XML bean的直接支持使得处理MSML语言的XSD轻而易举。这里，我们提供了应用程序所需要的那些模式的子集。

　　为进行分离逻辑，Workshop项目被划分为两个相关的文件夹：Web应用程序文件夹（WebApp）和流应用程序文件夹（SipStreamingApp）。 WebApp文件夹包含用来启动新流会话的Web服务。

　　流应用程序

　　SipStreamingApp文件夹包含com.bea.appserver.streaming包，这是视频流功能本身背后的业务逻辑（包括通过SIP servlet实现、用于接受和发送SIP消息的呼叫流逻辑，以及用来管理呼叫流的状态控制类）。 com.bea.appserver.streaming.AnnouncementManager类和com.bea.appserver.streaming.AnnouncementSession类充当SIP应用程序业务逻辑和Web服务前端之间的接口点。

　　AnnouncementManager类是一个单元素，它唯一的用途是聚集所有正在运行的流会话。 AnnouncementSession类封装整个流行为，并且维护这样一个信息，即哪一个剪辑应该播放给哪一个用户。 它完全是从协议细节中抽象出来的，并被推入DialogHandler实现类： DialoutClientDialogHandler和ServerDialogHandler。 Listener设计模式广泛地应用在应用架构上。Listener模式很适合应用程序的事件驱动本质。它用于在DialogHandler类与相应的AnnouncementSession类之间传递信息。

　　视频剪辑的流式传输功能是作为背对背的用户代理（Back to Back User Agent，B2BUA）实现的，它支持第三方呼叫控制。 通过第三方呼叫控制，应用程序创建两个相关的对话来管理流会话，一个是在应用服务器和媒体服务器之间，另一个是在应用服务器和终端用户的SIP设备之间。DialOutClientDialogHandler类用来管理与SIP客户端间的会话，而ServerDialogHandler类管理与媒体服务器间的会话。

　　还有一点很重要，那就是虽然第三方呼叫控制应用程序在理想情况下能够把SDP协商留在端点（endpoint），但对本例来说，我们仍需在SDP协商中发挥作用。这是因为我们认识到Windows Messenger的SDP实现与媒体服务器之间的差异。当SDP数据元素在Windows Messenger和媒体服务器之间交换时，这些差异将要求应用程序修改这些SDP数据元素。互操作性始终是SIP必需面对的一个问题。Weblogic SIP Server提供了传递SIP消息的理想平台用以实现互操作性。

　　图1展示了应用程序的SipStreamingApp部分的简单类图：

　　图1.SipStreamingApp应用程序的对象图（单击查看大图）

　　请注意，SIP呼叫流逻辑是从管理流会话的业务逻辑抽象而来的。 SIP对话由DialogHandler实现类管理。 类似地，由对com.bea.appserver.conferencing.ConferenceServlet类的传入请求发起的SIP对话也运用了在DialogHandler中实现的状态机制。通过维护自身的内部状态，DialogHandler也就能够轻松实现SIP呼叫流。

　　以下代码段总结了利用图1中的系统架构启动一个新视频剪辑的流式传输所需的逻辑。

　　AnnouncementManager mgr = AnnouncementManager.getInstance();

　　AnnouncementSession annc = new AnnouncementSession(to, file);

　　mgr.addAnnouncement(annc);

　　annc.startStreaming();

　　驱动媒体服务器

　　Convedia Media Server的丰富特性（如播放视频剪辑和管理会议）是通过SIP消息体中附带的一种基于XML的语言——MSML驱动的。流应用程序利用这些协议，通过RTP为用户播放视频剪辑。它必须向媒体服务器发送请求、解释响应，并处理与特定流会话相关的事件。

　　MSML是由XML模式文件定义的，这一事实允许我们使用 XMLBean更方便地生成和解析MSML内容。还允许我们执行复杂的媒体操作，而不用担心解析XML和符合模式的细节。它还为媒体服务器控制提供了第一层抽象，并允许开发人员真正地专注于要创建的应用程序的业务逻辑。

　　随本文一同发布的项目是为WebLogic Workshop 8.1构建的，因此只需要把协议定义XSD文件复制到项目的模式文件夹中即可，必需的文件将自动生成，您不必调用XMLBean编译器。项目提供了MSML需要的部分模式文件，这些文件是项目的一部分，位于schemas文件夹中。 如下代码段演示了应用程序如何利用生成的XMLBean类来生成协议内容。

　　// 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 = "\r\n";

　　payload += doc.toString();

　　媒体处理抽象的下一步是定义一个媒体控制API，以实现一般媒体服务器控制。

　　SIP呼叫流

　　这一节介绍了 附录 所列演示用例的SIP呼叫流。这些呼叫流展示了在流式传输音乐视频时，用于与媒体服务器和SIP客户端交互的SIP和MSML消息。这些流中并未包含代理。

　　为最终用户X播放流式视频文件

　　这个示例假定了这样一个前提：已经调用了Web服务streamContent，从而为最终用户（URI为sip:marcelo@imsdomain.com）播放流式视频文件JessicaSimpson_WithYou.mov。下图描述应用程序与Convedia Media Server及SIP客户端之间的交互所生成的呼叫流。

　　第三方呼叫控制消息流的第一步是从媒体服务器中收集SDP提议。这可以通过向媒体服务器发送一个INVITE来实现，而不用指定SDP有效载荷。请注意，下图中从媒体服务器接收到的SDP提议并不是像正常的第三方呼叫控制场景中那样，由初始的INVITE请求直接传给SIP客户端。由于SIP客户端与媒体服务器在SDP协商上的不兼容，流应用服务器必须修改SDP提议。

　　图2.从媒体服务器收集SDP

　　图3展示了终端用户SIP用户代理对INVITE请求的响应，该请求包含一个对音频和视频的SDP提议。请注意，由于端对端的不兼容性，流应用服务器还需对从SIP客户端接收到的响应OK的SDP应答进行再次修改。 流应用服务器需为QCIF重新引入fmtp属性，作为视频媒体的描述一部分，这些描述将在SIP客户端做出应答时被丢弃。

　　图3.终端用户SIP用户代理响应

　　在这之后，媒体服务器发起一个额外的re-INVITE事务（图中未显示），将其作为由流应用服务器执行的类似过程。。

　　当SDP协商完成时，流应用服务器指示媒体服务器开始将视频剪辑流式传输到SIP客户端。下图显示了所用的MSML命令：

　　图4.WebLogic SIP Server和RadiSys Convedia Media Server之间的MSML

　　从这时开始，视频剪辑将通过RTP从媒体服务器流向SIP客户端，直到视频播放完成或终端用户通过挂断视频会话终止SIP对话。 图5显示了视频播放完成时的系统默认行为。请注意从媒体服务器传送到流应用服务器的MSML事件，以及终止视频会话中的两个对话时应用服务器的反应。

　　图5.媒体服务器和流应用服务器之间的MSML

　　SIP Servlet最佳实践

　　应特别注意此应用程序所采纳的最佳实践。考虑到时间和简单性，这里没有实现所有最佳实践。此外，SIP servlet规范非常新，一些最佳实践仍在开发中。然而，应关注以下关键实践的细节：

　　根据Web应用程序开发的最佳实践，Web服务接口从业务逻辑中分离出来。流逻辑是由com.bea.appserver.streamiing包中的类实现的。这就使SIP应用程序和Web服务层能够引用相同的对象，建立SIP/HTTP聚合。

　　流状态和对话状态在SIP servlet之外的业务逻辑中管理。由于SIP servlet是新技术，且流本身是通过VoIP会话表示的，所以人们往往会忘记将表示与业务逻辑分离开来。然而，认识到SIP servlet是表示层的一部分非常关键。 这允许在SIP和Web层之间共享相关信息。这也允许使用新的Web接口或SIP呼叫流独立地扩展应用程序。

　　此应用程序考虑到了更大规模的SIP网络 请注意，部署描述符sip.xml文件明确拒绝发送SIP REGISTER请求，因此肯定了SIP servlet可与现有注册器一起部署。事实上，注册器和代理功能是分别提供的。这也就意味着，SIP servlet应是粒度化、模块化并在逻辑上独立的，以确保在服务创建和部署时获得最佳灵活性。

　　结束语

　　本文展示了一个示例应用程序，演示了如何使用WebLogic SIP Server 2.2和WebLogic Workshop 8.1开发SIP应用程序。文中介绍了Convedia Media Server与WebLogic SIP Server的互操作性，以及构建基于SIP的应用程序的最佳实践。还演示了如何把应用程序功能作为Web服务公开，这样就可以在SOA架构中把它们组合成更复杂的工作流。我们希望您能喜欢这个示例，并期待能得到您的反馈。