说话人验证资源的请求、事件和headers详解

• MRCP学习笔记

　　在前面的讲座中，我们介绍了MRCP媒体资源的几个主要类型，它们分别是语音合成资源，语音识别资源和录音资源的所有请求，事件和headers的细节。今天的讲座中，我们介绍MRCP媒体资源的最后一个资源类型-说话人验证资源（speaker verification resource-speakverify）。

　　1、说话人验证资源对MRCP客户端提供说话人的验证和确认功能。说话人验证主要关心的是说话人应该是谁。通常情况下，说话人验证是通过他们自己声明的身份数据来验证。说话人通过一系列的验证方式来关联身份验证。这一系列的验证方式包括输入密码，客户ID，或者呼叫号码绑定的方式来加以验证。说话人的语句可以和其保存的声纹语句进行对比来确认其身份，然后执行通过或者拒绝的流程。而说话人确认功能则处理的是通过从多人的说话语句中识别出其身份，它通过已录制的语句对比一组存储的说话人声纹来确认说话人身份。简单来说，说话人确认就是一个已录制的语音和一组或者多组存储的声纹进行对比，识别出其身份。事实上，如果从MRCP说话人验证资源的角度来讨论的话，说话人确认可以看作为多组声纹的说话人验证方式。因此，为了讨论方便，我们通常使用说话人验证来表示验证和确认步骤。另外，MRCP验证资源的处理方式和基于文本方式的处理方式是相似的，它也借用了自然语言语义标识语音的语法格式来封装说话人验证和确认的结果。

　　2、MRCP验证资源可以在两种工作模式下执行，它可以配合语音识别资源或录音资源来工作，也可以独立工作。当独立工作时，它在媒体会话中通过实时传输的方式获得的语音数据，然后对语音数据进行分析。当结合其他媒体资源工作时，验证资源会通过验证资源的缓冲和语音识别资源或录音资源共享缓冲数据。通过设定Ver-Buffer-Utterance header，语音识别资源和录音资源可以对缓冲进行数据写入的操作。在语音识别或录音过程中，这个缓冲中的语音数据可以后续支持说话人验证或者确认的分析任务。

　　MRCP验证资源支持十一个请求消息，两个事件消息，二十个headers和一个状态机。状态机可支持两种工作模式：训练模式和验证模式。状态机的状态改变是通过VERIFY或VERIFY-FROM-BUFFER method来实现。验证资源的状态机的工作流程图如下：

　　3、START-SESSION method 是用来启动一个训练或验证会话。Verification-Mode header可以用来表示其启动的会话模式。这个会话类型值包括：train和verify。如果设置为验证会话的话，它会绑定声纹的数据仓库，其路径通过Repository-URI来表示。每个会话可以绑定一个或多个声纹，他们通过各自的声纹ID Voiceprint-Identifier header表示。这里需要读者注意，结合本章节前面谈到的关于验证资源和确认资源的区别，他们的使用方式在在这里得到了体现。如果是验证资源的话，指定的是一个声纹资源URL。如果是说话人确认的话，可以支持多个声纹路径，通过分号分开多个声纹资源。在训练期间的话，如果声纹不存在的话，系统会自动创建。其请求的图例如下：

　　现在，我们看一下此请求的消息流程：

　　F1 （client → speakverify）:

　　F2 （speakverify → client）:

　　END-SESSION请求支持结束训练或验证会话。在Abort-Model header创建声纹，这个声纹则反映更新状态。如果声纹更新，则可能是训练会话被激活，或者验证会话被激活，同时声纹状态信息也会更新。声纹更新是通过START-SESSION会话中设置 header Adapt-Model 为true来实现。如果Abort-Model设置为false，则会导致声纹的任何修改都最终保存到数据库中。如果此header设置为true，则会丢弃任何对声纹的修改。以下是结束会话的图例：

　　F1 （client → speakverify）:

　　F2 （speakverify → client）:

