5.1.1MediaCtrl媒体控制草案
MediaCtrl是IETF下专门研究和制定媒体服务器控制标准的小组，以SIP和XML为所制定标准的基础。这个工作组的工作包括：定义媒体服务器控制的技术需求说明、框架、控制协议簇和定位/连接协议。
5.1.1.1技术需求描述
这个技术需求描述媒体服务器控制协议需要实现的目标，给控制协议划定适用范围，主要内容包括：
l媒体控制要求：
1、协议应该支持一个或者多个应用服务器同时控制一个或者多个媒体服务器；
2、协议应该使用可靠的底层传输协议；
3、协议应该支持包括语音、音频信号、文本和视频在内的媒体类型；
4、协议应该使用SIP/SDP来建立到媒体服务器的连接；
5、应该支持跨媒体服务器的会议；
6、必须支持一个或者一组参与者从会议分离出来，而不需要跟媒体服务器建立新的连接，例如在会议中建立子会议；
7、协议应该支持应用服务器查询媒体服务器的会话状态信息，信息报告应包括资源使用状况和网络质量等；
8、媒体服务器应该支持上报应用服务器订阅的事件信息，如STUN请求，流量控制等；
l媒体混合/合成要求：
9、应用服务器应该支持会议混音；
10、应用服务器应该支持用户自定义的视频输出窗口；
11、应用服务器应该支持视频流到指定输出窗口的映射或者告知媒体服务器视频流和输出窗口的映射关系
12、媒体服务器应该能把当前会议中的讲话者和视频源上报应用服务器，讲话者与视频源可能是不同的，如介绍一个播放的视频资料时；
13、媒体服务器应该支持告知应用服务器其所能支持的视频合成格式；
14、协议应该支持应用服务器控制媒体服务器对会议进行录音/像；
lIVR要求：
15、应用服务器可以通过协议控制媒体服务器执行一个或者多个IVR脚本，并得到运行结果；脚本可以在服务器上也可以承载在控制信令上；
16、应用服务器可以通过发送放音请求和接收应答(如DTMF)来控制IVR会话过程；应用服务器根据收到的应答来决定IVR的流程；
17、应用服务器可以控制媒体服务器录制一小段媒体流然后回放；这不同于录音/像需求；
l操控要求：
18、应用服务器可以通过协议在媒体会话过程中改变媒体服务器的状态；
19、媒体服务器可以在媒体会话过程中上报自己的状态；
5.1.1.2架构描述
架构描述为满足上述技术需求，定义了媒体服务器控制的所有逻辑实体、实体之间的组成结构和SIP的使用，并对IVR业务和会议业务使用媒体服务器控制来实现进行描述。
5.1.1.2.1架构总述
基本的信令架构如下图所示：
应用服务器负责处理所有与用户终端之间的信令交互，并通过SIP第三方呼叫控制(3PCC)的呼叫方式建立、维护和删除用户终端到媒体服务器之间的媒体连接。媒体流直接在用户终端和媒体服务器之间传输。
这个架构支持多对多的应用服务器和媒体服务器连接。实际应用中，一个应用服务器可以同时控制多个媒体服务器，一个媒体服务器也可以同时服务于多个应用服务器。
根据一个业务流程过程中是否需要应用和媒体服务器之间进行交互，媒体业务可以分为两类：一类是不需要过程中进行交互的，称之为基本业务，如简单的放音服务和会议服务(只做混音功能)，这类业务只需要使用NETANN就可以完成应用对媒体服务器的媒体处理请求；另一类是需要过程中进行交互的，这类业务应用更广泛，如IVR、复杂的会议服务等，这就需要另外的机制来传递交互信息。
应用和媒体服务器之间交互的信息可分为三类：
l控制指令：应用服务器发给媒体服务器媒体控制信令，如播放某段媒体、检测媒体流中的DTMF信号等；
l应答：媒体服务器完成控制指令的结果反馈；
l上报事件：当应用服务器订阅的事件触发或者状态发生改变的时候，媒体服务器上报的消息，如上报DTMF信号、媒体连接网络状况变化等；
控制指令、应答和上报事件的传输需要应用和媒体服务器之间建立一个可靠的、顺序的、端到端的连接。传输层协议应该使用TCP。示意图如下：
5.1.1.2.2SIP使用
在上述架构里，SIP应用于媒体连接的建立和媒体服务器控制通道的建立。关于使用SIP建立、管理和删除媒体服务器控制通道会在5.2.4.3节里面详细描述。
相对别的协议，使用SIP主要有以下几点好处：
l可以使用SIP的定位策略和聚合能力。如根据DNS进行路由。
l可以沿用SIP的安全策略。如使用TLS或者已有的各种加密和鉴权机制。
lSIP拥有很强的动态能力协商机制。
l可以根据能力集选择合适的SIP实体。这使得媒体服务器可以告知应用服务器它所能支持的媒体能力。
l使用SIP可以与IETF的协议和应用保持延续性。
但在现有的媒体控制协议中，SIP的INFO消息被用来作为控制信令的载体，这并不合适，原因是：
lINFO是没有特定语义的不透明的请求，终端收到INFO请求时，根据SIP协议定义并不能明确知道应该如何处理；
lINFO是定义来传递可选的应用层信息的，如呼叫中在PSTN网关之间传递PSTN信令，而不应该用来传递会话层控制信息；
lINFO是根据SIP路由来传递的，这使得效率比较低，媒体控制信令应该直接在应用和媒体服务器之间传递；
l在RFC3261中，关于使用UDP传输有一个准则，就是如果消息包接近最大传输单元时，应改用TCP传输。这对于经常传递基于XML格式的媒体控制消息包来说，十分不便。
5.1.1.2.3IVR业务描述
IVR业务所需的媒体功能包括：媒体转换、基本放音、用户输入检测(通过DTMF或者语音识别)和录音等。当然，根据IVR业务的不同，所需要的媒体功能也会不同，简单的IVR业务可能只需要上述功能其中之一。
根据架构描述，应用服务器使用SIP和SDP建立和配置与媒体服务器的媒体会话。同时，使用SIP建立媒体服务器控制通道。应用服务器通过控制通道调用IVR请求、接收应答和上报事件。拓扑示意图如下：
对于使用VoiceXML描述的IVR业务，也可以通过媒体服务器控制通道进行调用。这就需要媒体服务器支持通过HTTP协议与VoiceXML文件所在服务器(可以是应用服务器本身)进行业务交互。
5.1.1.2.4会议业务描述
这里的会议业务描述遵循RFC4353和兼容集中式会议工作组(XCON)所制定的标准。
与IVR业务一样，应用服务器使用SIP和SDP建立和配置与媒体服务器的媒体会话。同时，使用SIP第三方呼叫控制的方式建立会议成员与媒体服务器的媒体连接和进行添加/删除会议成员的操作。有两个会议成员的会议拓扑示意图如下：
2m表示两个会议成员与媒体服务器的媒体连接，1c表示应用和媒体服务器之间的媒体会话。作为会议中枢，应用服务器负责创建和管理在媒体服务器上的会议，以确保会议的媒体流可以正确的到达每个会议成员。
应用服务器提供的会议功能应包括：建立、管理和删除会议、添加/删除会议成员、管理会议中的所有媒体流、控制每一个媒体流的输出和混音配置、允许用户自定义媒体属性等。下面简要概括这些会议功能：
l创建新的会议
当第一个会议成员发起SIP会议呼叫到应用服务器的时候，应用服务器会通过媒体控制通道给媒体服务器发出建立新会议的请求。这个请求包含了会议的详细设置和策略要求，如媒体格式、混音配置等。媒体服务器验证请求并为会议分配媒体资源。
当媒体服务器完成对请求的处理，会返回给应用服务器结果。每个会议都会分配一个唯一的会议号，用来作为应用和媒体服务器对后续会议操作的标志。
l媒体控制
XCON工作组的通用数据模型定义了一些基本媒体相关的控制，可供会议成员使用，其中包括：调整语音音量、调整视频输出格式、静音/取消静音和停止/恢复视频等。这些控制功能需要会议成员和会议中枢之间使用标准的会议控制协议。会议中枢在收到这种控制请求后，会把它转换成媒体控制协议通知媒体服务器对相应的媒体流进行处理。取消静音的例子示意图：
l场景控制
场景控制是XCON提出来的，是指在会议里对共享资源共同或者独享使用进行管理的一种机制。这对于会议来说不是必须的，但它增加了会议对媒体流输入的控制功能。场景对应着会议提供的一组资源，以供用户合法使用和控制。XCON还定义了BFCP(Binary Floor Control Protocol)来规范场景控制机制。
BFCP包括场景控制服务器和场景决策器。结合应用和媒体服务器的架构，场景决策器是应用逻辑，属于应用服务器的一部分。而场景控制服务器则既跟媒体服务器有关联也跟应用服务器有关，本文只讨论场景控制服务器属于媒体服务器的情形，这与3GPP定义的H.248.19是兼容的。
下面的时序图给出一个在应用和媒体服务器架构上的场景控制例子：
在例子中，用户终端开始的时候对场景资源只有旁听的权限，他想参与发言就必须向场景控制器发起请求，经过场景决策器的同意，媒体服务器把用户终端的媒体流加入场景资源的混音中，用户就可以在场景中发言了。
