1、準確地說，MRCP是一種框架，也是一種協(xié)議。MRCP的框架定義了各種網(wǎng)絡要素和它們之間的關(guān)系，并且也設定了在MRCP中其他協(xié)議之間的之間的會話管理和媒體處理等關(guān)系（例如SIP和RTP）。MRCP協(xié)議本身也提供了對媒體源的控制機制，例如控制語音識別和語音合成等。所以，通常環(huán)境下，我們?yōu)榱朔奖�，稱之為MRCP協(xié)議。當然，讀者也可以稱之為MRCP框架。

　　MRCP的設計目的是支持客戶端對服務器端發(fā)起一個請求，設定一個在網(wǎng)絡中部署的媒體資源。MRCP的主要目的在于語音處理資源的處理，這些語音處理資源包括：語音識別，語音合成，語音錄音和講話人的認證和確認。MRCP借用了SIP協(xié)議來支持MRCP的處理流程。SIP可以使用SIP URL通過網(wǎng)絡來支持MRCP客戶端來獲取媒體資源，并且可以查詢獲取到媒體類型和其支持能力。它一旦獲取到正確的媒體資源服務器信息，SIP將會創(chuàng)建兩個通信管道，一個是用來支持媒體會話，它支持發(fā)送或接收語音數(shù)據(jù)。這些數(shù)據(jù)可能是從媒體資源服務器發(fā)出也可能是來自于媒體資源服務器。另外一個管道是控制會話，它用來支持MRCP客戶端和媒體資源服務器之間的請求通信，從服務器端返回響應消息和事件。這里，MRCP協(xié)議是運行在控制會話之上。以下圖例表示了一個基本的MRCP框架。

　　在MRCP 客戶端包括了SIP協(xié)議棧和MRCP協(xié)議棧。后者扮演的就是一個MRCP客戶端角色。當應用層的程序請求一個媒體資源的時候，它會調(diào)用媒體資源的API接口。此API接口通過SIP協(xié)議棧會創(chuàng)建一個SIP dialog 并且攜帶媒體資源服務器信息。SIP協(xié)議棧會通過RTP對媒體服務器資源初始化一個媒體會話，并且通過MRCP對媒體資源服務器創(chuàng)建一個控制會話。

　　在會話初始化過程也可以包括一些服務器端可預設的專用媒體資源。接下來，MRCP客戶端可以通過會話控制直接調(diào)用這些專有的媒體資源。MRCP客戶端可以在同樣的終端設備或作為其他實體的一個部分包含媒體資源�？蛻舳说腟IP協(xié)議則可以充分利用信令和媒體分離的方式，它們分別通過不同的路徑來處理。

　　媒體資源服務器端的也同樣包括了MRCP協(xié)議棧和SIP協(xié)議棧。服務器端的MRCP執(zhí)行的是服務器端的MRCP協(xié)議棧，并且對MRCP客戶端的請求做出響應，生成事件。如上圖所示，服務器端包括了各種媒體資源，例如語音識別，合成等引擎。當客戶端請求多個資源時，這些資源可以共享同一媒體會話或支持針對每個媒體資源的專有會話。以下圖例比較清晰地解釋了上面的架構(gòu)示例，方便用戶做進一步的理解MRCP的架構(gòu)。

　　MRCP充分地利用了SIP協(xié)議的優(yōu)勢，非常完美地解決了管理媒體和控制會話的問題。從SIP協(xié)議的角度來看，它管理的話會話屬性本身不是最重要的，它更側(cè)重于對媒體資源的定位，提供一個整合功能。因為SIP協(xié)議提供的媒體資源服務器查詢服務，MRCP客戶端可以獲得關(guān)于媒體資源的支持能力。

　　2、在上面的章節(jié)中我們討論了MRCP的基本架構(gòu)，其中，在服務器端支持了很多媒體資源。媒體資源則包括了各種媒體類型。MRCP定義了六種媒體資源類型，它們分別是：

　　Speech synthesisers（語音合成）支持了兩種語音合成方式。一種是基本的語音合成�；�本語音合成把語音文件簡單進行合成，僅支持有限的部分SSML標準，它必須支持的基本語法包括：，

