MRCP在美團語音互動中的實踐和應用

當你和智慧語音機器人對話互動時，你是否好奇電話背後的機器人如何“聽懂”你的意思，又如何像人一樣“回答”你的問題？其中比較重要的技術就是 MRCP。本文主要介紹了 MRCP 在美團語音互動中的實踐和應用，基於美團自研的語音識別及語音合成能力，我們提升了外呼通話的成功率，並且保證了更好的使用者體驗。

一、背景

智慧語音對話作為人工智慧領域最先落地的分支之一，可以實現與人進行自然語言多輪對話，其核心技術在近年來不斷地發展成熟，包括語音識別、自然語言理解、對話管理等。伴隨著技術的成熟，越來越多的電話機器人開始走進我們的生活，這些電話機器人在客戶服務、智慧銷售、通知觸達等場景發揮著重要的作用。

當你和智慧語音機器人對話互動時，你是否好奇電話背後的機器人如何“聽懂”你的意思，又如何像人一樣“回答”你的問題？經典的技術實現路徑是：機器人首先透過“語音識別（ASR）”將使用者輸入語音識別成文字，再透過“自然語言理解（NLU）”識別意圖，之後根據意圖、系統訊號等輸入結合對話管理技術得到相應的回覆，最後透過“語音合成（TTS）”生成語音播報給電話對端的使用者。但要將 ASR、TTS 這些技術應用到電話系統上，還需要一些額外的工作和技術支撐，其中比較重要的技術之一也就是本文將要介紹的 MRCP。

備註：本文涉及較多的專業名詞，我們特別在文末附上了名詞解釋，以幫助大家進行閱讀。

1.1 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]。

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 

1.2 MRCP 使用場景

目前，語音行業幾乎所有的重要廠商都承諾支援 MRCP。MRCP 使用場景豐富，它支援目前最熱門的開源語音通訊平臺 Asterisk 和 FreeSWITCH ，並且提供了豐富的介面文件，其中呼叫中心就是一個典型的案例。一個簡單的呼叫中心如下圖 2 所示：

1. 當分機撥打外呼使用者時，需要從運營商那裡獲得一條電話通訊線路，FreeSWITCH 指定路由透過閘道器到達運營商線路，透過運營商基礎網路、連線使用者通訊裝置終端。
2. 智慧語音服務透過 MRCP 協議與 FreeSWITCH 進行對接，使用者接通電話後，智慧語音服務從呼叫中心裝置中實時獲取聲音訊號，將語音訊號轉化為文字流實時輸出，並將要回復的文字話術經過語音合成轉化為語音訊號，交由呼叫中心進行語音播報。

在此場景中可以看到，採用 MRCP 協議，呼叫方僅需要面向 MRCP 介面撰寫程式，而無需考慮不同語音引擎產品之間的差異，可以真正做到一次開發、多種環境下應用，任何支援 MRCP 標準的語音引擎都可以被無縫整合和呼叫。

1.3 美團自研的 ASR/TTS 能力

自 2018 年起至今，美團語音互動部持續投入語音識別（ASR）和語音合成（TTS）的自主研發，目前已形成平臺級的服務能力。美團語音識別重點針對美團場景進行最佳化，相比通用場景的識別率更高；參考 2022 年的資料，在電話呼叫場景的測試集中，美團語音識別的字準率達到 94.6%（很多業界頭部廠商的字準率在 89% 左右）。在騎手語音助理、客服中心語音轉譯、美團 App / 外賣 App語音助理等典型業務場景中進行了落地和應用。

美團語音合成從美團各場景出發，建立起從端到雲一體化，全面覆蓋客服、配送、聽書等各個方向的合成音色群，並支援不同資料量級的語音定製化能力，做到了通用場景好、特色場景精、定製週期短。其中現有聲音的客服場景效果已領先於行業，具有小樣本聲音克隆、強表現力的配音能力，在效能和效果層面達到了業界一流水準；同時，美團語音合成在美團外賣配送、美團商家端、美團叫車、美團客服等核心業務場景落地，支援日均億級別的呼叫。

1.4 我們為什麼需要 MRCP

1.4.1 賦能內部業務

