媒体服务器介绍（NETANN）

5.1                媒体控制

媒体控制是指软交换或者应用服务器与媒体服务器之间的信令交互，以达到完成业务流程的目的。目前这个信令交互并没有一个统一的标准，实际使用的有Convedia公司的SIP+MSML方式、IETF定义的多个RFC（NETANN、MSCML和SIP构建会议的框架）、W3C的公开标准HTTP+VoiceXML和IETF下的MediaCtrl工作组定义的一系列媒体控制草案。

 

5.1.1        NETANN、MSCML和SIP构建会议的描述框架

这三个RFC分别阐述了使用SIP承载基本网络媒体服务、扩展网络媒体服务和构建会议的框架。

 

5.1.1.1              NETANN

NETANN是RFC4240的简称，主要讲述使用SIP调用基本网络媒体服务的机制。在基于SIP的网络里，存在基本网络媒体业务的需求，这些业务包括放音、用户互动和简单混音会议。利用这些基本媒体模块，可以搭建更多有趣的业务。能提供这些基本媒体模块的服务器就称之为媒体服务器。应用开发要能实现与媒体服务器的互动，就需要一个通用的方法去定位和调用媒体模块。NETANN就是一个描述应用服务器和提供基本模块功能的媒体服务器之间互动机制的协议文档。

 

5.1.1.1.1        简述

NETANN是针对提供基本媒体业务的媒体服务器的，所谓基本业务，就是指功能单一，可作为模块化封装的业务。RFC4240里面定义了三种基本业务：放音业务、提示和接收应答业务和媒体混合业务。

放音业务就是给用户播放媒体流。媒体流的来源可以很多样，静态的媒体文件、实时采集的媒体流等。

媒体混合业务就是把不同的RTP流混合起来。这能满足基本会议功能的要求，对于更多会议控制的功能，超出了NETANN的定义范围。

提示和接收应答业务是指向用户播放提示语音，然后等待用户输入应答。它可以是一个单步的IVR，也可以是复杂的IVR业务使用MSCML或者VoiceXML描述。

NETANN最大的优点就在于它利用了SIP，但是没有对SIP做任何修改或进行某些限制，对不支持NETANN的SIP设备不会造成困扰。

 

5.1.1.1.2        机制

NETANN使用SIP URI里面的用户部分来描述基本业务，对每种基本业务都分别定义固定的字符串来表示，放音业务是“annc”，提示和接收应答业务是“dialog”，会议业务是“conf”。

NETANN的认证机制由SIP提供。媒体服务器可以使用回复401来要求进行鉴权。同时媒体服务器应该支持SIPS。

业务描述由两部分组成：业务名字和业务实例ID（可选），中间用等号分隔。对于有参数集的业务描述，参数集应该遵循SIP URI参数的规范，即关键字=参数值得格式，参数间用逗号分隔。一个媒体服务器可能同时为多个独立的会议业务提供媒体服务，这就需要对每个会议实例进行区分。方法是为每个业务实例分配唯一的ID，在业务名字上增加实例ID。

业务客户发起SIP INVITE到媒体服务器，指定所需的媒体业务和相关参数。媒体服务器收到请求后，判断是否能处理，如果不能则回复488表示请求不接受。如果请求的业务描述里面带有实例ID，媒体服务器需要检查该实例是否存在，如果不存在则回复404表示实例不存在。

 

5.1.1.1.3        放音业务

放音业务有两种类型，区别在于是否需要建立完整的SIP会话。在完成呼叫后放音很容易理解，业务客户发起SIP INVITE请求到媒体服务器，媒体服务器通过回复200进行SDP能力协商，在接收到ACK确认后，媒体服务器播放指定的媒体，播放完毕后再BYE掉业务客户。而不完成呼叫就放音，主要的考虑是回复200会导致计费，很多放音业务都是作为语音提示的，并不希望作为正常通话进行计费，所以就使用回复183进行SDP能力协商。在这种情况下，SIP呼叫并没有完成，但是语音通道已经打开，就可以进行放音。

如果媒体服务器收到放音业务请求，但是没有找到相应的媒体文件，它应该回复404和设置原因为“Announcement content not found”。如果收到的请求里面缺少“play=”的参数，应该回复400和设置原因为“Mandatory play parameter missing”。

放音业务的参数包括：

l      play：放音的源媒体文件。

l      repeat：放音重复的次数。

l      delay：重复放音之间的间隔时间。

l      duration：放音的总时长。

除了play参数外，其余的参数都是可选的。放音业务的SIP请求URI的格式如下：sip:[e-mail];play=http://audio.example.net/allcircuitsbusy.g711。

下面以终端用户、SIP代理和媒体服务器组成的简单场景描述协议交互的过程。

 

5.1.1.1.4        提示和接收应答业务

提示和接收应答业务处理的参数只有一个：

l      voicexml：描述需要执行的脚本文件URI地址。

提示和接收应答业务的SIP请求URI格式如：sip:[e-mail]; voicexml=。SIP URI里后续的参数项都会作为VoiceXML解释器的会话输入参数。

因为VoiceXML脚本里面可能会包含一些敏感信息，如DTMF格式的用户密码，所以媒体服务器需要支持https，以这种安全的方式获取脚本。

 

5.1.1.1.5        简单会议业务

要创建一个会议业务，可通过发送表示会议会话的URI的INVITE到媒体服务器。当URI描述的会议会话不存在，而且媒体资源可用的话，媒体服务器就会创建一个简单会议业务。当URI描述的会议会话已经存在，媒体服务器会把当前会话加入到会议中。会议的SIP请求URI格式如：sip:conf=[e-mail]。会议控制应用程序需要负责保证uniqueIdentifier全局唯一。

通过发送带会议描述符URI的BYE到媒体服务器，就可以离开会议会话。当所有会话都离开会议，该会议业务就因该结束掉。

对于一些商业会议，会存在计费等要求，这就需要媒体服务器支持对调用者进行鉴权，同时需要支持sips机制。

上图描述一个简单的三方会议建立过程。根据SIP构建会议框架里面的术语，应用服务器就是会议工厂，负责创建、管理和删除会议。而媒体服务器就是会议中枢，负责会议中媒体资源的集中管理。