MRCP（V2）的交互过程可以分为三部分
1.SIP交互 ： Session Initiation Protocol，缩写SIP,正如协议的名称所言，用于初始化会话。MRCP交互和RTP交互都基于此会话进行。交互的媒体能力和地址都基于SIP消息携带的SDP信息进行协商。SIP消息一般基于UDP协议交互。
2.MRCP消息交互：控制具体的基于语音的操作（语音识别、语音合成等），同时传递操作的信息和结果（识别结果传递、需要合成语音的文本内容等）。MRCP消息一般通过TCP协议交互。
3.RTP消息交互：传递操作中的音频流。RTP消息一般基于UDP协议交互。
作为一个MRCP Server，包含了上面的协议的三部分。如何才能对同时包含了三中交互方式的协议进行均衡负载和容错呢。我们即需要保证同一会话的SIP消息转发给同一节点，还需要保证与该会话绑定的MRCP消息和RTP消息都走对应的节点。
看似复杂，其实很简单，我们只需要对SIP交互进行负载均衡即可。通过观察SIP交互内容，我们不难看到，MRCP消息和RTP消息的交互地址，都是在SIP交互过程中，由SDP协商的。也即，MRCP消息的交互和RTP消息的交互的双方地址都是基于SIP消息得到的。
如从下面MRCP Server返回的200SIP消息可以看出，MRCP消息交互使用9.75.181.154:1544,而媒体则使用9.75.181.154:5028。
MRCP的SIP协商
只要我们SIP协商成功，那么对应的MRCP 和 RTP交互是基于协商地址直接交互的。因此只要做到了SIP消息的负载均衡，就做到了MRCP会话级别的负载均衡。
下面我们来谈谈如何进行负载均衡。
方案一： 使用NGINX进行UDP代理
Nginx 1.9版本增加了Stream模块，支持4层代理，
如下图所示，只需要配置stream模块进行代理即可。nginx会自动均衡请求到负载节点。这里有几个配置项要补充描述一下：
proxy_responses ： UDP转发时，此配置项决定了nginx在转发一个nginx请求后，反向转发多少个响应后认为释放通道。如下图所示，A给B发起一个请求后，B返回了10个响应，NGINX将10个响应转回到A后会释放通道，NGINX的临时转发端口将被释放，之后B的下一个返回消息将无法转回A。
proxy_timeout ： UDP转发时，如果A从端口p1通过ngxin向B发送了请求，100s内的同源ip端口的请求会被转发到同一节点，同理在此期间能否原路返回响应。超时释放通道。
上面两个配置同时存在是，通道存在时长取最小值，即有配置触发了释放通道，通道即被释放。
MRCP代理nginx配置
有的文章可能会使用客户端ip hash的方式进行均衡，以保证会话一致性。实际上通过上面的配置，已经能够保证超时时间内的同会话请求转发到同一节点。反而使用ip hash时，需要考虑如何在机器数量不多时，使多个ip hash分部到不同节点上（这一块未仔细研究）。
关于容错，nginx会自动检查分发服务地址是否可达，如果不可达，会自动剔除该节点。当然，如果在会话中节点崩溃，进行中的会话会将无法继续提供服务，但系统不会进入故障状态，后续新会话会转发到剩余正常节点。
方案二：使用开源SIP框架，如OpenSips等。
OpenSips的部署可以参考官网，需要安装db进行均衡配置，同时通过route脚本进行分发控制。总体来说个人觉得成本稍大。当前采用了方案一。