隨著美團自研的 ASR/TTS 逐步達到業界一流水平，美團內部越來越多業務接入美團自研的 TTS 和 ASR 能力。特別是 TTS，在應用的業務場景中取得超過外採系統捷通華聲的效果，但在業務對接和最佳化過程中，也存在一些問題，可以概括為音色機械、音色不統一、合成延時過高等。

這幾類問題，主要是在業務升級替換音色過程中，採取了將業務系統（如外呼系統）與語音的合成和識別能力的 HTTP/RPC 介面直接對接的方式，這種方式不僅投入大，需要逐個業務系統、逐個流程的對接，也容易因為系統複雜性、運營疏漏等問題出現音色不統一等體驗問題。因此，按行業通用標準，以 MRCP 將語音合成和識別與電話系統直接對接的方式，可以有效地降低業務使用、升級語音能力的成本，平滑地提升使用者體驗。

音色不統一示例：對話流程中，一部分固定的話術文字使用的提前合成好的音訊檔案，另一部分動態的話術文字（如，錄音中“請問你是某某店嗎”）採用的實時合成的音訊，兩部分拼接在一起播放，音色不統一。

延時過高：部分業務對於動態話術文字，特別是本身句子較長的話術，待一整句合成完成後再播放到使用者，給使用者帶來嚴重的遲滯感。

1.4.2 支撐對外商業化

另一方面，越來越多美團外部企業如中通天鴻、微呼科技、馬上消費金融等，認可並計劃接入美團語音自研的 TTS 和 ASR 能力；預期以標準的 MRCP 協議完成對接，在客戶服務、通知觸達、電話提示語音識別等場景，提升其呼叫中心的基礎使用者體驗。

二、設計與實現

2.1 設計目標

如下圖 3 所示，美團的小美機器人平臺、木星通訊平臺分別提供不同型別的語音對話機器人能力。以語音合成（TTS）為例，這些機器人平臺直接呼叫 TTS 引擎的服務介面，將合成好的語音檔案交由電話軟交換平臺（如FreeSWITCH）去播報，如鏈路 ① 所示。

我們的目標是將這種呼叫關係簡化，以標準 MRCP 下的語音合成服務對接電話軟交換平臺，那麼上述機器人平臺則只用核心關注機器人的對話邏輯，將具體的語音合成邏輯解耦出來，那麼鏈路 ② 所傳遞的內容即為機器人待播報的話術文字，由電話軟交換平臺去呼叫和處理語音合成。

總而言之，目標結合自研流式 TTS 和 ASR 能力，建設 MRCP 協議下標準的語音合成和識別服務，達到：

• 支援標準協議下的 TTS 和 ASR 能力對接方式，追齊業界主流廠商能力。
• 以橫向可擴充套件、業務解耦的方式，支援和助力美團內部業務，在智慧外呼、內呼熱線等場景下提升使用者體驗；併為美團語音能力的對外商業化探索，提供更好的支撐。

2.2 總體系統架構

2.2.1 系統層次架構

在系統層次上，圍繞聯絡場景，美團語音互動部正在建設全聯絡場景智慧化的平臺化解決方案。具體來說，美團智慧對話平臺 AICC（AI for Contact Center），基於美團語音互動部領先的語音識別、自然語言理解、多輪對話、知識圖譜等人工智慧技術，為美團業務提供智慧文字客服（線上客服）、智慧語音客服（熱線客服）、智慧外呼、智慧營銷、智慧質檢等完整解決方案；幫助業務從傳統服務模式向智慧服務模式轉型，助力美團業務的服務成本最佳化、客戶服務體驗提升，實現客戶服務及營銷智慧化升級。

AICC 的層次架構如下圖 4 所示，從整個 AICC 架構來看，TTS 和 ASR 處於語音技術平臺，提供語音合成和識別的 PaaS 級能力；相應地，MRCP-TTS、MRCP-ASR擴充已有的 HTTP/RPC 介面的能力範圍。

2.2.2 系統間呼叫關係

以熱線電話機器人的系統呼叫過程為例，MRCP 在系統中所處的位置以及同其他各環節的配合關係如下圖 5 所示：