　　dtmfrecog和speechrecog都是媒體資源，都支持語音識別。dtmfrecog僅對DTMF進行識別。speechrecog則是我們通常所說的語音識別。兩種媒體識別都借用了W3C 的Speech Recognition Grammar Specification （SRGS）設定了單詞，短語（包括DTMF）來作為語音識別的輸入。語音識別媒體資源通常還包括對通過語音識別對自然語言結(jié)合語法等進行處理識別的能力。

　　speech recorder則提供對語音進行錄音，然后保存到一個指定的URL，另外，它同時也對終端提供一種語音靜音處理作用。當用戶在某一段設定時間后已經(jīng)停止講話，用戶錄音應該會去除靜音時間。

　　Speakverify 媒體資源主要的作用利用聲學技術(shù)，通過對講話者的語音和已保存的聲紋進行匹配，確認其身份和簽權(quán)認證。

　　3、媒體資源服務通過MRCP支持了很多應用場景�，F(xiàn)在我們簡單介紹幾個具體的應用場景，讓用戶理解如何通過MRCP結(jié)合語音電話系統(tǒng)來實現(xiàn)分布式語音媒體處理。

　　首先，我們介紹一個VoiceXML IVR 場景。這里的VoiceXML相當于一個MRCP的客戶端，支持了SIP協(xié)議棧，VoiceXML 解析器和MRCP客戶端。同時，它也支持了PSTN的接入，通過SIP 協(xié)議對接MRCP客戶端SIP。媒體資源服務器端包括了語音識別，合成，錄音和DTMF識別處理引擎。這樣的應用場景可以運用在呼叫中心等相關(guān)的行業(yè)。當然，目前的很多呼叫中心智能機器人也基本上和以下示例相似�？蛻舳丝梢灾С諥sterisk或者FreeSWITCH，通過uniMRCP實現(xiàn)和媒體資源引擎的交互。

　　早期智能化的IPPBX語音郵箱也是一個經(jīng)典的應用場景。首先，這里我們說明，這是一個早期的語音郵箱的服務示例。當然無論從功能的豐富性，成本優(yōu)勢或其他集成能力，目前的IPPBX或者軟交換的語音郵箱系統(tǒng)本身已經(jīng)非常靈活強大。目前，開源的融合通信平臺，例如Asterisk，F(xiàn)reeSWITCH都支持了非常強大的語音留言功能，可以輕松實現(xiàn)標準化的語音郵箱的語音提示。特別是基于Asterisk平臺開發(fā)的開源免費IPPBX-FreePBX，它支持了豐富的界面管理，用戶可以通過界面輕松配置語音郵箱。但是這些不是我們今天討論的范圍。今天，我們重點討論的是基于MRCP集成的IPPBX 語音郵箱�；�于MRCP的語音郵箱系統(tǒng)可以通過MRCP對呼叫方進行錄音，合成和語音識別，實現(xiàn)對用戶電話留言進行管理，包括語音文件內(nèi)容，日期，呼叫方名稱等。這些數(shù)據(jù)都可以通過語音資源引擎進行處理，方便儲存。這是以前基于MRCP開發(fā)的一種語音郵箱服務，具體市場用戶的認可度有多高，我們也不得而知，畢竟語音資源引擎的部署成本和準確率是一個非常大的挑戰(zhàn)。這里，我們僅作為一個演示的示例。但是，筆者認為，如果對于IPPBX來說，如果呼叫方（例如，殘障人士，老人，或者病人等）直接對IPPBX系統(tǒng)說一個公司員工的名稱就可以自動實現(xiàn)呼叫此員工分機，呼叫方不需要再通過摁DTMF 按鍵來撥號，這也許也是一個可行的需求。

