一、概述

VoiceXML(语音可扩展标志语言)[1]是为了创建音频会话而设计，用于描绘合成语音、数字音频、话音与DTMF按键式输入识别、话音输入录制、电话和混合式主动转换，其主要目标是将基于Web开发和内容交付的优势延伸到IVR(交互式语音应答)应用。

SIP(会话启动协议)[2]是一种应用层控制(信令)协议，用于建立、修改和终止与一个或多个参与者的会话，这些会话包括因特网电话呼叫、多媒体发布和多媒体会议。

CCXML(呼叫控制可扩展标志语言)[3]是为了给诸如VoiceXML这样的会话系统提供电话呼叫控制而设计的，尽管它可使用在任何能够处理媒体的会话系统，但主要还是为了补充和与VoiceXML解释器进行集成。

Voxeo公司提供的Prophecy平台(http://cn.voxeo.com/prophecy/)是一个灵活可靠的完全开放式IVR语音应用的开发、部署和运行平台。其核心的呼叫控制全部基于SIP，可以运行和部署任何基于VoiceXML、CCXML标准的电话应用，是构建包括SIP多方会议系统在内的新一代VoIP应用的利器。

二、SIP会议系统

考虑一个SIP会议系统，用户通过拨入会议URI sip:staffmeet@conference.com来加入会议。只有按键式电话的传统电话用户无法拨打这类一般性的URI。我们可以每次会议为直接向内拨号(DID)分配电话号码，但是首选的是用户总是拨打VoiceXML浏览器的号码，该浏览器将依次提示PIN(个人身份号码)认证和会议号。一旦用户通过认证，浏览器把呼叫转移给选定的会议。用户也可以使用单一PIN标识参与者和会议。

图1显示了一个用户(比如说Alice)在加入会议前是如何同语音浏览器进行交互的： 　　
Alice拨打浏览器的电话号码(212-9397137)或SIP URI (sip:7137@server.com)。

浏览器接受呼叫，提示主叫方输入PIN标识。

Alice键入她的PIN号码1-2-3-4，后面跟着一个终结键“#”。DTMF数字在RTP中发送。

浏览器查询数据库，把主叫方标识为Alice。

基于使用权限，浏览器向她提示一个会议列表供她选择。

Alice选择标识符为23的会议。

浏览器再次核对Alice是否允许加入标识为23的会议，在本例中是sip:staffmeet@conference.com。

一旦认证完成，浏览器将使用SIP REFER方法把呼叫转移给实际的会议服务器，该方法携带了会议SIP URI。

Alice的电话接受转移，并向会议服务器发起一个新的呼叫。

Alice的电话与会议服务器直接交换音频，不必再经过浏览器。

 
图1方法一：在盲目转移模式中加入会议

注意：用户认证、会议查询和转移实际上由会议服务器CGI脚本调用，而浏览器只是解释脚本生成的VoiceXML页面来完成实际的转移或提示主叫方。例如，业务脚本可能在第(9)步为呼叫转移生成以下转移标签：

<block><prompt>Your call is being transferred,
　　please wait.</prompt></block>
　　<transfer dest="sip:staffmeet@conference.com" bridge="false" />
[nextpage]

转移有两种模式：盲目转移和桥接转移。前者是不查阅服务器的呼叫转移，而后者是查阅后转移，从而浏览器可以选择进入媒体路径。

 
图2 方法二：使用桥接模式加入会议

图2显示了桥接转移情形，其中浏览器作为一个“背靠背用户代理”在用户电话和会议服务器之间桥接音频路径。步骤1～7与盲目转移情形相同，所不同的是，浏览器并非发送REFER，而是向会议服务器发送一个新的呼叫请求，在SIP INVITE消息的Request-URI中标识会议sip:staffmeet@conference.com。浏览器为双向RTP/RTCP媒体流量充当了应用级包转发器。

桥接转移的优点在于，浏览器逗留在媒体路径中，可以接受随后来自用户电话(使用DTMF)的控制命令。对于会议来说，这一点可能是有用的，例如将DTMF 6-6-#解释为关闭你的音频或者6-8-#表示加入另一个虚拟聊天或会议室。其次，浏览器也需要给会议服务器转发其它的信令消息，例如来自主叫方的re-INVITE。而且，维持会议期间的数据包转发状态在可以同时处理的主叫数目方面限制了浏览器的可扩展性。浏览器可以向主叫方和会议服务器发布带更新的RTP/RTCP传输地址的re-INVITE，以便媒体路径是直接的。但是，这依然需要维持呼叫期间的信令状态。另一方面，盲目转移在会议期间无须浏览器的任何呼叫状态，不过它期望主叫IP电话支持REFER方法。

三、安全性

每一个因特网应用都应该处理安全性。我们的体系结构有三个方面需要考虑安全性：电话网关、SIP信令与RTP媒体传输和对后台服务器的HTTP/RTSP访问。

在桥接转移情形，VoiceXML浏览器使用PIN认证主叫方，并在SIP认证中提供自己的机密信息给会议服务器。而在盲目转移情形，如果主叫方使用通过网关连接的传统电话，那么SIP认证将包含网关的机密信息。为了防止恶意用户连接到受限会议，我们在REFER消息中把机密信息从浏览器传递给主叫方网关，随即用于主叫方网关呼叫会议服务器。机密信息可以是浏览器或主叫方的。例如，Refer-To头可能包含sip:staffmeet-@conference.com，这里是base-64编码的，hash是browser-host:timestamp:shared-secret的MD5哈希值。这种方案只在会议服务器能解释该URI时起作用。如果时间戳老化了，服务器应该拒绝呼叫，以防重播攻击。

浏览器应该使用HTTP POST方法，而不是GET方法，以避免在Web服务器日志中保存CGI输入。

四、功能扩充

除了安全性，我们还可以对会议系统进行功能扩充，比如控制会议音量和增强系统鲁棒性。

不同声音设备的异构客户机之间的多方音频会议常常导致恼人的音频失真，一些参与者听起来太大声，而另一些可能根本听不见。理想状态下，会议服务器应该在混音前平衡来自所有参与者的输入音量，但是这将在服务器上为每一个音频数据包带来额外处理要求。另一个办法是告诉参与者调整他的麦克风和扬声器的音量。参与者在加入会议之前连接到一个“音量反馈”的系统，并且对它说话。该系统宣布用户的麦克风音量是可接受、太高或太低。它也播放一个预先录制好的音频文件，允许用户调整其扬声器音量。这个处理过程由一个服务器侧脚本建立，VoiceXML浏览器可以访问它。

在过去几年，开发人员已经日益使用CCXML给他们的电话系统增加强健的呼叫控制特性。图3展示了如何在VoiceXML与SIP环境中运用CCXML平台进行高级会议控制[4]。在这里CCXML作为SIP的“背靠背用户代理”，面向呼叫者和网络资源(比如VoiceXML浏览器和会议混合器)执行基于SIP的呼叫控制职能，可以基于开放式的行业标准方式创建健壮可靠的多方会议系统。Voxeo Prophecy 8.0是一个强大的完全基于标准的IVR和SIP VoIP应用平台，它捆绑了业界第一个(也是目前唯一的) 100% 通过VoiceXML官方规定的全部兼容性测试(全部强制性和可选功能)的VoiceXML浏览器和世界上目前最完整CCXML实现，同时它还与任意网络开发语言(包括ASP, CGI, C#, Java,PERL, PHP, Python 和 Ruby)或服务器兼容，给VoIP语音应用开发与部署人员提供了有力的工具和平台。

 
图3 CCXML SIP体系结构

五、小结

本文讲述了SIP会议系统的两种转移模式，以及体系安全性的一些考虑，最后简单介绍了可以采用VoiceXML服务器侧编程逻辑和CCXML脚本来扩充会议服务器的功能，并推荐了一款完全基于标准的开发工具和平台――Voxeo Prophecy 8.0。

参考资料：

[1] VoiceXML 2.1: http://www.w3.org/TR/voicexml21/
　　[2] SIP: Session Initiation Protocol: http://www.ietf.org/rfc/rfc3261.txt
　　[3] CCXML 1.0: http://www.w3.org/TR/ccxml/
　　[4] Using Call Control XML (CCXML) as a SIP Softswitch: http://www.voicexml
.org/Review/Apr2005/features/softswitch.html