1. MRCPv2 协议交互过程
MRCP(Media Resource Control Protocol, 媒体资源控制协议)
目前有 2 个版本,当前最常用的版本是 v2。下图以 TTS(语音合成) 请求处理为例展示 MRCPv2协议
交互的时序,可以看到其核心处理分为 3 个部分:
SIP 消息交互
SIP 用于建立和管理整个会话,会话交互过程中 MRCP 客户端和服务端会通过 SDP 协商自身用于 MRCP 协议交互和 RTP 语音流传输的端口地址。一旦会话建立完成,MRCP 客户端和服务端后续的资源交互都基于协商地址点对点直接完成MRCP 消息交互
这个部分用于控制具体的资源交互行为,主要是基于语音的操作(如语音识别),同时传递操作的信息和结果(如语音识别结果)RTP 数据交互
点对点传输 MRCP 客户端和服务端交互的资源,如语音识别对应的音频流等。RTP 传输时间点可能穿插在 MRCP 消息交互中,二者并不存在严格的先后顺序
2. MRCPv2 负载分发方案
从上一节内容中我们知道 MRCP 服务器虽然要处理 3 种协议,但是只要 SIP 协商成功,后续 MRCP 和 RTP 交互都可以基于协商地址直接进行,因此只要做到 SIP 信令的负载分发就可以实现 MRCP 会话级别的负载。对于 SIP 协议的负载,其网络拓扑如下图所示,具体有以下两个方案可以考虑:
- 使用 SIP 代理服务器
最完备的方案,通常基于 SIP 协议栈的OpenSIPS、Kamailio
是比较好的选择,不过二者有一定的学习成本,使用 OpenSIPS 的话可以选择 load_balancer 或者 dispatcher 模块,大致方案可以参考 OpenSIPS 3.1 负载均衡 MRCP 服务器的实现- 使用四层负载均衡器
四层负载均衡器反向代理 MRCP 服务器实例比较易用,主要用于实现 MRCP 服务端的高可用,并不能保证负载均衡。因为 MRCP 客户端和四层负载均衡器 SIP 交互的 IP 四元组(Source IP、Source port、Destination IP、Destination port)是固定的,则在四层负载均衡器上同一个 MRCP 客户端的所有 SIP 请求都会转发到同一台 MRCP 服务器,比较大的可能造成负载倾斜