　　最后，我們再介紹一個高級媒體網(wǎng)關(guān)，智能終端或軟交換的應用場景。其實，這里的媒體網(wǎng)關(guān)應用場景和上面所說的IPPBX結(jié)合MRCP的應用場景非常相似。這里的高級媒體網(wǎng)關(guān)仍然是MRCP的客戶端，通過不同的SIP終端（例如，PJSIP 等終端），物理話機對媒體網(wǎng)關(guān)發(fā)起一個請求，通過媒體網(wǎng)關(guān)的MRCP模塊和媒體資源服務器端的語音資源引擎進行處理。這樣的應用場景和以上我們討論的兩個場景都有相似之處。所不同的是，如果通過開源SIP終端，結(jié)合軟交換或媒體網(wǎng)關(guān)可以實現(xiàn)更多的應用場景，不僅僅局限于語音呼叫業(yè)務本身。例如，用戶可以通過PJSIP 終端，可以開發(fā)手機APP終端，也可以通過PJSIP嵌入式終端方式實現(xiàn)智能物聯(lián)網(wǎng)等需求。

　　4、我們在上面的篇幅中分別介紹了MRCP的技術(shù)架構(gòu)示例，媒體資源類型和網(wǎng)絡應用場景。為了進一步了解SIP協(xié)議和MRCP協(xié)議，我們花一點時間介紹一下SIP協(xié)議和MRCP的工作流程。

　　首先讓我們簡單了解一下如何創(chuàng)建通信的通道。筆者在前面的介紹中已多次討論過，MRCP借助SIP協(xié)議完美地解決了通信的控制問題。MRCP本身沒有定義自己的查詢媒體資源能力和會話創(chuàng)建機制。它借助于SIP協(xié)議來完成。大家知道，在IP通信中，SIP可以在兩個終端之間創(chuàng)建媒體會話。而媒體的傳輸則是獨立于SIP協(xié)議之外的RTP協(xié)議來完成。在創(chuàng)建會話過程中或者呼叫中的交互中，SIP協(xié)議使用了SDP協(xié)議來協(xié)助描述和協(xié)商媒體會話。以下是一個簡單的呼叫創(chuàng)建流程，這里不再介紹SIP呼叫的創(chuàng)建過程。讀者可以參考其他材料做進一步的了解和學習，讀者也可以查閱本公眾號的歷史文檔有非常詳細的介紹。

　　在簡單的應用環(huán)境中，一次從媒體資源服務器調(diào)用一種單個的媒體資源類型，媒體會話也是單向的。如果同一時間使用多個媒體資源類型時則創(chuàng)建雙向的媒體資源流。MRCP和我們常見的IP通信不同，它可以對媒體會話包含一個控制會話連接。此控制會話是通過在SDP描述中添加更多消息，例如包括MRCP客戶端請求的媒體資源類型等。這里，媒體會話的傳輸是使用RTP通過UDP端口來傳輸；而控制會話則是通過MRCP通過TCP或者SCTP傳輸。以下示例是一個MRCP客戶端連接媒體資源服務器的流程。這里，不要求支持180 響應，但是創(chuàng)建了一個媒體會話和一個控制會話。

　　以上流程中，創(chuàng)建了會話以后，MRCP需要控制媒體資源。MRCP協(xié)議消息格式類似于HTTP的消息格式，也是一種外部格式。MRCP消息格式包括三種格式：請求消息，響應消息和事件。請求消息是從MRCP客戶端發(fā)到媒體資源服務器端，而響應消息則是由媒體資源服務器端，根據(jù)客戶端的請求返回的響應消息，并且響應消息中包含了一個三位數(shù)的狀態(tài)碼。另外，響應消息中包含了當前的請求狀態(tài)，當前請求狀態(tài)包括：PENDING，IN-PROGRESS 或 COMPLETE的其中一種。

　　PENDING 狀態(tài)表示當前的請求在等待處理的隊列中，等待進行處理，處理方式為先進先出的方式。IN-PROGRESS狀態(tài)表示當前請求正在被處理。COMPLETE響應則表示完成請求處理，在當前的連接中無更多消息。在以上三種狀態(tài)中，PENDING和IN-PROGRESS都表示請求未完成處理，需要更多的事件消息。事件消息允許媒體資源服務器端和客戶端對某些狀態(tài)的改變或?qū)�客戶端發(fā)生一個事件來進行通信。事件消息中包括事件名稱和請求狀態(tài)。

