MRCP协议学习笔记-关于媒体资源服务器的定位路由策略

前面我们讨论了分布式的媒体源处理方式和直接指定了媒体资源服务器。但是，如果媒体资源服务器是通过分布式部署，同时为了拓展性的需要，可能不同的媒体资源服务器支持了不同的功能。MRCP 客户端需要查询媒体资源服务器来进行进一步的处理。为了对多个媒体资源服务器进行路由调度处理，我们将简要介绍关于媒体资源服务器的能力支持查询和媒体资源代理（MRB）的使用方式，其路由方式的存在的问题进行讨论，还有如何使用SIP拓展来实现媒体能力查询。

1

MRCP 客户端可以通过一个OPTION 请求来对媒体资源服务器进行能力查询，然后通过路由方式对媒体资源服务器进行进一步的控制管理。现在让我们看一下如何实现MRCP 客户端发送OPTION请求进行媒体资源服务器查询处理。

这是一个从MRCP客户端发送到OPTION请求消息内容：

Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKab3

Max-Forwards: 70

Accept: application/sdp

Content-Length: 0

媒体资源服务器的回复的响应消息中，我们可以看到媒体资源服务器端的各种支持能力：

SIP/2.0 200 OK

Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKab3

Max-Forwards: 70

Allow: INVITE, BYE, OPTIONS, ACK, CANCEL

Content-Type: application/sdp

Content-Length: 288

v=0

o=Server 289123140 289123140 IN IP4 host99.example.com

s=-

t=0 0

m=application 0 TCP/MRCPv2

a=resource:speechsynth

a=resource:speechrecog

a=resource:recorder

m=audio 0 RTP/AVP 0 8 96

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:96 telephone-event/8000

a=fmtp:96 0-15

在响应消息中，媒体资源服务器支持的三种媒体资源，它们是语音识别，语音合成和录音。媒体资源服务器可以支持PCMU 和PCMA的格式，同时，它也支持RFC 2833, a=fmtp的 payload是96，支持16个 DTMF事件。通过回复消息，我们获悉了媒体资源服务器端所支持的功能。

2

在实际生产环境中，我们不可能总是使用一种媒体资源来实现对多种MRCP客户端的支持。为了实现媒体资源服务器的拓展和逃生处理方式，我们需要媒体资源服务器能够实现灵活方便的媒体资源支持，同时也能够应对不同的媒体资源能力的需要。其解决办法就是在MRCP客户端和媒体资源池之间提供一个路由的功能或者媒体资源代理，我们称之为-Media Resource Broker（MBR）在实际生产部署环境中，用户可以通过以下两种方式来实现对媒体资源服务器的路由管理。现在我们简要介绍一下两种媒体资源服务器的部署方式。

3

首先，我们介绍一下所谓的内联方式来处理媒体资源服务器的路由管理。此方式是基于SIP代理的工作方式。在这种内联工作模式下，MBR通过定位服务器数据库查询INVITE请求中的REQUEST-URL，获得相应的媒体资源服务器的AOR记录信息，然后返回到SIP代理服务器，它会通过不同的路由策略来对媒体资源服务器进行路由处理。SIP代理对有效的媒体资源服务器进行不同的调度路由，它支持的路由查询方式可能是轮询方式或其他的任意路由方式等。如果出现媒体资源调度失败的响应消息，它可以通过二次路由使用其它媒体资源来实现逃生功能。

4

另外一种MRB的路由调度方式就是使用转发服务器来进行路由处理。

在此示例中，MRB可以通过重定位服务器来进行一个基本的查询服务。重定位服务器通过回复一个302 Moved Temporarily 响应，通过响应消息中的Contact头来表示媒体资源服务器。此方案仍然通过轮询的方式来进行路由调度处理。

5

在上面章节中的示例中，我们都是假设媒体资源服务器池中注册的都有同样的AOR和同样的支持能力。但是，在实际生产环境中，可能一台媒体资源服务器同时支持了语音识别和语音合成，但是另外一台资源服务器可能仅支持语音识别。为了支持这种比较复杂的部署环境，我们通常会要求MRCP客户端请求时携带推荐的支持能力，这样的话，MRB会根据客户端的推荐能力来选择路由策略，最终可以实现复杂环境中智能化的媒体资源路由管理。

为了保证准确获悉媒体资源服务器的支持能力。同样的原理，MRB也要需要一个控制机制来获悉媒体资源服务器的支持能力，当注册到定位服务器时，媒体资源服务器首先需要对MRB声明自己的媒体资源服务器所支持的媒体类型。MRB可以通过一个OPTION 请求来查询定位服务器数据库中的不同的媒体资源服务器URL来获得媒体资源服务器的支持能力。

如果MRCP客户端发起一个请求时，来自MRCP INVITE中会在SDP中携带所需要的媒体资源服务器的支持能力，MRB会对照检查MRCP客户端的SDP消息体，它然后会和媒体资源服务器端所提供的支持能力进行对比，然后给出路由策略。但是这样的方式可能会存在一定的局限性，如果SDP是支持的加密的S/MIME时，SDP消息体的访问会被拒绝，所以在使用时需要读者了解具体的适用场景。

另外一种解决方案就是使用SIP协议的拓展来支持对媒体资源服务器的路由处理。RFC3841协议提供了一种机制可以让SIP用户代理或MRCP客户端来标识自己的推荐能力。服务器端可以对其INVITE消息回复一个结果。RFC3840协议也可以支持服务器端来标识自己的功能支持。客户端在注册时，服务器端会添加一些额外的标签来表示支持能力。此处理方法就是在注册时，对Contact URL添加 URL参数（功能标签）来表示所提供的支持能力。MRCP客户端则可以在INVITE中通过Accept-Contact 头域设定一个所需功能。

这里，MRB实际上执行了一个媒体资源协商的过程。MRB接下来会URL来查询定位服务器来选择一个合适的媒体资源服务器。通过匹配MRCP客户端发送的功能请求标签，对比媒体资源服务器所提供的功能支持，最后给MRCP客户端返回最终的推荐支持功能，并且对MRCP客户端返回协商后的建议的功能标签。

6

在本章节中，笔者重点讨论了如何实现媒体资源服务器的定位查询，同时介绍了媒体资源服务器的支持能力的问题。我们也讨论了关于MRB 媒体资源服务器代理和其部署方式，包括分布式部署的媒体资源服务器的两种类型。在讨论了两种类型后，我们添加了对通过SIP拓展方式实现媒体资源路由的支持的讨论，并且具体解释了媒体支持能力，功能标签的处理和其协商过程。

参考资料：

https://tools.ietf.org/html/rfc3841

http://www.ietf.org/rfc/rfc3840.txt