MRCP(V2) 服务器的负载分发方案分析

1. MRCP(V2) 协议交互过程

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

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

2. MRCP(V2) 负载分发方案

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

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