　　4、VERIFY method是验证资源对实时语音通过媒体会话进行传输，启动声纹训练，或启动验证，并且对比多组声纹数据。具体的操作模式是在START-SESSION的header Verification-Mode中设置。当VERIFY 请求完成后，验证资源会生成一个VERIFICATION-COMPLETE事件消息。NLSML数据会包含在这个事件消息中，包括训练状态和验证状态数据。以下图例是一个训练模式下的流程图：

　　F1 （client → speakverify）:

　　F2 （speakverify → client）:

　　F3 （client → speakverify）:

　　F4 （speakverify → client）:

　　F5 （speakverify → client）:

　　F6 （speakverify → client）:

　　F7 （client → speakverify）:

　　F8 （speakverify → client）:

　　5、VERIFY-FROM-BUFFER 请求的和VERIFY的工作方式相同，但是VERIFY-FROM-BUFFER的语音流源来自于验证缓冲而不是来自于实时的语音数据。验证缓冲数据写入的方式支持通过说话人验证资源写入数据，通过VERIFY请求的头中设置Ver-Buffer-Utterance为true来获得支持，也可以通过语音识别资源分配同样的SIP dialog，通过RECOGNIZE请求中设置Ver-Buffer-Utterance为true的方式写入，还可以通过录音资源分配同样的SIP dialog，通过RECORD请求中设置Ver-Buffer-Utterance为true来获得支持。这里，需要读者注意，系统不会为VERIFY-FROM-BUFFER 请求生成START-OF-INPUT事件消息。

　　使用从验证缓冲中验证说话人有几个方面的理由。语音识别资源可以用来验证其用户身份（例如通过识别客户账户），然后，紧接着此语音数据可以和其相应的声纹进行匹配。另外，如果VERIFY请求验证用户失败的话，但是MRCP客户端希望使用同样的语音数据匹配其他不同的声纹资源，这个资源可以被重复使用。这里我们假设，初始的VERIFY已传输了Ver-Buffer-Utterance为true的header，验证缓冲将被写入，START-SESSION 创建了一个新的会话支持了不同的声纹，VERIFY-FROM-BUFFER请求也已经启动。以下是一个VERIFY-FROM-BUFFER图例：

　　F1 （client → speakverify）:

　　F2 （speakverify → client）:

　　F3 （speakverify → client）:

　　6、VERIFY-ROLLBACK 请求时回滚到前面VERIFY或VERIFY-FROM-BUFFER的请求，因此，前面已处理的语音数据不再用于声纹训练（训练会话中）和声纹的调整环境中（验证会话）。如果多次发起VERIFY-ROLLBACK请求，则会导致无效回滚。以下是一个回滚请求的图例：

　　VERIFY-ROLLBACK 的消息流程：

　　F1（client→speakverify）:

　　F2（speakverify→client）:

　　START-INPUT-TIMERS请求用来支持对验证资源启动定时器。启动默认环境下，当发起一个VERIFY请求时，系统会自动启动No-Input-Timeout的定时器。如果在定时器时间范围内，验证资源没有检测到任何输入的话，VERIFY请求会结束这个请求，并且生成VERIFICATION-COMPLETE消息，消息中说明了Completion-Cause，其值为002 no-input-timeout。通常情况下，如果用户完成输入的话，MRCP 客户端会马上发起VERIFY请求。但是，在有一些应用场景中，我们需要用户输入的同时在同一时间内启动训练或验证流程。因此，它可以支持熟悉的用户可以打断输入，并且尽早启动训练或验证资源。有时，在提示回放的同时，训练/验证资源也同时启动，如果用户不想启动No-Input-Timeout 定时器，他/她需要让系统完成提示回放以后，才开始启动定时器。用户可以VERIFY消息中设置Start-Input-Timers header为false来实现以上要求。如果在稍后的处理过程中，MRCP客户端知道提示回放已经完成的话，客户端可以对验证资源发起START-INPUT-TIMERS启动No-Input-Timeout定时器。 以下是一个START-INPUT-TIMERS图例：

　　F1（client→speakverify）:

　　F2（speakverify→client）:

　　F3（client→speakverify）:

　　F4（speakverify→client）:

　　F5（speakverify→client）:

　　F6（speakverify→client）:

