MRCP协议学习笔记-MRCP概要

　　1、准确地说，MRCP是一种框架，也是一种协议。MRCP的框架定义了各种网络要素和它们之间的关系，并且也设定了在MRCP中其他协议之间的之间的会话管理和媒体处理等关系（例如SIP和RTP）。MRCP协议本身也提供了对媒体源的控制机制，例如控制语音识别和语音合成等。所以，通常环境下，我们为了方便，称之为MRCP协议。当然，读者也可以称之为MRCP框架。

　　MRCP的设计目的是支持客户端对服务器端发起一个请求，设定一个在网络中部署的媒体资源。MRCP的主要目的在于语音处理资源的处理，这些语音处理资源包括：语音识别，语音合成，语音录音和讲话人的认证和确认。MRCP借用了SIP协议来支持MRCP的处理流程。SIP可以使用SIP URL通过网络来支持MRCP客户端来获取媒体资源，并且可以查询获取到媒体类型和其支持能力。它一旦获取到正确的媒体资源服务器信息，SIP将会创建两个通信管道，一个是用来支持媒体会话，它支持发送或接收语音数据。这些数据可能是从媒体资源服务器发出也可能是来自于媒体资源服务器。另外一个管道是控制会话，它用来支持MRCP客户端和媒体资源服务器之间的请求通信，从服务器端返回响应消息和事件。这里，MRCP协议是运行在控制会话之上。以下图例表示了一个基本的MRCP框架。

　　在MRCP 客户端包括了SIP协议栈和MRCP协议栈。后者扮演的就是一个MRCP客户端角色。当应用层的程序请求一个媒体资源的时候，它会调用媒体资源的API接口。此API接口通过SIP协议栈会创建一个SIP dialog 并且携带媒体资源服务器信息。SIP协议栈会通过RTP对媒体服务器资源初始化一个媒体会话，并且通过MRCP对媒体资源服务器创建一个控制会话。

　　在会话初始化过程也可以包括一些服务器端可预设的专用媒体资源。接下来，MRCP客户端可以通过会话控制直接调用这些专有的媒体资源。MRCP客户端可以在同样的终端设备或作为其他实体的一个部分包含媒体资源。客户端的SIP协议则可以充分利用信令和媒体分离的方式，它们分别通过不同的路径来处理。

　　媒体资源服务器端的也同样包括了MRCP协议栈和SIP协议栈。服务器端的MRCP执行的是服务器端的MRCP协议栈，并且对MRCP客户端的请求做出响应，生成事件。如上图所示，服务器端包括了各种媒体资源，例如语音识别，合成等引擎。当客户端请求多个资源时，这些资源可以共享同一媒体会话或支持针对每个媒体资源的专有会话。以下图例比较清晰地解释了上面的架构示例，方便用户做进一步的理解MRCP的架构。

　　MRCP充分地利用了SIP协议的优势，非常完美地解决了管理媒体和控制会话的问题。从SIP协议的角度来看，它管理的话会话属性本身不是最重要的，它更侧重于对媒体资源的定位，提供一个整合功能。因为SIP协议提供的媒体资源服务器查询服务，MRCP客户端可以获得关于媒体资源的支持能力。

　　2、在上面的章节中我们讨论了MRCP的基本架构，其中，在服务器端支持了很多媒体资源。媒体资源则包括了各种媒体类型。MRCP定义了六种媒体资源类型，它们分别是：

　　Speech synthesisers（语音合成）支持了两种语音合成方式。一种是基本的语音合成。基本语音合成把语音文件简单进行合成，仅支持有限的部分SSML标准，它必须支持的基本语法包括：，

　　dtmfrecog和speechrecog都是媒体资源，都支持语音识别。dtmfrecog仅对DTMF进行识别。speechrecog则是我们通常所说的语音识别。两种媒体识别都借用了W3C 的Speech Recognition Grammar Specification （SRGS）设定了单词，短语（包括DTMF）来作为语音识别的输入。语音识别媒体资源通常还包括对通过语音识别对自然语言结合语法等进行处理识别的能力。

　　speech recorder则提供对语音进行录音，然后保存到一个指定的URL，另外，它同时也对终端提供一种语音静音处理作用。当用户在某一段设定时间后已经停止讲话，用户录音应该会去除静音时间。

　　Speakverify 媒体资源主要的作用利用声学技术，通过对讲话者的语音和已保存的声纹进行匹配，确认其身份和签权认证。

