MRCP学习笔记-控制会话的消息体、参数设置和头域说明

　　在上一节的分享中，我们介绍了消息类型和基本语法。为了让读者更加清晰地了解具体的消息内容，我们在本章节会进一步介绍消息体的内容，两种基本的参数设置方式，几个标准的头域值说明和安全性讨论。

　　1、顾名思义，消息体是有多种信息按照一定的顺序构成的内容。其格式和SIP协议的消息体基本相似。以下是基本的内容类型：

　　这里要注意，在某些环境中，消息体可以由多个部分的信息数据来构成帮助创建一个完整的消息体。其具体的语法定义格式为：

　　Content-Type: multipart/mixed; boundary=a4V3bnq129s8

　　以上格式表示其消息体有多个数据构成，边界标识（boundary）是a4V3bnq129s8。因为消息体是由多个数据构成，每个消息都要设置边界标识来确认每个消息，并且边界标识必须在起始处和结尾处都标识边界，以表明这是一个多数据构成的一个完整的消息体（--a4V3bnq129s8--），边界标识符前面的连字符表示消息体初始，结束边界标识后面带两个连字符表示此完整的信息体结束。让我们看一下以下示例：

　　MRCP/2.0 521 SPEAK 20000

　　Channel-Identifier: 43b9ae17@speechsynth

　　Content-Type: multipart/mixed; boundary=a4V3bnq129s8

　　Content-Length: 374

　　--a4V3bnq129s8 // 表示第一个数据初始，以换行符结束

　　Content-Type: text/uri-list

　　Content-Length: 68

　　http://www.example.com/file1.ssml

　　http://www.example.com/file2.ssml

　　--a4V3bnq129s8 // 表示第二个数据初始，以换行符结束

　　Content-Type: application/ssml+xml

　　Content-Length: 140

　　xmlns="http://www.w3.org/2001/10/synthesis">

　　Hello world!

　　--a4V3bnq129s8-- // 带了两个换行符，表示多消息体数据结束

　　MRCP客户端对服务器端发送了一个SSML URL列表，包括了需要合成的消息内容，在以上的消息体中，同时包括了两个数据结构。在MRCP的消息体中，可以通过text/uri-list来设定一个或多个URL。

　　2、在某些情况下，我们不需要对会话中的某些参数进行修改或者调整。但是有一些环境中，我们可能需要对某些参数进行适当调整来满足实时环境的要求，因此MRCP提供了两种不同的参数设置方式来支持对某些会话中的参数进行设置。这两种设置方式是SET-PARAMS和GET-PARAMS。从字面意思，读者可能就会明白，一种是用来设置参数的，另外一种是用来获取参数。比较常见的例子如设置语音合成的声音高低，语音识别的定时器设置等。现在，我们分别介绍这两种方式。

　　SET-PARAMS通过头域来设定一个参数设置。如果媒体资源服务器返回200，则表示媒体资源服务器可以支持此参数；如果媒体资源服务器返回403表示媒体资源服务器识别一个或多个参数；404表示媒体资源服务器认为是无效参数。

　　MRCP客户端请求支持了参数设置语音合成的语言设置请求：

MRCP/2.099 SET-PARAMS 12309
Channel-Identifier:23fa32fg1@speechsynth
Speech-Language:fr-FR

　　媒体资源服务器的响应消息：

　　MRCP/2.0 77 12309 200 COMPLETE

　　Channel-Identifier: 23fa32fg1@speechsynth

　　上面我们介绍了如何设置SET-PARAMS 请求，GET-PARAMS 请求的处理也是同样的原理。对于MRCP 客户端对服务器端发送的头域，服务器端必须返回相应的头域和其相应的值，并且返回状态码 200，如果服务器端不能支持一些客户端请求的头域，服务器端则会拒绝这个请求，并且返回403 状态码。

　　MRCP客户端发送到服务器端的请求，要求获取两个具体的参数：

　　MRCP/2.0 … GET-PARAMS 543256

　　Channel-Identifier:32AECB23433802@speechsynth

　　Voice-gender:

　　Voice-variant:

　　Vendor-Specific-Parameters:com.example.param1;

　　com.example.param2

　　服务器端返回到客户端的响应和具体参数和其值：

　　MRCP/2.0 … 543256 200 COMPLETE

　　Channel-Identifier:32AECB23433802@speechsynth

　　Voice-gender:female

　　Voice-variant:3

　　Vendor-Specific-Parameters:com.example.param1="Company Name";

　　com.example.param2="124324234@example.com"

　　根据MRCP v2 的建议，如果需要获取的参数比较多的话，返回的数值打包的数据会非常大，因此这种方法获取参数的效率比较低，不建议用户经常使用这种方法来获取服务器参数。

　　3、在MRCP协议中，我们会使用两种类别的头域数值。一种是针对媒体资源服务器的头（resource-specific headers），另外一种是标准的头（generic headers）。例如我们上面介绍的两种管理参数的方式也可以适用于某些头域设置，也可以适用于指定的媒体服务器参数设置。

　　这里，读者一定要注意，根据MRCP v2 的规定，generic-header 的头域值的发送顺序或经过转发解析时，中间代理或解析器不能修改以上头的顺序。

　　因为标准头值中包括了多个具体的参数，因为篇幅的关系，我们这里不再做具体介绍，我们会在接下来的章节中继续进行讨论。

　　4、安全问题对控制协议来说也是一个比较大的挑战。在基于DTMF的语音IVR中，我们也可以轻易获得查询数据，安全人员可以通过DTMF解析获取到其登录密码或者账号信息等敏感内容。在MRCP的运行环境中，我们也会遇到类似的安全问题。在控制协议中，我们的应用程序可能会同时需要连接多个媒体资源服务器，用户可能通过SPEAK请求来获取系统敏感信息，例如密码等。媒体资源服务器则会通过NLSML 数据格式在事件消息中返回RECOGNITION-COMPLETE，这些消息会把密码等敏感数据携带在在事件的消息中。为了防止安全隐患的发送，系统用户可以考虑使用TLS或VPN等其他安全机制来增加系统的安全性。

　　5、在本章节的分享中，我们首先介绍了MRCP中消息体的结构，在消息体中特别重点介绍了边界标志符来区分数据包结构，笔者然后介绍了两种管理参数的方式已经交互流程，并且介绍了标准的headers，最后简单讨论了在使用控制会话中的安全性问题以及安全机制设置。

　　在下一个章节中，我们会继续讨论generic-header的每个具体的头的内容。