　　当VERIFY或VERIFY-FROM-BUFFER请求正在处理中时，MRCP客户端可以发出GET-INTERMEDIATE-RESULT请求要求获得更多累计的验证资源。这里读者要注意，GET-INTERMEDIATE-RESULT的响应消息中包含NLSML数据，因为请求仍然进行中，还没有完成，所以响应消息中没有Completion-Cause header。当验证资源在空闲状态时，MRCP客户端发送GET-INTERMEDIATE-RESULT请求时，它会收到402 Method not valid in this state 响应码。以下是GET-INTERMEDIATE-RESULT图例：

　　F1 （client → speakverify）:

　　F2 （speakverify → client）:

　　STOP method用来支持正在进行的训练验证资源，资源状态返回到空闲状态。STOP 的响应消息中会包含Active-Request-Id-List 列表，表示结束的ID。在STOP请求method中可以包含一个Abort-Verification 头，此header可以用来表示训练验证结果是否丢弃（true）或者保持（false）。 如果是false的话，STOP请求的响应消息中包含验证结果。以下是STOP 请求的图例：

　　F1 （client → speakverify）:

　　F2 （speakverify → client）:

　　F3 （client → speakverify）:

　　F4 （speakverify → client）:

　　CLEAR-BUFFER method用来清除验证缓冲数据。在前面的讨论中，我们已经介绍了如何实现缓冲数据写入。这里，使用CLEAR-BUFFER来清除缓冲数据。具体的缓冲清除图例如下：

　　F1 （client → speakverify）:

　　F2 （speakverify → client）:

　　QUERY-VOICEPRINT method用来支持MRCP客户端对验证资源进行声纹数据查询。声纹数据是通过Repository-URI和Voiceprint-Identifier 来确定。在给定的URL资源中，每个Voiceprint-Identifier 设定了一个唯一的ID。QUERY-VOICEPRINT 响应消息中会包含一个布尔值Voiceprint-Exists来表示此声纹是否存在。如果Repository-URI 不存在，则返回响应消息，并且相当Completion-Cause: 007 repository-uri-failure header。 以下是一个查询声纹资源的图例：

　　F1 （client → speakverify）:

　　F2 （speakverify → client）:

　　DELETE-VOICEPRINT method用来支持MRCP客户端删除声纹，具体的声纹身份确认由Repository-URI 和Voiceprint-Identifier构成。 这里，读者要注意，如果指定的需要删除的声纹不存在的话，不会会任何返回错误。图例是删除声纹的流程：

　　F1 （client → speakverify）:

　　F2 （speakverify → client）:

　　7、验证资源包括两个消息事件，两个事件分别是START-OF-INPUT和VERIFICATION-COMPLETE。这两个事件在前面的章节中都有完整的消息示例，读者可以参考那些示例来进一步了解这两个事件。

　　START-OF-INPUT事件是由说话人验证资源生成，通知MRCP客户端已经收到输入数据。MRCP客户端使用此事件来进行语音打断检测或者停止语音回放。

　　VERIFICATION-COMPLETE是由说话人验证资源生成来对MRCP客户端说明训练/验证流程已经完成，正在消息体中传输训练或验证结果。Completion-Cause和可选Completion-Reason header来表示训练或验证的完成状态。

　　8、MRCP协议的验证资源支持了二十个headers。现在，我们逐一介绍这些headers的使用方式。

　　9、在本讲座中，我们首先介绍了说话人验证资源的背景知识，验证资源和确认资源的区别，然后分别介绍了验证资源的请求方式，事件和所有验证资源的headers。在每个请求方式的介绍过程中，笔者结合具体的流程图和消息流程做了非常详细的解释，以及需要读者特别注意到对方。另外，对headers也做了非常详细的解释，这样可以帮助读者能够完全掌握MRCP协议中说话人验证资源的所有相关细节。

　　到目前为止，我们已经基本上介绍了整个MRCP协议的主体部分。在后续的章节中，笔者会根据时间安排等实际情况，更多讨论MRCP相关的安全方面的话题和其应用实践。

 

 

　　unimrcp-MRCP协议学习分享，QQ群号：208136295

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

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

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

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

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