MRCP协议学习笔记-录音资源的请求，事件和headers详解

在前面的两个大的章节中，我们介绍了MRCP资源类型的两个重要媒体类型：语音合成资源和语音识别资源以及它们的请求，事件和headers的详解。今天，我们将继续介绍MRCP的另外一个媒体类型-录音资源。MRCP的录音资源用来捕捉语音数据，并且以URL的形式保存，以支持同一会话后期访问。

MRCP的录音资源可以具有一些基本的语音处理能力支持语音检测。这里的语音检测功能可以支持对录音起始阶段，结束阶段的录音，甚至于中间的录音进行静音压缩处理，因此移除语音中的静音部分，从而降低录音文件存储大小。另外，如果在预设的超时设置中，没有收到任何语音，此功能可以支持录音终止执行。如果接收端在结束之前检测到一段静音状态，录音资源也要自动结束录音。录音资源的应用范围非常广泛，可以应用在语音留言服务器环境，智能客服语音导航等环境中。在本章节中，我们会详细介绍录音资源的请求，事件和headers的具体内容。

1

录音资源支持三个请求消息和两个事件信息，以及十五个headers。三个请求消息是：

两个事件消息是：

十五个headers包括：

MRCP录音资源同样也支持一个状态机。MRCP客户端发起一个请求，媒体录音资源生成事件消息。

2

RECORD 请求method 是由MRCP客户端发起，默认情况下，录音资源开始捕捉语音数据。如果当出现在Capture-On-Speech header出现在请求中，并且此值为true，当语音被检测到以后，录音资源才开始捕捉语音数据。录音格式是通过Media-Type header来设置。此header会出现在RECORD请求中。录音资源对捕捉到语音录音以后，通过Record-URI 的形式表示录音存储路径。如果此header出现没有支持设置的值，则录音资源会在RECORD-COMPLETE事件消息中返回Record-URI或在STOP请求中，携带一个URL地址。

如果在RECORD的请求中省略了Record-URI，录音资源则会在RECORD-COMPLETE事件的消息体中或者STOP响应中返回这个URL值。

MRCP要求Record-URI至少支持HTTPS来保证数据传输的安全性，MRCP同样也支持经常使用的http:// 和 file:// URI的形式。如果Record-URI是无效的地址，则会返回无效状态码“404 Illegal value for header”。如果录音资源因为各种原因不能对创建的内容链接，则返回407 Method or operation failed。

不像识别资源，请求中可以支持队列的处理。录音资源没有队列的支持。如果录音资源收到一个RECORD的请求，而录音资源正在录音状态，则返回407 Method or operation failed。以下是一个RECORD请求的流程图：

RECORD请求的消息流程：

F1 (client → recorder):

MRCP/2.0 168 RECORD 1000

Channel-Identifier: 11F018BE6@recorder

Record-URI:

Media-Type: audio/basic

Capture-On-Speech: true

Final-Silence: 2000

Max-Time: 5000

F2 (recorder → client):

MRCP/2.0 76 1000 200 IN-PROGRESS

Channel-Identifier: 11F018BE6@recorder

F3 (recorder → client):

MRCP/2.0 87 START-OF-INPUT 1000 IN-PROGRESS

Channel-Identifier: 11F018BE6@recorder

F4 (recorder → client):

MRCP/2.0 200 RECORD-COMPLETE 1000 COMPLETE

Channel-Identifier: 11F018BE6@recorder

Completion-Cause: 000 success-maxtime

Record-URI: ;

size=40000;duration=5000

3

默认环境下，启动录音以后，No-Input-Timeout header就会启动一个no-input timer 的定时器。如果在定时器超时之前没有检测到语音输入时，RECORD-COMPLETE 事件消息会返回Completion-Cause，此值为002 noinput-timeout。通常情况下，系统提示用户完成输入以后，MRCP客户端会马上发起一个RECORD 请求。对某些应用场景来说，用户输入的同时需要同时启动录音操作。录音资源可以通过二次设置来启动定时器的设置。RECORD请求中可以设置Start-Input-Timers为false来表示不启动定时器，如果需要定时器启动的话，MRCP客户端可以发起一个START-INPUT-TIMERS请求来启动定时器设置。以下是一个START-INPUT-TIMERS流程图：

