　　在前面的分享中，我們介紹了幾個(gè)MRCP相關(guān)基本的概念。在今天的分享中，我們從更加抽象的層面介紹MRCP的技術(shù)架構(gòu)，MRCP客戶端，服務(wù)器端，相關(guān)支持協(xié)議，媒體資源服務(wù)器的類型，典型的基本網(wǎng)絡(luò)應(yīng)用應(yīng)用場景，完整的MRCP協(xié)議流程示例，例如語音合成和語音識別的消息內(nèi)容和關(guān)于MRCP部署時(shí)需要注意到安全問題。讀者通過此分享可以比較全面地了解整個(gè)MRCP協(xié)議的技術(shù)背景。

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

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

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

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

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

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

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

basicsynth，支持基本的語音合成
speechsynth ，支持標(biāo)準(zhǔn)的語音合成
dtmfrecog，支持DTMF識別
speechrecog，支持語音識別
recorder，支持語音錄音
speakverify，講話人驗(yàn)證，聲紋匹配

　　Speech synthesisers（語音合成）支持了兩種語音合成方式。一種是基本的語音合成�；菊Z音合成把語音文件簡單進(jìn)行合成，僅支持有限的部分SSML標(biāo)準(zhǔn)，它必須支持的基本語法包括：，

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　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.

　　接下來的響應(yīng)的消息格式為：

　　MRCP/2.0 119 14321 200 IN-PROGRESS

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

　　Channel-Identifier: 43b9ae17@speechsynth

　　Speech-Marker: timestamp=857206027059 // 這里是NTP時(shí)間

　　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終端。

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

　　MRCP/2.0 157 SPEAK-COMPLETE 14321 COMPLETE

　　Channel-Identifier: 43b9ae17@speechsynth

　　Speech-Marker: timestamp=861500994355

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

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

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

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

　　MRCP/2.0 79 32121 200 IN-PROGRESS

　　Channel-Identifier: 23af1e13@speechrecog

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

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

　　Channel-Identifier: 23af1e13@speechrecog

　　Input-Type: speech

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

　　MRCP/2.0 472 RECOGNITION-COMPLETE 32121 COMPLETE

　　Channel-Identifier: 23af1e13@speechrecog

　　Completion-Cause: 000 success

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

　　Content-Type: application/nlsml+xml

　　// W3C發(fā)布的NLSML

　　Content-Length: 289

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

　　yes

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

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

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

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

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

　　參考資料：

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

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