　　3、媒体资源服务通过MRCP支持了很多应用场景。现在我们简单介绍几个具体的应用场景，让用户理解如何通过MRCP结合语音电话系统来实现分布式语音媒体处理。

　　首先，我们介绍一个VoiceXML IVR 场景。这里的VoiceXML相当于一个MRCP的客户端，支持了SIP协议栈，VoiceXML 解析器和MRCP客户端。同时，它也支持了PSTN的接入，通过SIP 协议对接MRCP客户端SIP。媒体资源服务器端包括了语音识别，合成，录音和DTMF识别处理引擎。这样的应用场景可以运用在呼叫中心等相关的行业。当然，目前的很多呼叫中心智能机器人也基本上和以下示例相似。客户端可以支持Asterisk或者FreeSWITCH，通过uniMRCP实现和媒体资源引擎的交互。

　　早期智能化的IPPBX语音邮箱也是一个经典的应用场景。首先，这里我们说明，这是一个早期的语音邮箱的服务示例。当然无论从功能的丰富性，成本优势或其他集成能力，目前的IPPBX或者软交换的语音邮箱系统本身已经非常灵活强大。目前，开源的融合通信平台，例如Asterisk，FreeSWITCH都支持了非常强大的语音留言功能，可以轻松实现标准化的语音邮箱的语音提示。特别是基于Asterisk平台开发的开源免费IPPBX-FreePBX，它支持了丰富的界面管理，用户可以通过界面轻松配置语音邮箱。但是这些不是我们今天讨论的范围。今天，我们重点讨论的是基于MRCP集成的IPPBX 语音邮箱。基于MRCP的语音邮箱系统可以通过MRCP对呼叫方进行录音，合成和语音识别，实现对用户电话留言进行管理，包括语音文件内容，日期，呼叫方名称等。这些数据都可以通过语音资源引擎进行处理，方便储存。这是以前基于MRCP开发的一种语音邮箱服务，具体市场用户的认可度有多高，我们也不得而知，毕竟语音资源引擎的部署成本和准确率是一个非常大的挑战。这里，我们仅作为一个演示的示例。但是，笔者认为，如果对于IPPBX来说，如果呼叫方（例如，残障人士，老人，或者病人等）直接对IPPBX系统说一个公司员工的名称就可以自动实现呼叫此员工分机，呼叫方不需要再通过摁DTMF 按键来拨号，这也许也是一个可行的需求。

　　最后，我们再介绍一个高级媒体网关，智能终端或软交换的应用场景。其实，这里的媒体网关应用场景和上面所说的IPPBX结合MRCP的应用场景非常相似。这里的高级媒体网关仍然是MRCP的客户端，通过不同的SIP终端（例如，PJSIP 等终端），物理话机对媒体网关发起一个请求，通过媒体网关的MRCP模块和媒体资源服务器端的语音资源引擎进行处理。这样的应用场景和以上我们讨论的两个场景都有相似之处。所不同的是，如果通过开源SIP终端，结合软交换或媒体网关可以实现更多的应用场景，不仅仅局限于语音呼叫业务本身。例如，用户可以通过PJSIP 终端，可以开发手机APP终端，也可以通过PJSIP嵌入式终端方式实现智能物联网等需求。

　　4、我们在上面的篇幅中分别介绍了MRCP的技术架构示例，媒体资源类型和网络应用场景。为了进一步了解SIP协议和MRCP协议，我们花一点时间介绍一下SIP协议和MRCP的工作流程。

　　首先让我们简单了解一下如何创建通信的通道。笔者在前面的介绍中已多次讨论过，MRCP借助SIP协议完美地解决了通信的控制问题。MRCP本身没有定义自己的查询媒体资源能力和会话创建机制。它借助于SIP协议来完成。大家知道，在IP通信中，SIP可以在两个终端之间创建媒体会话。而媒体的传输则是独立于SIP协议之外的RTP协议来完成。在创建会话过程中或者呼叫中的交互中，SIP协议使用了SDP协议来协助描述和协商媒体会话。以下是一个简单的呼叫创建流程，这里不再介绍SIP呼叫的创建过程。读者可以参考其他材料做进一步的了解和学习，读者也可以查阅本公众号的历史文档有非常详细的介绍。