消息流程如下：

F1 (client → recorder):

MRCP/2.0 219 RECORD 1500

Channel-Identifier: 11F018BE6@recorder

Record-URI:

Media-Type: audio/basic

Capture-On-Speech: true

Start-Input-Timers: false

No-Input-Timeout: 2000

Final-Silence: 2000

Max-Time: 5000

F2 (recorder → client):

MRCP/2.0 76 1500 200 IN-PROGRESS

Channel-Identifier: 11F018BE6@recorder

F3 (client → recorder):

MRCP/2.0 79 START-INPUT-TIMERS 1501

Channel-Identifier: 11F018BE6@recorder

F4 (recorder → client):

MRCP/2.0 73 1501 200 COMPLETE

Channel-Identifier: 11F018BE6@recorder

F5 (recorder → client):

MRCP/2.0 87 START-OF-INPUT 1500 IN-PROGRESS

Channel-Identifier: 11F018BE6@recorder

F6 (recorder → client):

MRCP/2.0 200 RECORD-COMPLETE 1500 COMPLETE

Channel-Identifier: 11F018BE6@recorder

Completion-Cause: 000 success-silence

Record-URI: ;

size=40000;duration=5000

4

STOP method结束录音流程，并且通知录音资源从录音状态切换到空闲状态。STOP响应消息中包含一个Active-Request-Id-List表示请求停止的ID。以下是一个停止请求的流程图：

STOP请求的消息流程：

F1 (client → recorder):

MRCP/2.0 201 RECORD 2000

Channel-Identifier: 11F018BE6@recorder

Record-URI: file://recorder/audio/file04.wav

Media-Type: audio/x-wav

Capture-On-Speech: true

Final-Silence: 2000

Max-Time: 5000

F2 (recorder → client):

MRCP/2.0 76 2000 200 IN-PROGRESS

Channel-Identifier: 11F018BE6@recorder

F3 (recorder → client):

MRCP/2.0 87 START-OF-INPUT 2000 IN-PROGRESS

Channel-Identifier: 11F018BE6@recorder

F4 (client → recorder):

MRCP/2.0 65 STOP 2001

Channel-Identifier: 11F018BE6@recorder

F5 (recorder → client):

MRCP/2.0 179 2001 200 COMPLETE

Channel-Identifier: 11F018BE6@recorder

Active-Request-Id-List: 2000

Record-URI: ;

size=16000;duration=2000

5

MRCP录音资源支持两个事件消息，它们分别是START-OF-INPUT和RECORD-COMPLETE消息。

当录音资源第一次检测到语音时，录音资源会生成START-OF-INPUT事件消息。MRCP客户端可以使用事件消息来结束语音回放等流程。例如，在语音合成资源中的BARGE-IN-OCCURRED消息激活打断流程。

当录音资源完成对RECORD请求流程后，录音资源生成并返回RECORD-COMPLETE消息事件，并且录音资源从录音资源切换到空闲状态。录音资源会自动结束录音流程，结束的原因会返回到MRCP客户端。具体结束原因可能是：no-input timeout，maximum time expired，final silence detected等。Completion-Cause header表示了RECORD 请求结束的原因。如果录音结束后，请求没有携带任何错误的话，RECORD-COMPLETE消息则会表示一个录音文件的URL地址。

6

录音资源支持了十五个headers。我们逐一介绍这些headers的使用方式。

Completion-Cause，此header总是出现在RECORD-COMPLETE事件中，用来表示RECORD结束原因。如果出现错误的话，它也可能出现在RECORD请求的返回响应消息中。示例：Completion-Cause: 002 noinput-timeout。

Completion-Reason，此header可选出现在RECORD-COMPLETE事件消息中，提供更多结束原因代码。示例：Completion-Reason: Out of disk space。为客户端通过日志跟踪信息：

Failed-URI，此header 表示访问所给URL失败。示例：Failed-URI: http://192.168.1.10/audio/mailbox01.wav。

Failed-URI-Cause，此header表示访问URL失败的具体原因，示例：Failed-URI-Cause: 404 Not Found。

Record-URI，表示录音的存储URL路径。示例：Record-URI: ; size=40000;duration=5000。

