MRCP協(xié)議學(xué)習(xí)筆記-MRCP概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　具體的請(qǐng)求消息格式如下：

　　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.

　　

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

　　MRCP/2.0 119 14321 200 IN-PROGRESS

　　// ID是14321，200 表示成功，正在處理中，119消息長(zhǎng)度是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)碼基本類(lèi)似。

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

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

　　MRCP/2.0 157 SPEAK-COMPLETE 14321 COMPLETE

　　Channel-Identifier: 43b9ae17@speechsynth

　　Speech-Marker: timestamp=861500994355

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

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

　　以上是一個(gè)語(yǔ)音合成的MRCP處理流程，我們?cè)俳榻B一個(gè)語(yǔ)音識(shí)別的MRCP處理流程。這里，我們?nèi)匀患僭O(shè)通過(guò)SIP協(xié)議，會(huì)話(huà)控制和媒體控制已經(jīng)創(chuàng)建成功。以下是一個(gè)MRCP客戶(hù)端發(fā)出的請(qǐng)求消息，它要求媒體資源服務(wù)器對(duì)語(yǔ)音進(jìn)行識(shí)別。注意，這里的請(qǐng)求是RECOGNIZE 請(qǐng)求，而不是剛才我們?cè)谡Z(yǔ)音合成時(shí)的SPEAK請(qǐng)求。

　　RECOGNIZE請(qǐng)求消息如下：

　　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請(qǐng)求格式非常相似，這里的通道是使用的是speechrecog 媒體資源。這里需要識(shí)別的是兩個(gè)選項(xiàng)（Yes/No）。同樣，媒體資源服務(wù)器對(duì)客戶(hù)端返回一個(gè)正在處理的狀態(tài)消息：

　　MRCP/2.0 79 32121 200 IN-PROGRESS

　　Channel-Identifier: 23af1e13@speechrecog

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

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

　　Channel-Identifier: 23af1e13@speechrecog

　　Input-Type: speech

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

　　MRCP/2.0 472 RECOGNITION-COMPLETE 32121 COMPLETE

　　Channel-Identifier: 23af1e13@speechrecog

　　Completion-Cause: 000 success

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

　　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（通常說(shuō)的自然語(yǔ)言語(yǔ)義的標(biāo)記語(yǔ)言或者描述語(yǔ)言）是由W3C發(fā)布。另外一種是EMMA標(biāo)記語(yǔ)言。EMMA全稱(chēng)為Extensible Multimodal Annotation Markup Language （EMMA）。如果讀者有興趣的話(huà)，可以查閱相關(guān)的參考文檔做進(jìn)一步的研究。

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

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

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

　　在接下來(lái)的分享學(xué)習(xí)中，筆者會(huì)更加詳細(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/

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

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

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

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

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