　　5、以上章節(jié)介紹了MRCP如何通過各種消息來控制媒體資源。為了讓讀者更加清晰地了解整個流程的處理方式，我們通過兩個完整的示例來說明MRCP協(xié)議對媒體的控制和消息格式。

　　第一個關(guān)于MRCP協(xié)議的流程示例是語音合成（speech synthesiser）的示例。這里，我們假設媒體會話和控制會話通過SIP響應已經(jīng)創(chuàng)建成功，語音流正在傳輸。MRCP客戶端對服務器端發(fā)起了一個SPEAK的請求，開始處理此請求，并且要求通過媒體資源服務器合成一個文本。

　　具體的請求消息格式如下：

　　MRCP/2.0 380 SPEAK 14321

　　Channel-Identifier: 43b9ae17@speechsynth

　　Content-Type: application/ssml+xml

　　Content-Length: 253

　　

　　

　　Good afternoon Anne.

　　You have one voice message, two e-mails, and three faxes

　　waiting for you.

　　

　　接下來的響應的消息格式為：

　　MRCP/2.0 119 14321 200 IN-PROGRESS

　　// ID是14321，200 表示成功，正在處理中，119消息長度是119 bytes。

　　Channel-Identifier: 43b9ae17@speechsynth

　　Speech-Marker: timestamp=857206027059 // 這里是NTP時間

　　MRCP的狀態(tài)碼包括：200–299（Success）， 400–499（ Client error）和500–599（Server error）。這些狀態(tài)碼和SIP的狀態(tài)碼基本類似。

　　讀者已經(jīng)看到，我們的請求的狀態(tài)是IN-PROGRESS ，表示正在被媒體資源處理，大部分情況下，媒體數(shù)據(jù)可能已經(jīng)返回到MRCP終端。

　　接下來，媒體資源服務器端生成一個SPEAK-COMPLETE事件，表示此請求已經(jīng)完成，對于此請求來說，沒有更多的事件進行處理。

　　MRCP/2.0 157 SPEAK-COMPLETE 14321 COMPLETE

　　Channel-Identifier: 43b9ae17@speechsynth

　　Speech-Marker: timestamp=861500994355

　　Completion-Cause: 000 normal // 表示SPEAK請求的正常處理結(jié)束。

　　通過以上幾個步驟和響應消息處理，我們可以清晰地看到語音合成的基本處理流程和其相應的返回碼。

　　以上是一個語音合成的MRCP處理流程，我們再介紹一個語音識別的MRCP處理流程。這里，我們?nèi)匀患僭O通過SIP協(xié)議，會話控制和媒體控制已經(jīng)創(chuàng)建成功。以下是一個MRCP客戶端發(fā)出的請求消息，它要求媒體資源服務器對語音進行識別。注意，這里的請求是RECOGNIZE 請求，而不是剛才我們在語音合成時的SPEAK請求。

　　RECOGNIZE請求消息如下：

　　MRCP/2.0 461 RECOGNIZE 32121

　　Channel-Identifier: 23af1e13@speechrecog

　　Content-ID:

　　Content-Type: application/srgs+xml

　　Content-Length: 289

　　

　　

　　xml:lang="en-GB">

　　

　　

　　yes

　　no

　　

　　

　　

　　以上消息格式和SPEAK請求格式非常相似，這里的通道是使用的是speechrecog 媒體資源。這里需要識別的是兩個選項（Yes/No）。同樣，媒體資源服務器對客戶端返回一個正在處理的狀態(tài)消息：

　　MRCP/2.0 79 32121 200 IN-PROGRESS

　　Channel-Identifier: 23af1e13@speechrecog

　　此消息表示媒體資源服務器正在處理客戶端請求，也可能語音識別引擎正在采集媒體流數(shù)據(jù)，馬上生成一個識別的語音。當語音識別引擎檢測到語音時，它會生成一個START-OF-INPUT消息。

　　MRCP/2.0 111 START-OF-INPUT 32121 IN-PROGRESS

　　Channel-Identifier: 23af1e13@speechrecog

　　Input-Type: speech

　　這里，客戶端也可以結(jié)束或打斷此語音合成。如果正常處理的話，語音識別引擎會生成一個RECOGNITION-COMPLETE事件消息，并且在消息中包含生成的結(jié)果。