1. FreeSWITCH 電話軟交換平臺，負責和運營商打通通訊線路，以具備基礎的電話通訊能力。
2. FreeSWITCH 除了以內建模組（如 mod_java）的方式開發控制介面外，也以 ESL（Event Socket Library）的 Inbound/Outbound 方式開放介面，提供事件監聽、通話控制等能力。
3. ESL Server 將監聽到的事件、訊息傳遞給具體的業務邏輯，可以提供通訊層所有的事件供監聽和處理，籍此實現機器人的語音對話互動能力。
4. 將調語音相關的事件和訊號處理解耦以後來看，熱線、線上機器人的互動邏輯則可以簡化、抽象為統一的模型和系統。
5. 管理配置臺主要負責一般對話機器人所需要的意圖、槽位的定義、管理和配置任務型對話流程。
6. 配置管理也可對 ASR、TTS 引擎需要的領域知識進行管理，比如客服領域的詞庫、樣本資料集的持續標註等。
7. 本文所述的MRCP在系統呼叫中處於此位置：在FreeSWITCH 收到合成/識別請求後，發起與 MRCP-Server 的互動，MRCP-Server 呼叫內部實現的 MRCP-TTS Plugin 與 MRCP-ASR Plugin 分別完成相應的合成或識別結果。
8. ASR Engine 和 TTS Engine 指美團語音自研的語音合成和語音識別引擎，MRCP 透過 HTTP/RPC 介面與之完成通訊。

2.3 關鍵技術元件

要實現一個工業可用的 MRCP Server，有兩個關鍵技術能力：一是 MRCP 協議本身的支援，二是 MRCP Server 的高可用，如多節點的負載均衡。

2.3.1 MRCP 協議實現

對於 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），並改造適配美團日誌框架、監控打點等基礎技術元件，從而保障服務的穩定性和可維護性。

2.3.2 MRCP Server 負載均衡

對於實現 MRCP-Server 的負載均衡，我們選用開源的 Kamailio 來完成。Kamailio 的前身叫 Openser，作為出色的 SIP proxy，在大併發量使用時常常用於負載均衡媒體伺服器，對 Asterisk、FreeSWITCH、MRCP 等實現叢集能力^[5]。Kamailio 經常與 FreeSWITCH 配合使用，最常用的場景是 Kamailio 作呼叫負載均衡伺服器（一般主備配置），FreeSWITCH做媒體相關的處理如轉碼、放音、錄音、呼叫排隊等。

2.4 MRCP-Server 模組結構

由於 UniMRCP 提供的基礎框架已經實現了服務介面、連線管理、協議管理，如何載入自定義外掛，以及系統層的日誌框架；並且 TTS 引擎與 ASR 引擎作為基礎的依賴，已以 HTTP/RPC 協議的方式提供穩定的基礎語音服務。因此，開發工作是在 UniMRCP 的基礎上進行 TTS/ASR 外掛的開發，模組結構如下圖 6 所示，主要新增的模組已在圖中標灰，其中：

• MRCP-TTS Plugin 和 MRCP-ASR Plugin 兩個為核心的模組，以外掛的形式載入到 MRCP-Server。

• MRCP-TTS Plugin 和 MRCP-ASR Plugin 抽象出公共的模組：

  • 事件/介面管理：訂閱和註冊 MRCP-Server 收到事件和訊息，如通道建立事件、請求訊息等等。
  • 會話管理：管理會話的建立、開啟、關閉、銷燬過程。
  • 執行緒池管理：管理呼叫 TTS 和 ASR 引擎服務介面所需的任務執行緒池。
  • 配置管理：讀取配置檔案對各自 Plugin 定義的配置項。
  • 語音資料處理：包括語音資料緩衝、時長計算等。
  • 服務註冊：負責將服務註冊到 OCTO，支援 MRCP 服務例項啟用、摘除的自動發現。
• 應用日誌模組，將外掛這一層的日誌與美團的日誌框架打通，將應用日誌接入美團日誌中心。
• 監控打點模組，將合成首包延時、狀態事件等支援，接入美團 Raptor 監控平臺。
• 鑑權模組，使用美團語音開放平臺的統一認證服務，完成呼叫 TTS 和 ASR 引擎前的鑑權過程。