　　在简单的应用环境中，一次从媒体资源服务器调用一种单个的媒体资源类型，媒体会话也是单向的。如果同一时间使用多个媒体资源类型时则创建双向的媒体资源流。MRCP和我们常见的IP通信不同，它可以对媒体会话包含一个控制会话连接。此控制会话是通过在SDP描述中添加更多消息，例如包括MRCP客户端请求的媒体资源类型等。这里，媒体会话的传输是使用RTP通过UDP端口来传输；而控制会话则是通过MRCP通过TCP或者SCTP传输。以下示例是一个MRCP客户端连接媒体资源服务器的流程。这里，不要求支持180 响应，但是创建了一个媒体会话和一个控制会话。

　　以上流程中，创建了会话以后，MRCP需要控制媒体资源。MRCP协议消息格式类似于HTTP的消息格式，也是一种外部格式。MRCP消息格式包括三种格式：请求消息，响应消息和事件。请求消息是从MRCP客户端发到媒体资源服务器端，而响应消息则是由媒体资源服务器端，根据客户端的请求返回的响应消息，并且响应消息中包含了一个三位数的状态码。另外，响应消息中包含了当前的请求状态，当前请求状态包括：PENDING，IN-PROGRESS 或 COMPLETE的其中一种。

　　PENDING 状态表示当前的请求在等待处理的队列中，等待进行处理，处理方式为先进先出的方式。IN-PROGRESS状态表示当前请求正在被处理。COMPLETE响应则表示完成请求处理，在当前的连接中无更多消息。在以上三种状态中，PENDING和IN-PROGRESS都表示请求未完成处理，需要更多的事件消息。事件消息允许媒体资源服务器端和客户端对某些状态的改变或对客户端发生一个事件来进行通信。事件消息中包括事件名称和请求状态。

　　5、以上章节介绍了MRCP如何通过各种消息来控制媒体资源。为了让读者更加清晰地了解整个流程的处理方式，我们通过两个完整的示例来说明MRCP协议对媒体的控制和消息格式。

　　第一个关于MRCP协议的流程示例是语音合成（speech synthesiser）的示例。这里，我们假设媒体会话和控制会话通过SIP响应已经创建成功，语音流正在传输。MRCP客户端对服务器端发起了一个SPEAK的请求，开始处理此请求，并且要求通过媒体资源服务器合成一个文本。

　　具体的请求消息格式如下：

　　MRCP/2.0 380 SPEAK 14321

　　Channel-Identifier: 43b9ae17@speechsynth

　　Content-Type: application/ssml+xml

　　Content-Length: 253

　　

　　

　　Good afternoon Anne.

　　You have one voice message, two e-mails, and three faxes

　　waiting for you.

　　

　　接下来的响应的消息格式为：

　　MRCP/2.0 119 14321 200 IN-PROGRESS

　　// ID是14321，200 表示成功，正在处理中，119消息长度是119 bytes。

　　Channel-Identifier: 43b9ae17@speechsynth

　　Speech-Marker: timestamp=857206027059 // 这里是NTP时间

　　MRCP的状态码包括：200–299（Success）， 400–499（ Client error）和500–599（Server error）。这些状态码和SIP的状态码基本类似。

　　读者已经看到，我们的请求的状态是IN-PROGRESS ，表示正在被媒体资源处理，大部分情况下，媒体数据可能已经返回到MRCP终端。

　　接下来，媒体资源服务器端生成一个SPEAK-COMPLETE事件，表示此请求已经完成，对于此请求来说，没有更多的事件进行处理。

　　MRCP/2.0 157 SPEAK-COMPLETE 14321 COMPLETE

　　Channel-Identifier: 43b9ae17@speechsynth

　　Speech-Marker: timestamp=861500994355

　　Completion-Cause: 000 normal // 表示SPEAK请求的正常处理结束。

　　通过以上几个步骤和响应消息处理，我们可以清晰地看到语音合成的基本处理流程和其相应的返回码。

　　以上是一个语音合成的MRCP处理流程，我们再介绍一个语音识别的MRCP处理流程。这里，我们仍然假设通过SIP协议，会话控制和媒体控制已经创建成功。以下是一个MRCP客户端发出的请求消息，它要求媒体资源服务器对语音进行识别。注意，这里的请求是RECOGNIZE 请求，而不是刚才我们在语音合成时的SPEAK请求。

　　RECOGNIZE请求消息如下：

　　MRCP/2.0 461 RECOGNIZE 32121

　　Channel-Identifier: 23af1e13@speechrecog

　　Content-ID:

　　Content-Type: application/srgs+xml

　　Content-Length: 289

　　

　　

　　xml:lang="en-GB">

　　

　　

　　yes

　　no

　　

　　

　　

