语音识别资源的概括和全部Methods

在前面的分享中，我们介绍了媒体资源中语音合成资源的请求，事件和一些头的使用方式。今天，我们进一步介绍媒体资源中另外一个非常重要的核心内容-语音识别资源的请求，在后续的章节中介绍事件和一些相关头的使用方式。

　　MRCP语音识别资源针对语音数据和DTMF事件进行分析，然后通过媒体会话来进行传输，最后返回文本形式的处理结果。MRCP协议将语音识别资源的类型分成两种：dtmfrecog和speechrecog。前者只能支持DTMF的识别，因此语法也仅限于DTMF语法的支持；后者则支持语音流数据的识别和DTMF识别，因此其语法支持语音语法和DTMF语法两种。另外，在今天的讲座中，我们会涉及其语法的使用方式（SRGS和NLSML），我们在以前的章节中对这些语法也做过一些介绍，读者可以查阅历史文档掌握这些必要的知识。

　　1、在前面的部分我们已经提到，dtmfrecog仅提供对DTMF事件的支持，因此它可以归并到speechrecog中。dtmfrecog提供了speechrecog的功能所支持的一部分功能子集，支持了DTMF输入和相应的DTMF语法。DTMF数字值则是通过RTP事件或DTMF tone分析获得。语音识别资源可以在以下其中一种模式下工作：

1. normal mode recognition
2. hotword mode recognition

　　normal mode recognition 顾名思义是一种正常工作模式，它支持的是一种正常工作的模式，可以匹配整个语音句子或DTMF字符，然后和语法进行对比，返回RECOGNITION-COMPLETE，这个事件包含成功或失败的状态消息（，例如，001 no-match，无输入匹配）。Hot word mode recognition工作的模式有所不同，它仅对一些热词感兴趣，会查询一些短语和DTMF的排序，并且忽略不匹配的部分。如果MRCP客户端取消了识别请求，或者No-Input-Timeout或Recognition-Timeout定时器超时的话，它仅完成成功匹配的语法。因此，热词模式结束时从来不会返回Completion-Cause码 001 no-match。热词模式可以使用在很多的场景中。简单的例子就是电话转接或我们在电销场景中的价格或者地址等关键词的处理。如果在监听时，听到说话人需要返回主语音导航菜单时，我们可以立即返回主菜单。如果在电销场景中，我们听到客户提到价格时，我们可以打断然后查询相关的价格，然后返回价格数据。另外，语音识别资源还可以支持第三种的工作模式，那就是基于文本的"interpretation" 模式。文本语句通过控制会话（不是媒体会话）发送到语音识别资源，通过语法匹配，然后返回识别结果并且携带语义解析。此功能可以支持很多场景，例如，它可以支持创建一个基于文本的工具来测试语法的覆盖情况和修正语义解析的语法标签。

　　语音识别资源可以支持六个请求消息和三个事件消息。Voice enrolment 又进一步增加了五个请求方法来支持创建和管理注册的语法。

　　语音识别资源支持的methods 消息：

　　另外五个注册的语音语法methods：

　　三个事件消息：

　　语音识别资源的状态机图例：

　　音识别状态机是由MRCP客户端来发起请求，媒体资源端则会生成返回事件消息。以上示例是一个非常简单的状态机使用场景，它对注册语法进行训练处理。这里的起始会话和结束会话不会改变资源的状态。通过RECOGNIZE 触发触发事件后，状态机中每个被捕捉的句子的结果状态会从空闲状态切换到正在识别状态，当触发 RECOGNITION-COMPLETE事件时，则又返回到空闲状态。

　　语音识别资源支持了标准的头值和更多对语法注册支持的头值。标准的headers参数设置（三十三个headers）：

　　支持语法注册的headers（支持十二个enrollment-header ）：

　　2、笔者在上面的部分重点概括介绍了语音识别资源的请求方法，事件和一些相关的headers。现在我们开始介绍语音识别资源具体的请求方式。RECOGNIZE是我们第一个介绍的请求方式。

　　简单来说，RECOGNIZE请求是启动识别流程，紧接着为输入的语音流进行匹配，然后设定匹配的词语的语法。识别结果会包含在RECOGNITION-COMPLETE 的事件中。Hotword发识别模式会在Recognition-Mode头值中进行设置。默认设置是normal模式。RECOGNIZE请求中可以包含一些头值来调整相关的请求，这些可调整的请求头包括语言，安全阀值，和定时器设置等。

　　语音识别资源可以支持对RECOGNIZE 请求进行队列管理，也可以进行单独运行而不进入队列中。具体的操作上通过Cancel-If-Queue 头的设置来进行设置。因为Cancel-If-Queue牵扯了多种处理状态，流程处理的响应都完全不同，我们这里不做过多解释。用户可以参考RFC标准做进一步的了解。

