MRCPv2 服务器的负载分发方案分析

1. MRCPv2 协议交互过程

MRCP(Media Resource Control Protocol, 媒体资源控制协议) 目前有 2 个版本，当前最常用的版本是 v2。下图以 TTS(语音合成) 请求处理为例展示 MRCPv2协议 交互的时序，可以看到其核心处理分为 3 个部分：

1. SIP 消息交互
   SIP 用于建立和管理整个会话，会话交互过程中 MRCP 客户端和服务端会通过 SDP 协商自身用于 MRCP 协议交互和 RTP 语音流传输的端口地址。一旦会话建立完成，MRCP 客户端和服务端后续的资源交互都基于协商地址点对点直接完成
2. MRCP 消息交互
   这个部分用于控制具体的资源交互行为，主要是基于语音的操作（如语音识别），同时传递操作的信息和结果（如语音识别结果）
3. RTP 数据交互
   点对点传输 MRCP 客户端和服务端交互的资源，如语音识别对应的音频流等。RTP 传输时间点可能穿插在 MRCP 消息交互中，二者并不存在严格的先后顺序

2. MRCPv2 负载分发方案

从上一节内容中我们知道 MRCP 服务器虽然要处理 3 种协议，但是只要 SIP 协商成功，后续 MRCP 和 RTP 交互都可以基于协商地址直接进行，因此只要做到 SIP 信令的负载分发就可以实现 MRCP 会话级别的负载。对于 SIP 协议的负载，其网络拓扑如下图所示，具体有以下两个方案可以考虑：

1. 使用 SIP 代理服务器
   最完备的方案，通常基于 SIP 协议栈的 OpenSIPS、Kamailio 是比较好的选择，不过二者有一定的学习成本，使用 OpenSIPS 的话可以选择 load_balancer 或者 dispatcher 模块，大致方案可以参考 OpenSIPS 3.1 负载均衡 MRCP 服务器的实现
2. 使用四层负载均衡器
   四层负载均衡器反向代理 MRCP 服务器实例比较易用，主要用于实现 MRCP 服务端的高可用，并不能保证负载均衡。因为 MRCP 客户端和四层负载均衡器 SIP 交互的 IP 四元组（Source IP、Source port、Destination IP、Destination port）是固定的，则在四层负载均衡器上同一个 MRCP 客户端的所有 SIP 请求都会转发到同一台 MRCP 服务器，比较大的可能造成负载倾斜