智能语音对话作为人工智能领域最先落地的分支之一，可以实现与人进行自然语言多轮对话，其核心技术在近年来不断地发展成熟，包括语音识别、自然语言理解、对话管理等。伴随着技术的成熟，越来越多的电话机器人开始走进我们的生活，这些电话机器人在客户服务、智能销售、通知触达等场景发挥着重要的作用。
当你和智能语音机器人对话交互时，你是否好奇电话背后的机器人如何“听懂”你的意思，又如何像人一样“回答”你的问题？经典的技术实现路径是：机器人首先通过“语音识别（ASR）”将用户输入语音识别成文字，再通过“自然语言理解（NLU）”识别意图，之后根据意图、系统信号等输入结合对话管理技术得到相应的回复，最后通过“语音合成（TTS）”生成语音播报给电话对端的用户。但要将 ASR、TTS 这些技术应用到电话系统上，还需要一些额外的工作和技术支撑，其中比较重要的技术之一也就是本文将要介绍的 MRCP。
备注：本文涉及较多的专业名词，我们特别在文末附上了名词解释，以帮助大家进行阅读。
MRCP（Media Resource Control Protocol, MRCP）是一种通讯协议，中文定义是：媒体资源控制协议，用于语音服务器向客户端提供各种语音服务（如语音识别和语音合成）。该协议定义了控制媒体处理资源所必需的请求（Request）、应答（Response）和事件（Event）等消息，它需要借助 RTP（Real-Time Transport Protocol, 实时传输协议）创建一个媒体会话、借助 SIP（Session Initiation Protocol, 会话初始化协议） 和 SDP（Session Description Protocol, 会话描述协议） 创建一个控制会话来实现媒体资源服务器端和客户端之间的控制[1]。
在传统的语音应用中，各集成商必须针对不同的 ASR/TTS 厂商提供的 API 接口进行专门的集成开发，不同 ASR/TTS 引擎的接口各不相同，从而导致了集成过程的复杂性和局限性。因此，在实现语音和网络技术集成方面必须需要比较规范的协议来进行处理。MRCP 协议是目前针对媒体资源和 IP 网络起草的标准协议。有了 MRCP 协议后，ASR/TTS 厂商提供 MRCP 协议的标准统一接口，语音集成开发商们不必再针对特定的 ASR/TTS 进行开发，为各种语音应用开发提供了更加灵活的选择，并有效地降低业务开发周期和成本[2]。
以语音合成（TTS）为例，图 1 展示了一个 MRCP 客户端连接媒体资源服务器的流程，在连接中会创建一个媒体会话和一个控制会话。假设连接成功，此时 MRCP 客户端对服务器端发起了一个 SPEAK 语音合成的请求，处理此请求的过程中包括了3个消息指令：SPEAK指令表示发送语音合成请求，IN-POGRESS指令表示正在处理中，SPEAK—COMPLETE指令表示处理完成[3]。
图1 MRCP 协议交互
MRCP 协议的消息格式和 HTTP 消息格式类似，如下以一次语音合成的 MRCP 消息为例，展示了 MRCP 消息的主要构成。
发起语音合成请求：
MRCP/2.0 380 SPEAK 14321
Channel-Identifier: 43b9ae17@speechsynth
Content-Type: application/ssml+xml
Content-Length: 253
您好，有什么能帮助您？
IN-PROGRESS 响应消息：
MRCP/2.0 119 14321 200 IN-PROGRESS
#消息长度是119 bytes,ID是14321，200 表示成功，正在处理中
Channel-Identifier: 43b9ae17@speechsynth
Speech-Marker: timestamp=857206027059
COMPLETE 响应消息：
MRCP/2.0 157 SPEAK-COMPLETE 14321 COMPLETE
Channel-Identifier: 43b9ae17@speechsynth
Speech-Marker: timestamp=861500994355
#表示SPEAK请求的正常处理结束
Completion-Cause: 000 normal
目前，语音行业几乎所有的重要厂商都承诺支持 MRCP。MRCP 使用场景丰富，它支持目前最热门的开源语音通信平台 Asterisk 和 FreeSWITCH ，并且提供了丰富的接口文档，其中呼叫中心就是一个典型的案例。一个简单的呼叫中心如下图 2 所示：
图2 简单呼叫中心系统示意
在此场景中可以看到，采用 MRCP 协议，调用方仅需要面向 MRCP 接口撰写程序，而无需考虑不同语音引擎产品之间的差异，可以真正做到一次开发、多种环境下应用，任何支持 MRCP 标准的语音引擎都可以被无缝集成和调用。
自 2018 年起至今，美团语音交互部持续投入语音识别（ASR）和语音合成（TTS）的自主研发，目前已形成平台级的服务能力。美团语音识别重点针对美团场景进行优化，相比通用场景的识别率更高；参考 2022 年的数据，在电话呼叫场景的测试集中，美团语音识别的字准率达到 94.6%（很多业界头部厂商的字准率在 89% 左右）。在骑手语音助理、客服中心语音转译、美团 App / 外卖 App语音助理等典型业务场景中进行了落地和应用。
美团语音合成从美团各场景出发，建立起从端到云一体化，全面覆盖客服、配送、听书等各个方向的合成音色群，并支持不同数据量级的语音定制化能力，做到了通用场景好、特色场景精、定制周期短。其中现有声音的客服场景效果已领先于行业，具有小样本声音克隆、强表现力的配音能力，在性能和效果层面达到了业界一流水准；同时，美团语音合成在美团外卖配送、美团商家端、美团打车、美团客服等核心业务场景落地，支持日均亿级别的调用。
随着美团自研的 ASR/TTS 逐步达到业界一流水平，美团内部越来越多业务接入美团自研的 TTS 和 ASR 能力。特别是 TTS，在应用的业务场景中取得超过外采系统捷通华声的效果，但在业务对接和优化过程中，也存在一些问题，可以概括为音色机械、音色不统一、合成延时过高等。
这几类问题，主要是在业务升级替换音色过程中，采取了将业务系统（如外呼系统）与语音的合成和识别能力的 HTTP/RPC 接口直接对接的方式，这种方式不仅投入大，需要逐个业务系统、逐个流程的对接，也容易因为系统复杂性、运营疏漏等问题出现音色不统一等体验问题。因此，按行业通用标准，以 MRCP 将语音合成和识别与电话系统直接对接的方式，可以有效地降低业务使用、升级语音能力的成本，平滑地提升用户体验。
音色不统一示例：对话流程中，一部分固定的话术文本使用的提前合成好的音频文件，另一部分动态的话术文本（如，录音中“请问你是某某店吗”）采用的实时合成的音频，两部分拼接在一起播放，音色不统一。
延时过高：部分业务对于动态话术文本，特别是本身句子较长的话术，待一整句合成完成后再播放到用户，给用户带来严重的迟滞感。
另一方面，越来越多美团外部企业如中通天鸿、微呼科技、马上消费金融等，认可并计划接入美团语音自研的 TTS 和 ASR 能力；预期以标准的 MRCP 协议完成对接，在客户服务、通知触达、电话提示语音识别等场景，提升其呼叫中心的基础用户体验。
如下图 3 所示，美团的小美机器人平台、木星通讯平台分别提供不同类型的语音对话机器人能力。以语音合成（TTS）为例，这些机器人平台直接调用 TTS 引擎的服务接口，将合成好的语音文件交由电话软交换平台（如FreeSWITCH）去播报，如链路 ① 所示。
我们的目标是将这种调用关系简化，以标准 MRCP 下的语音合成服务对接电话软交换平台，那么上述机器人平台则只用核心关注机器人的对话逻辑，将具体的语音合成逻辑解耦出来，那么链路 ② 所传递的内容即为机器人待播报的话术文本，由电话软交换平台去调用和处理语音合成。
图3 语音能力与业务系统对接方式比较
总而言之，目标结合自研流式 TTS 和 ASR 能力，建设 MRCP 协议下标准的语音合成和识别服务，达到：
在系统层次上，围绕联络场景，美团语音交互部正在建设全联络场景智能化的平台化解决方案。具体来说，美团智能对话平台 AICC（AI for Contact Center），基于美团语音交互部领先的语音识别、自然语言理解、多轮对话、知识图谱等人工智能技术，为美团业务提供智能文字客服（在线客服）、智能语音客服（热线客服）、智能外呼、智能营销、智能质检等完整解决方案；帮助业务从传统服务模式向智能服务模式转型，助力美团业务的服务成本优化、客户服务体验提升，实现客户服务及营销智能化升级。
AICC 的层次架构如下图 4 所示，从整个 AICC 架构来看，TTS 和 ASR 处于语音技术平台，提供语音合成和识别的 PaaS 级能力；相应地，MRCP-TTS、MRCP-ASR扩充已有的 HTTP/RPC 接口的能力范围。
图4 MRCP在AICC层次架构中的位置关系
以热线电话机器人的系统调用过程为例，MRCP 在系统中所处的位置以及同其他各环节的配合关系如下图 5 所示：
图5 MRCP服务调用关系
要实现一个工业可用的 MRCP Server，有两个关键技术能力：一是 MRCP 协议本身的支持，二是 MRCP Server 的高可用，如多节点的负载均衡。
对于 MRCP 协议的实现，不仅仅需要支持 MRCP 协议本身，也需要支持一套完整的协议栈，包括文章开头部分提到的 SIP、RTP 协议等，这是一个复杂且庞大的工作。
参考业界的一般做法，我们选择基于开源的 UniMRCP 完成这些工作。UniMRCP 是一个开源的、跨平台的 MRCP 协议实现，由 C/C++ 语言编写，包括了 MRCP 客户端和服务端两个部分，它封装了 SIP、SDP、MRCPv1、MRCPv2、RTP/RTCP 协议栈，并为语音服务集成商提供了一致的 API[4]。
UniMRCP 完成了 MRCP 协议栈的封装，并没有实现 ASR 或 TTS ；基于其对底层协议栈的完整支持，我们在 UniMRCP的框架下实现相应的 Recog（ASR）和 Synth（TTS）插件（即 MRCP-TTS Plugin，MRCP-ASR Plugin），并改造适配美团日志框架、监控打点等基础技术组件，从而保障服务的稳定性和可维护性。
对于实现 MRCP-Server 的负载均衡，我们选用开源的 Kamailio 来完成。Kamailio 的前身叫 Openser，作为出色的 SIP proxy，在大并发量使用时常常用于负载均衡媒体服务器，对 Asterisk、FreeSWITCH、MRCP 等实现集群能力[5]。Kamailio 经常与 FreeSWITCH 配合使用，最常用的场景是 Kamailio 作呼叫负载均衡服务器（一般主备配置），FreeSWITCH做媒体相关的处理如转码、放音、录音、呼叫排队等。
由于 UniMRCP 提供的基础框架已经实现了服务接口、连接管理、协议管理，如何加载自定义插件，以及系统层的日志框架；并且 TTS 引擎与 ASR 引擎作为基础的依赖，已以 HTTP/RPC 协议的方式提供稳定的基础语音服务。因此，开发工作是在 UniMRCP 的基础上进行 TTS/ASR 插件的开发，模块结构如下图 6 所示，主要新增的模块已在图中标灰，其中：
图6 MRCP服务模块结构
在语音交互场景中，用户可以连续不间断的“说话”并听到“回应”，是保证本次交互顺利完成的重要基础。因此，高可用是 MRCP-Server 在部署方案设计中核心关注和考虑的维度，部分节点故障不影响整体的可用性，并可以快速摘除、恢复、替换故障节点。其中，关键的措施包括：
对应地，整体部署如图7所示，在美团通过这种部署方式为业务提供稳定可用的服务。
图7 MRCP整体系统部署方案
目前 MRCP 已经在美团内外呼热线电话下的多个业务场景中广泛应用：
在外部商业化落地过程中，客户一般要求将 MRCP-Server 私有化部署到客户机房，服务的运维工作由客户自行保证；MRCP-Server 本身在 8C16G 容器中测试，可承载约 600 路并发访问。目前已支持的美团外部客户包括：
MRCP 将语音合成和识别能力接口标准化以后，在美团对接了外采的 Genesys 电话系统（主要支持内呼电话），以及自研的木星通讯系统（主要支持外呼电话），也在支持语音合成和识别能力商业化的过程中对接了中通天鸿、微呼科技等外部公司的电话系统。在这些业务对接和支持的过程中，一次开发多处复用，相较于早期的对接方式，极大提高了业务支持的效率。
此外，对于使用 MRCP-TTS 的业务，在语音合成的性能有明显提升，具体体现在：首包延时显著降低，且与待合成的话术文本句长无关。此前，使用 HTTP 接口进行整句合成播报，以大约 6~8 字每秒的合成速度、需要整句完成后用户才能听到声音。目前，MRCP-TTS 支持一边合成一边为用户播报语音。
从线上观测来看，内呼机器人的端到端延时降低了约 55%，外呼机器人的端到端延时降低了约 33%，并且做到了音色统一、无变量导致的音色跳跃问题。从业务使用 MRCP-TTS 前后的业务指标对比来看，有较为显著的效果：
在业务支持中，我们结合 MRCP 提供了多种音色，音色更加丰富真实，尽可能满足各个业务场景。
MRCP 协议及相关技术已经相对成熟，围绕技术本身而言的迭代和演进相对较少。未来，除了语音合成（TTS）和语音识别 (ASR) 外，语音交互部自研的声纹识别（VPR）技术也逐步成熟；其中，娇喘识别效果大幅提升、目前性能已超过头部厂商服务，年龄识别误差小于7.5岁（公开测试集评测）。预计结合 MRCP 在电话智能等场景提供相应技术能力，支持优化和提升业务流程及效果（如金服生意贷场景，通过声纹识别判断是否为虚假申贷人，减少恶意申贷造成的损失）。
从技术运用上看，一方面 MRCP 协议下的 TTS、ASR 为美团智能外呼机器人、智能呼入机器人等多个业务场景提供稳定的服务，并带来可观的业务效果提升；我们预期将其接入更多的业务场景，以客户为中心、给每一个用户带来流畅丝滑的人机对话体验，助力业务优化。另一方面，在标准化的 MRCP 协议接口的承载下，持续推进美团 TTS 和 ASR 能力的商业化。
唐锐、森彬、子丰、亚男、王程、国桥、俞涛等，均来自美团平台/语音交互部。
关注微信