　　MRCP协议根据不同的normal或hotword识别模式的不同，定义了不同的定时器来控制识别处理。normal 识别模式的定时器设置：

　　hotwords 识别的定时器设置：

　　现在，让我们看一下RECOGNIZE  请求的图例：

　　相应的消息流程如下：　　

     　　

　　3、DEFINE-GRAMMAR method是请求语音识别资源访问消息体中语法进行访问，提取和编译。MRCP客户端不一定需要发起DEFINE-GRAMMAR 请求执行识别，相反的，它可以给客户端提供一个选择来准备处理比较大的语法文件。DEFINE-GRAMMAR请求的响应消息总是携带COMPLETE的响应。成功的响应消息返回200 Success和一个头消息000 success。如果返回错误的话，则会收到407 Method 或 Operation Failed，并且携带Completion-Cause 头。以下是一个DEFINE-GRAMMAR 的示例：

　　相应的响应消息流程如下：

 

　

　

　　4、START-INPUT-TIMERS 是对定时器设置的请求方式。在MRCP v1的版本中这个method称之为RECOGNITION-START-TIMERS。 默认环境下，当识别资源启动以后，No-Input-Timeout 定时器就会自动启动，如果在超时之前，没有检测到任何的输入的话，识别就会结束，并且返回RECOGNITION-COMPLETE消息，消息中携带Completion-Cause，此值设置为002 no input-timeout。以下示例是一个START-INPUT-TIMERS的请求示例：

 

　　START-INPUT-TIMERS 具体的消息处理流程如下：

　

    

　　5、当识别请求成功完成后，识别结果会通过RECOGNITION-COMPLETE事件中的消息体返回到客户端，并且识别引擎进入到已识别状态。返回结果可依赖于识别参数设置，例如安全阀值和N-Best-Length-List等。这里，我们可以使用GET-RESULT method来对进入识别状态的结果重新计算，或通过GET-RESULT 请求，根据识别设置参数返回相应的结果。例如，MRCP客户端可以发起一个GET-RESULT 请求，设置了较低的安全阀值（Confidence-Threshold ）和较高的N-Best-List-Length 来获得一个假设值。以下是一个GET-RESULT的图例：

　　GET-RESULT相应的消息流程如下：

<result< div="" style="margin: 0px; padding: 0px; border: 0px; list-style: none; clear: both; float: none; line-height: 26px;">

　　6、STOP method可以支持对IN-PROGRESS 状态（活动的状态）或PENDING（队列中的）请求执行停止。如果在STOP请求中忽略了Active-Request-Id-List 头的话，说明活动状态的请求已经停止，在队列中的识别请求已经被移除。如果STOP请求成功结束了一个或多个活动的识别请求或队列中的识别请求，返回到客户端的响应消息是200 Success，并且包含一个Active-Request-Id-List 头，这个头值中包含了停止的请求ID列表。注意，这里服务器端也不会发送RECOGNITION-COMPLETE 事件。如果没有结束的识别请求，同样，客户端也会收到200 Success，但是会忽略掉Active-Request-Id-List 头。有时，我们可以在STOP method的Active-Request-Id-List 头中指定一个请求ID来停止这个识别请求，这个识别请求可能是在当前IN-PROGRESS状态或PENDING队列中的识别请求。如果当前活动的识别请求被停止后，则可以处理下一个在PENDING队列中请求。以下是一个STOP 示例图：

　　以下是相应的消息流程：

　

　　7、INTERPRET method 的使用方式和RECOGNIZE 的method 非常相似，不同之处在于，RECOGNIZE是支持语音输入的，但是这里的输入是完全基于文本格式的形式，通过Interpret-Text 头来设定这个文本格式。其返回的解析结果包含在INTERPRETATION-COMPLETE的事件消息体中。这里，读者一定要注意，不像RECONGIZE method，它的请求不能支持队列设置。如果有一个INTERPRET在处理状态时，再次发起另外一个INTERPRET会导致返回一个402 Method not valid in this state。所以，读者一定要注意此method的使用方式。以下是一个INTERPRET的图例：

　　INTERPRET的消息处理流程如下：　

　　8、在本部分的介绍中，笔者将介绍关于Voice enrolment 的几个method方式。

　　这里，我们首先介绍一下START-PHRASE-ENROLLMENT。