Media-Type，此header表示录音文件格式。示例：Media-Type: audio/x-wav。

Capture-On-Speech，此header是一个布尔值，表示是否当检测到语音时开始录音。默认值是false，表示接收方收到录音请求后马上开始录音。示例：Capture-On-Speech: true。

No-Input-Timeout，此header表示当录音开始时，在设定的时间内没有检测到语音。在返回RECORD-COMPLETE 事件消息中携带Completion-Cause，其值为002 noinput-timeout。示例为：No-Input-Timeout: 3000。

Max-Time，其header用来设定最大录音时间，此时间从开始录音计算，不包括其中的静音压缩时段。其值以毫秒为单位。当录音时长达到最大录音时间时，录音会结束，录音资源会生成并且返回RECORD-COMPLETE事件，携带Completion-Cause， 值为000 success-silence。示例：Max-Time: 10000。

Final-Silence，此header设定一个静音时长（毫秒为单位），用来表示录音结束前的静音时长。如果此值为0，表示无穷大，无最后静音检测。示例：Final-Silence: 3500。

Sensitivity-Level，此header表示一个语音检测的敏感度。取值范围从0到1。取值比较低表示对噪音不敏感；取值比较高表示输入时静音比较敏感。示例：Sensitivity-Level: 0.85。

Trim-Length，此header使用在STOP 请求中。其值表示从录音结束起，所移除的时间长度。默认值为0。示例：Trim-Length: 1000。

Start-Input-Timers，此header 在RECORD请求中设定一个延迟启用no-input timer的时间，直到MRCP客户端重新发送START-INPUT-TIMERS请求。示例：Start-Input-Timers: false。

Ver-Buffer-Utterance，此header使用在RECORD 请求中，表示录音文件使用在后续的说话人验证流程中，这里，假设说话让验证资源被分配在同一会话中。默认值为false。示例：Ver-Buffer-Utterance: true。

New-Audio-Channel，如果此header在录音请求中设置为true，则表示语音数据正在从不同的语音资源，通道或讲话人发送。如果此header出现的话，并且设置为true，则表示正在调整某些算法。这些算法可能已经在语音检测中使用，为了适应新的语音资源，一些算法需要调整。示例：New-Audio-Channel: false。

7

这里，我们稍微花一点时间再多讨论一下关于静音检测到问题。首先说明，笔者不是语音检测算法方面的专家，因为我们在VOIP领域一直涉及相关的技术话题，所以这里提醒用户，对于录音资源的VAD检测也是非常重要的一环。静音检测在终端设计中结合厂家的技术特点都有各自的算法，具体的应用场景很多，包括检测语音挂机，降低录音文件大小，优化网络带宽都具有非常重要的作用。关于在SIP环境中的VAD检测，笔者在以前的SIP讲座中做过非常深入的讨论。这里，我们仅对录音资源中的静音处理做一些简单提示。因为在录音环境中，如果没有对录音进行静音检测处理或者优化，它会导致录音文件非常庞大，严重影响系统存储性能，同时也会影响语音识别的准确性。当然，如果开启VAD检测到话，同时也会增加系统的负载。具体的VAD设计流程如下：

更多关于VAD的算法，读者可以结合笔者给出的参考资料做进一步的研究，也可以针对录音资源的几个header做适当的调整来优化录音文件。读者也可以参考PSJIP或FreeSWITCH的VAD模块做更多了解。另外，如果读者想进一步了解VAD的话，读者也需要结合静音压缩的算法，舒适噪音生成来进一步了解这几个算法的相互关系。

8

在本章节的分享中，笔者详细介绍了MRCP中的录音资源的细节内容，包括请求，事件消息和headers的完整介绍。并且，对录音优化过程中的VAD做了简单分享，希望读者在优化录音文件时更多注意这些参数。

参考资料：

Tom Bäckström，Voice Activity DetectionSpeech Processing

E. Verteletskaya, K. Sakhnov， Voice Activity Detection for Speech Enhancement Applications

Md Sahidullah，Comparison of Speech Activity DetectionTechniques for Speaker Recognition

J. Ramírez, J. M. Górriz，Voice Activity Detection. Fundamentals andSpeech Recognition System Robustness

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