2.5 部署方案

在語音互動場景中，使用者可以連續不間斷的“說話”並聽到“回應”，是保證本次互動順利完成的重要基礎。因此，高可用是 MRCP-Server 在部署方案設計中核心關注和考慮的維度，部分節點故障不影響整體的可用性，並可以快速摘除、恢復、替換故障節點。其中，關鍵的措施包括：

• 統一的服務入口：使用美團 MGW（美團內部自研的四層負載均衡閘道器） 建立固定的虛擬 IP (VIP)，提供唯一的服務訪問入口。
• 資源隔離：為了減少語音合成和語音識別服務彼此間的影響，我們將 MRCP Server 拆分成兩個服務，即 MRCP-TTS 和 MRCP-ASR，對二者進行隔離部署。
• 跨地域、多機房部署：將 MRCP-TTS 和 MRCP-ASR 服務部署在多個機房，並且跨地域部署，以提高服務穩定性。
• Kamailio 熱備：為了防止 Kamailio 出現故障以影響整個鏈路，我們對 Kamailio 也採用了跨地域、多機房的部署，並且由 MGW 完成對 Kamailio 的多機熱備。
• 負載均衡：顯而易見地，需要對 MRCP-TTS 和 MRCP-ASR 進行負載均衡。如何進行負載均衡？起初我們打算直接使用 MGW 對 MRCP-TTS 進行負載均衡，MGW 是支援到傳輸層的四層負載均衡，可以路由分發到具體的服務。在我們場景中所使用的 SIP、MRCP 均屬於應用層的協議，資料傳輸基於 TCP/UDP，理論上四層負載均衡能夠滿足需要。但實際協議互動過程中，支援七層負載均衡的 Kamailio 能夠在 SIP 協議經過的路由點時，在協議頭中加入 <Via address> 和 <Contact address> 等欄位，層層路由能夠始終保持與同一臺機器進行互動。比如，客戶端透過 SIP-INVITE 經由 Kamalio 與 MRCP服務完成握手後，結束服務、客戶端傳送 SIP-BYE 訊息時，Kamailio 可以準確路由到當時接受 INVITE 訊息的同一個 MRCP 服務。因此，最終使用 Kamailio 完成對 MRCP-TTS 和 MRCP-ASR 的負載均衡。

對應地，整體部署如圖7所示，在美團透過這種部署方式為業務提供穩定可用的服務。

三、實踐與應用效果

3.1 應用範圍

3.1.1 美團內部業務賦能

目前 MRCP 已經在美團內外呼熱線電話下的多個業務場景中廣泛應用：

• 美團外呼業務語音合成：結合小美智慧外呼與木星自動外呼，在美團內部的太平洋客服坐席輔助外呼、營銷類外呼、通知觸達類外呼等場景，逐步接入 MRCP 協議下的流式語音合成。目前已接入 MRCP 的外呼機器人日均百萬次合成呼叫，峰值約千路併發。
• 美團內呼業務語音合成：內呼主要是支援美團呼入熱線的語音合成，包括：10107888-美團客服熱線、10109777-外賣客服熱線、10105777-美團商服熱線、10101777-美團騎手熱線以及其他長尾業務熱線。目前已接入 MRCP 的熱線呼入機器人日均近千萬次合成呼叫量，峰值千餘路併發。

3.1.2 外部商業化應用

在外部商業化落地過程中，客戶一般要求將 MRCP-Server 私有化部署到客戶機房，服務的運維工作由客戶自行保證；MRCP-Server 本身在 8C16G 容器中測試，可承載約 600 路併發訪問。目前已支援的美團外部客戶包括：

1. 微呼科技，接入了美團提供的 MRCP 語音合成和識別服務，在通知觸達等場景使用美團語音提供的流式語音合成能力，在“空號”、“忙音”、“助手秘書提示”等場景使用美團提供的語音識別能力。
2. 中通天鴻，接入了美團提供的 MRCP 語音合成服務，支援其外呼機器人等業務下的客戶選擇美團語音提供的多種場景化音色。

3.2 應用效果