　　START-PHRASE-ENROLLMENT 的目的是支持MRCP客户端启动一个注册会话（这里，翻译成enrolment session，也可能有其他作者的翻译名称）。注册会话的功能在于对每个独立的说话人添加一个特别的短语，形成一个个人的语法。在注册会话的生命周期内，MRCP客户端会调用RECOGNIZE 请求，并且携带了Enroll-Utterance，这里，此头值设置为true。每一次对RECOGINE调用都会捕捉单个的短语例句，并且执行注册流程，最后以NLSML的文件格式通过RECOGNITION-COMPLETE进行传输。一般情况下，识别资源需要重复多次来训练短语。MRCP 客户端通过调用END-PHRASE-ENROLLMENT来结束此注册会话。如果要配置一个注册会话，在START-PHRASE-ENROLLMENT的请求中需要设定多个头域。这些头域包括Personal-Grammar-URI（独立说话人的个人语法设置），Phrase-ID（短语唯一的ID）和Phrase-NL（短语支持的自然语言或语义结果）。以下图例说明了START-PHRASE-ENROLLMENT的流程：

　　以下是相应的消息流程：　
　

　　第二个介绍的请求是ENROLLMENT-ROLLBACK。MRCP客户端发起一个ENROLLMENT-ROLLBACK 请求回滚到上一个请求。此功能可以对句中不适合部分进行处理排除。这里要求丢弃上一次RECOGNIZE请求中捕获的语音。以下是一个ENROLLMENT-ROLLBACK图例：

　　具体的消息流程如下：

　　F1（client→speechrecog）:

　　MRCP/2.0 83 ENROLLMENT-ROLLBACK 70000

　　Channel-Identifier:23af1e13@speechrecog

　　F2（speechrecog→client）:

　　MRCP/2.0 76 70000 200 COMPLETE

　　Channel-Identifier:23af1e13@speechrecog

　　这里，我们继续讨论第三个请求方式。END-PHRASE-ENROLLMENT是由MRCP客户端发起，用来结束注册会话的一个method，可以对接受的注册短语进行确认或丢弃短语。这个method通常是识别资源返回的RECOGNITION-COMPLETE事件中包含NLSML，并且携带了 重复数量设置，然后MRCP客户端发起END-PHRASE-ENROLLMENT来结束注册会话。如果要中断短语注册的话，在END-PHRASE-ENROLLMENT的请求中设置Abort-Phrase-Enrollment置为true。如果在START-PHRASE-ENROLLMENT请求中出现了Save-Best-Waveform 头，并且此头设置为true，那么在返回的END-PHRASE-ENROLLMENT事件中会包含一个Waveform-URI来表示一个经过训练的短语录音存放路径。这些文件可以支持MRCP客户端选择类型，用户可以根据相应的个人的语法读出短语。因为END-PHRASE-ENROLLMENT 的消息流程也比较简单，我们这里不再做过多解释，用户可以参考说明的例子来学习。

　　修改短语是第四个请求方式。MODIFY-PHRASE用来支持对个人语法中已注册的短语中的某些参数属性进行修改。可修改的属性包括：Phrase-ID，Phrase-NL，和Weight。可修改的短语通过其Phrase-ID来确认它的唯一性，通过头域值设置修改Phrase-NL或Weight。如果是ID被修改的话，客户端会生成一个新的New-Phrase-ID头来表示这是新的短语ID。以下图例表示了MODIFY-PHRASE 流程：

　　具体的MODIFY-PHRASE消息流程如下：

　　F1（client→speechrecog）:

　　MRCP/2.0 133 MODIFY-PHRASE 90000

　　Channel-Identifier:23af1e13@speechrecog

　　Phrase-ID:Name01

　　New-Phrase-ID:Name03

　　Weight:0.5

　　F2（speechrecog→client）:

　　MRCP/2.0 76 90000 200 COMPLETE

　　Channel-Identifier:23af1e13@speechrecog

　　删除短语是第五个请求方式。DELETE-PHRASE method是客户端用来从个人语法中删除一个短语ID，通过Phrase-ID来表示，个人语法的设定通过Personal-Grammar-URI来表示。以下是一个删除短语的图例：

　　其具体的删除短语的消息流程如下：

　　F1（client→speechrecog）:

　　MRCP/2.0 162 DELETE-PHRASE100000

　　Channel-Identifier:23af1e13@speechrecog

　　Personal-Grammar-URI:http://enrolledgrammars/user01gram02.dat

　　Phrase-ID:Name01

　　F2（speechrecog→client）:

　　MRCP/2.0 77 100000 200 COMPLETE

　　Channel-Identifier:23af1e13@speechrecog

　　回顾本章节的内容，我们首先介绍了语音识别资源的请求处理方式，事件和headers，并且列出了它们的使用方式和属性设置。然后，笔者重点介绍了语音识别资源的六大methods和语法注册时使用的五个methods。因为篇幅的关系，笔者把语法注册的methods 归纳在一个话题中，以便方便读者能够结合这些相关的method充分了解注册语法的这些请求处理方式。笔者相信，通过本章节关于语音识别资源的请求处理的概念介绍结合图例和消息流程，读者会进一步了解语音识别的消息流程处理

转载自：http://ec.ctiforum.com/jishu/qiye/qiyetongxinjishu/kaiyuantongxin/jishudongtai/539618.html

版权归原作者所有