　　MRCP/2.0 472 RECOGNITION-COMPLETE 32121 COMPLETE

　　Channel-Identifier: 23af1e13@speechrecog

　　Completion-Cause: 000 success

　　// 000 表示成功，001 表示無匹配結(jié)果，002 表示輸入超時。

　　Content-Type: application/nlsml+xml

　　// W3C發(fā)布的NLSML

　　Content-Length: 289

　　

　　

　　xmlns="http://www.ietf.org/xml/ns/mrcpv2">

　　

　　

　　yes

　　

　　yes

　　

　　

　　在MRCP V2版本（RFC6787）中支持了兩種結(jié)果輸出格式，一種是nlsml（通常說的自然語言語義的標記語言或者描述語言）是由W3C發(fā)布。另外一種是EMMA標記語言。EMMA全稱為Extensible Multimodal Annotation Markup Language （EMMA）。如果讀者有興趣的話，可以查閱相關(guān)的參考文檔做進一步的研究。

　　6、通過以上完整的介紹，可能讀者對MRCP有了一個基本的概念。但是，在部署MRCP客戶端或服務器端時，我們這里沒有真正關(guān)注其安全性的問題。在今天的IP通信中，其實用戶已經(jīng)對SIP協(xié)議的使用場景做了很多的設置，但是如果沒有對MRCP協(xié)議或使用流程做安全設置的話，特別是MRCP協(xié)議中使用了多個XML文件和其語法語義解析文件，并且大部分的MRCP客戶端都是通過公網(wǎng)訪問的第三方的媒體資源服務器，如果沒有設置安全措施的話，同樣可能給客戶帶來很多的安全隱患。這些安全問題包括：

• 會話創(chuàng)建時的安全問題。在SIP創(chuàng)建過程中用戶一定要注意安全的設置。
• 控制會話的保護。如果對其控制會話沒有做保護措施的話，可能導致第三方對其進行安全攻擊。
• 媒體會話的保護。如果我們的媒體數(shù)據(jù)沒有經(jīng)過安全設置，可能導致媒體數(shù)據(jù)被監(jiān)聽或盜取。
• 非直接的內(nèi)容訪問。因為，我們的合成內(nèi)容或語音可能經(jīng)過公網(wǎng)進行處理，如果第三方非法訪問我們的最終數(shù)據(jù)，可能導致安全問題。
• 保護已存儲的媒體文件�？蛻舳撕兔襟w資源服務器端需要針對媒體文件存儲設置一定的安全措施和安全權(quán)限來保證媒體文件不被盜取或非法訪問。

　　7、在本分享中，我們首先介紹了關(guān)于MRCP的基本結(jié)構(gòu)，然后分別介紹了MRCP響應中多個核心模塊和接口，MRCP客戶端的處理方式和媒體資源服務器端的處理方式。我們也介紹了MRCP目前支持的媒體資源類型，以及結(jié)合語音服務，媒體網(wǎng)關(guān)完成對語音識別應用場景。為了進一步幫助讀者了解進一步了解MRCP的處理流程，我們對媒體控制和幾種請求響應狀態(tài)和處理流程做了介紹，并且結(jié)合語音合成和語音識別的消息處理流程，給讀者提供了一個較完整的消息解析。最后，為了部署安全穩(wěn)定的解決方案，筆者也從幾個不同的方面討論了關(guān)于MRCP的安全性問題，希望讀者能夠引起重視。

　　在接下來的分享學習中，筆者會更加詳細地一步步介紹MRCP協(xié)議中各個模塊功能作用。希望讀者繼續(xù)關(guān)注。

　　參考資料：

　　https://www.w3.org/TR/2004/REC-speech-synthesis-20040907/

　　https://www.w3.org/TR/2009/REC-emma-20090210/

　　關(guān)注微信公眾號：asterisk-cn，獲得有價值的行業(yè)分享

　　freepbx 技術(shù)論壇：www.ippbx.org.cn

　　Asterisk， freepbx技術(shù)文檔： www.freepbx.org.cn

　　歐米（Omni）智能客服解決方案

　　融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com