MRCP 將語音合成和識別能力介面標準化以後，在美團對接了外採的 Genesys 電話系統（主要支援內呼電話），以及自研的木星通訊系統（主要支援外呼電話），也在支援語音合成和識別能力商業化的過程中對接了中通天鴻、微呼科技等外部公司的電話系統。在這些業務對接和支援的過程中，一次開發多處複用，相較於早期的對接方式，極大提高了業務支援的效率。

此外，對於使用 MRCP-TTS 的業務，在語音合成的效能有明顯提升，具體體現在：首包延時顯著降低，且與待合成的話術文字句長無關。此前，使用 HTTP 介面進行整句合成播報，以大約 6~8 字每秒的合成速度、需要整句完成後使用者才能聽到聲音。目前，MRCP-TTS 支援一邊合成一邊為使用者播報語音。

從線上觀測來看，內呼機器人的端到端延時降低了約 55%，外呼機器人的端到端延時降低了約 33%，並且做到了音色統一、無變數導致的音色跳躍問題。從業務使用 MRCP-TTS 前後的業務指標對比來看，有較為顯著的效果：

• 在美團電話熱線的呼入場景，使用 MRCP-TTS 升級原來的語音播報服務後，不滿意度下降 0.25pp~3.92pp，平均電話服務時長縮短 2.19s~5.3s，可見 MRCP-TTS 的應用帶來了更好使用者體驗。
• 在美團的智慧外呼場景，結合 MRCP-TTS 提供流式語音合成服務後，對外呼機器人進行替換自研音色「美凡楠」的 A/B 試驗，資料表明智慧外呼通話成功率有效提升了 15% 。

在業務支援中，我們結合 MRCP 提供了多種音色，音色更加豐富真實，儘可能滿足各個業務場景。

四、結語

MRCP 協議及相關技術已經相對成熟，圍繞技術本身而言的迭代和演進相對較少。未來，除了語音合成（TTS）和語音識別 (ASR) 外，語音互動部自研的聲紋識別（VPR）技術也逐步成熟；其中，嬌喘識別效果大幅提升、目前效能已超過頭部廠商服務，年齡識別誤差小於7.5歲（公開測試集評測）。預計結合 MRCP 在電話智慧等場景提供相應技術能力，支援最佳化和提升業務流程及效果（如金服生意貸場景，透過聲紋識別判斷是否為虛假申貸人，減少惡意申貸造成的損失）。

從技術運用上看，一方面 MRCP 協議下的 TTS、ASR 為美團智慧外呼機器人、智慧呼入機器人等多個業務場景提供穩定的服務，並帶來可觀的業務效果提升；我們預期將其接入更多的業務場景，以客戶為中心、給每一個使用者帶來流暢絲滑的人機對話體驗，助力業務最佳化。另一方面，在標準化的 MRCP 協議介面的承載下，持續推進美團 TTS 和 ASR 能力的商業化。

五、名詞解釋

六、本文作者

唐銳、森彬、子豐、亞男、王程、國橋、俞濤等，均來自美團平臺/語音互動部。

七、參考文獻

• [1] Media Resource Control Protocol (2022) Wikipedia. Wikimedia Foundation. Available at: https://en.wikipedia.org/wiki/Media_Resource_Control_Protocol.
• [2] 史俊波,詹舒波 (2010) MRCPv2協議及其在分散式語音資源解決方案中的應用, 中國科技論文線上-科技論文. Available at: http://www.paper.edu.cn/releasepaper/content/201009-322.
• [3] zhu, james (2018) MRCP概要, CTI. Available at: http://www.ctiforum.com/news/guonei/534456.html.
• [4] UniMRCP Introduction (no date) Home. Available at: https://www.unimrcp.org/.
• [5] Kamailio Introduction (2022) The Kamailio SIP Server Project | The Open Source SIP Server. Available at: https://www.kamailio.org/w/.

閱讀更多

| 在美團公眾號選單欄對話方塊回覆【2022年貨】、【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可檢視美團技術團隊歷年技術文章合集。

| 本文系美團技術團隊出品，著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容，敬請註明“內容轉載自美團技術團隊”。本文未經許可，不得進行商業性轉載或者使用。任何商用行為，請傳送郵件至tech@meituan.com申請授權。