　　以上消息格式和SPEAK请求格式非常相似，这里的通道是使用的是speechrecog 媒体资源。这里需要识别的是两个选项（Yes/No）。同样，媒体资源服务器对客户端返回一个正在处理的状态消息：

　　MRCP/2.0 79 32121 200 IN-PROGRESS

　　Channel-Identifier: 23af1e13@speechrecog

　　此消息表示媒体资源服务器正在处理客户端请求，也可能语音识别引擎正在采集媒体流数据，马上生成一个识别的语音。当语音识别引擎检测到语音时，它会生成一个START-OF-INPUT消息。

　　MRCP/2.0 111 START-OF-INPUT 32121 IN-PROGRESS

　　Channel-Identifier: 23af1e13@speechrecog

　　Input-Type: speech

　　这里，客户端也可以结束或打断此语音合成。如果正常处理的话，语音识别引擎会生成一个RECOGNITION-COMPLETE事件消息，并且在消息中包含生成的结果。

　　MRCP/2.0 472 RECOGNITION-COMPLETE 32121 COMPLETE

　　Channel-Identifier: 23af1e13@speechrecog

　　Completion-Cause: 000 success

　　// 000 表示成功，001 表示无匹配结果，002 表示输入超时。

　　Content-Type: application/nlsml+xml

　　// W3C发布的NLSML

　　Content-Length: 289

　　

　　

　　xmlns="http://www.ietf.org/xml/ns/mrcpv2">

　　

　　

　　yes

　　

　　yes

　　

　　

　　在MRCP V2版本（RFC6787）中支持了两种结果输出格式，一种是nlsml（通常说的自然语言语义的标记语言或者描述语言）是由W3C发布。另外一种是EMMA标记语言。EMMA全称为Extensible Multimodal Annotation Markup Language （EMMA）。如果读者有兴趣的话，可以查阅相关的参考文档做进一步的研究。

　　6、通过以上完整的介绍，可能读者对MRCP有了一个基本的概念。但是，在部署MRCP客户端或服务器端时，我们这里没有真正关注其安全性的问题。在今天的IP通信中，其实用户已经对SIP协议的使用场景做了很多的设置，但是如果没有对MRCP协议或使用流程做安全设置的话，特别是MRCP协议中使用了多个XML文件和其语法语义解析文件，并且大部分的MRCP客户端都是通过公网访问的第三方的媒体资源服务器，如果没有设置安全措施的话，同样可能给客户带来很多的安全隐患。这些安全问题包括：

• 会话创建时的安全问题。在SIP创建过程中用户一定要注意安全的设置。
• 控制会话的保护。如果对其控制会话没有做保护措施的话，可能导致第三方对其进行安全攻击。
• 媒体会话的保护。如果我们的媒体数据没有经过安全设置，可能导致媒体数据被监听或盗取。
• 非直接的内容访问。因为，我们的合成内容或语音可能经过公网进行处理，如果第三方非法访问我们的最终数据，可能导致安全问题。
• 保护已存储的媒体文件。客户端和媒体资源服务器端需要针对媒体文件存储设置一定的安全措施和安全权限来保证媒体文件不被盗取或非法访问。

　　7、在本分享中，我们首先介绍了关于MRCP的基本结构，然后分别介绍了MRCP响应中多个核心模块和接口，MRCP客户端的处理方式和媒体资源服务器端的处理方式。我们也介绍了MRCP目前支持的媒体资源类型，以及结合语音服务，媒体网关完成对语音识别应用场景。为了进一步帮助读者了解进一步了解MRCP的处理流程，我们对媒体控制和几种请求响应状态和处理流程做了介绍，并且结合语音合成和语音识别的消息处理流程，给读者提供了一个较完整的消息解析。最后，为了部署安全稳定的解决方案，笔者也从几个不同的方面讨论了关于MRCP的安全性问题，希望读者能够引起重视。

　　在接下来的分享学习中，笔者会更加详细地一步步介绍MRCP协议中各个模块功能作用。希望读者继续关注。

　　参考资料：

　　https://www.w3.org/TR/2004/REC-speech-synthesis-20040907/

　　https://www.w3.org/TR/2009/REC-emma-20090210/

　　关注微信公众号：asterisk-cn，获得有价值的行业分享

　　freepbx 技术论坛：www.ippbx.org.cn

　　Asterisk， freepbx技术文档： www.freepbx.org.cn

　　欧米（Omni）智能客服解决方案

　　融合通信商业解决方案，协同解决方案首选产品：www.hiastar.com