5.1.1MediaCtrl媒體控制草案

MediaCtrl是IETF下專門研究和制定媒體服務(wù)器控制標(biāo)準(zhǔn)的小組，以SIP和XML為所制定標(biāo)準(zhǔn)的基礎(chǔ)。這個工作組的工作包括：定義媒體服務(wù)器控制的技術(shù)需求說明、框架、控制協(xié)議簇和定位/連接協(xié)議。

5.1.1.1技術(shù)需求描述

這個技術(shù)需求描述媒體服務(wù)器控制協(xié)議需要實現(xiàn)的目標(biāo)，給控制協(xié)議劃定適用范圍，主要內(nèi)容包括：

l媒體控制要求：

1、協(xié)議應(yīng)該支持一個或者多個應(yīng)用服務(wù)器同時控制一個或者多個媒體服務(wù)器；

2、協(xié)議應(yīng)該使用可靠的底層傳輸協(xié)議；

3、協(xié)議應(yīng)該支持包括語音、音頻信號、文本和視頻在內(nèi)的媒體類型；

4、協(xié)議應(yīng)該使用SIP/SDP來建立到媒體服務(wù)器的連接；

5、應(yīng)該支持跨媒體服務(wù)器的會議；

6、必須支持一個或者一組參與者從會議分離出來，而不需要跟媒體服務(wù)器建立新的連接，例如在會議中建立子會議；

7、協(xié)議應(yīng)該支持應(yīng)用服務(wù)器查詢媒體服務(wù)器的會話狀態(tài)信息，信息報告應(yīng)包括資源使用狀況和網(wǎng)絡(luò)質(zhì)量等；

8、媒體服務(wù)器應(yīng)該支持上報應(yīng)用服務(wù)器訂閱的事件信息，如STUN請求，流量控制等；

l媒體混合/合成要求：

9、應(yīng)用服務(wù)器應(yīng)該支持會議混音；

10、應(yīng)用服務(wù)器應(yīng)該支持用戶自定義的視頻輸出窗口；

11、應(yīng)用服務(wù)器應(yīng)該支持視頻流到指定輸出窗口的映射或者告知媒體服務(wù)器視頻流和輸出窗口的映射關(guān)系

12、媒體服務(wù)器應(yīng)該能把當(dāng)前會議中的講話者和視頻源上報應(yīng)用服務(wù)器，講話者與視頻源可能是不同的，如介紹一個播放的視頻資料時；

13、媒體服務(wù)器應(yīng)該支持告知應(yīng)用服務(wù)器其所能支持的視頻合成格式；

14、協(xié)議應(yīng)該支持應(yīng)用服務(wù)器控制媒體服務(wù)器對會議進(jìn)行錄音/像；

lIVR要求：

15、應(yīng)用服務(wù)器可以通過協(xié)議控制媒體服務(wù)器執(zhí)行一個或者多個IVR腳本，并得到運(yùn)行結(jié)果；腳本可以在服務(wù)器上也可以承載在控制信令上；

16、應(yīng)用服務(wù)器可以通過發(fā)送放音請求和接收應(yīng)答(如DTMF)來控制IVR會話過程；應(yīng)用服務(wù)器根據(jù)收到的應(yīng)答來決定IVR的流程；

17、應(yīng)用服務(wù)器可以控制媒體服務(wù)器錄制一小段媒體流然后回放；這不同于錄音/像需求；

l操控要求：

18、應(yīng)用服務(wù)器可以通過協(xié)議在媒體會話過程中改變媒體服務(wù)器的狀態(tài)；

19、媒體服務(wù)器可以在媒體會話過程中上報自己的狀態(tài)；

5.1.1.2架構(gòu)描述

架構(gòu)描述為滿足上述技術(shù)需求，定義了媒體服務(wù)器控制的所有邏輯實體、實體之間的組成結(jié)構(gòu)和SIP的使用，并對IVR業(yè)務(wù)和會議業(yè)務(wù)使用媒體服務(wù)器控制來實現(xiàn)進(jìn)行描述。

5.1.1.2.1架構(gòu)總述

基本的信令架構(gòu)如下圖所示：

應(yīng)用服務(wù)器負(fù)責(zé)處理所有與用戶終端之間的信令交互，并通過SIP第三方呼叫控制(3PCC)的呼叫方式建立、維護(hù)和刪除用戶終端到媒體服務(wù)器之間的媒體連接。媒體流直接在用戶終端和媒體服務(wù)器之間傳輸。

這個架構(gòu)支持多對多的應(yīng)用服務(wù)器和媒體服務(wù)器連接。實際應(yīng)用中，一個應(yīng)用服務(wù)器可以同時控制多個媒體服務(wù)器，一個媒體服務(wù)器也可以同時服務(wù)于多個應(yīng)用服務(wù)器。

根據(jù)一個業(yè)務(wù)流程過程中是否需要應(yīng)用和媒體服務(wù)器之間進(jìn)行交互，媒體業(yè)務(wù)可以分為兩類：一類是不需要過程中進(jìn)行交互的，稱之為基本業(yè)務(wù)，如簡單的放音服務(wù)和會議服務(wù)(只做混音功能)，這類業(yè)務(wù)只需要使用NETANN就可以完成應(yīng)用對媒體服務(wù)器的媒體處理請求；另一類是需要過程中進(jìn)行交互的，這類業(yè)務(wù)應(yīng)用更廣泛，如IVR、復(fù)雜的會議服務(wù)等，這就需要另外的機(jī)制來傳遞交互信息。

應(yīng)用和媒體服務(wù)器之間交互的信息可分為三類：

l控制指令：應(yīng)用服務(wù)器發(fā)給媒體服務(wù)器媒體控制信令，如播放某段媒體、檢測媒體流中的DTMF信號等；

l應(yīng)答：媒體服務(wù)器完成控制指令的結(jié)果反饋；

l上報事件：當(dāng)應(yīng)用服務(wù)器訂閱的事件觸發(fā)或者狀態(tài)發(fā)生改變的時候，媒體服務(wù)器上報的消息，如上報DTMF信號、媒體連接網(wǎng)絡(luò)狀況變化等；

控制指令、應(yīng)答和上報事件的傳輸需要應(yīng)用和媒體服務(wù)器之間建立一個可靠的、順序的、端到端的連接。傳輸層協(xié)議應(yīng)該使用TCP。示意圖如下：

5.1.1.2.2SIP使用

在上述架構(gòu)里，SIP應(yīng)用于媒體連接的建立和媒體服務(wù)器控制通道的建立。關(guān)于使用SIP建立、管理和刪除媒體服務(wù)器控制通道會在5.2.4.3節(jié)里面詳細(xì)描述。

相對別的協(xié)議，使用SIP主要有以下幾點(diǎn)好處：

l可以使用SIP的定位策略和聚合能力。如根據(jù)DNS進(jìn)行路由。

l可以沿用SIP的安全策略。如使用TLS或者已有的各種加密和鑒權(quán)機(jī)制。

lSIP擁有很強(qiáng)的動態(tài)能力協(xié)商機(jī)制。

l可以根據(jù)能力集選擇合適的SIP實體。這使得媒體服務(wù)器可以告知應(yīng)用服務(wù)器它所能支持的媒體能力。

l使用SIP可以與IETF的協(xié)議和應(yīng)用保持延續(xù)性。

但在現(xiàn)有的媒體控制協(xié)議中，SIP的INFO消息被用來作為控制信令的載體，這并不合適，原因是：

lINFO是沒有特定語義的不透明的請求，終端收到INFO請求時，根據(jù)SIP協(xié)議定義并不能明確知道應(yīng)該如何處理；

lINFO是定義來傳遞可選的應(yīng)用層信息的，如呼叫中在PSTN網(wǎng)關(guān)之間傳遞PSTN信令，而不應(yīng)該用來傳遞會話層控制信息；

lINFO是根據(jù)SIP路由來傳遞的，這使得效率比較低，媒體控制信令應(yīng)該直接在應(yīng)用和媒體服務(wù)器之間傳遞；

l在RFC3261中，關(guān)于使用UDP傳輸有一個準(zhǔn)則，就是如果消息包接近最大傳輸單元時，應(yīng)改用TCP傳輸。這對于經(jīng)常傳遞基于XML格式的媒體控制消息包來說，十分不便。

5.1.1.2.3IVR業(yè)務(wù)描述

IVR業(yè)務(wù)所需的媒體功能包括：媒體轉(zhuǎn)換、基本放音、用戶輸入檢測(通過DTMF或者語音識別)和錄音等。當(dāng)然，根據(jù)IVR業(yè)務(wù)的不同，所需要的媒體功能也會不同，簡單的IVR業(yè)務(wù)可能只需要上述功能其中之一。

根據(jù)架構(gòu)描述，應(yīng)用服務(wù)器使用SIP和SDP建立和配置與媒體服務(wù)器的媒體會話。同時，使用SIP建立媒體服務(wù)器控制通道。應(yīng)用服務(wù)器通過控制通道調(diào)用IVR請求、接收應(yīng)答和上報事件。拓?fù)涫疽鈭D如下：

對于使用VoiceXML描述的IVR業(yè)務(wù)，也可以通過媒體服務(wù)器控制通道進(jìn)行調(diào)用。這就需要媒體服務(wù)器支持通過HTTP協(xié)議與VoiceXML文件所在服務(wù)器(可以是應(yīng)用服務(wù)器本身)進(jìn)行業(yè)務(wù)交互。

5.1.1.2.4會議業(yè)務(wù)描述

這里的會議業(yè)務(wù)描述遵循RFC4353和兼容集中式會議工作組(XCON)所制定的標(biāo)準(zhǔn)。

與IVR業(yè)務(wù)一樣，應(yīng)用服務(wù)器使用SIP和SDP建立和配置與媒體服務(wù)器的媒體會話。同時，使用SIP第三方呼叫控制的方式建立會議成員與媒體服務(wù)器的媒體連接和進(jìn)行添加/刪除會議成員的操作。有兩個會議成員的會議拓?fù)涫疽鈭D如下：

2m表示兩個會議成員與媒體服務(wù)器的媒體連接，1c表示應(yīng)用和媒體服務(wù)器之間的媒體會話。作為會議中樞，應(yīng)用服務(wù)器負(fù)責(zé)創(chuàng)建和管理在媒體服務(wù)器上的會議，以確保會議的媒體流可以正確的到達(dá)每個會議成員。

應(yīng)用服務(wù)器提供的會議功能應(yīng)包括：建立、管理和刪除會議、添加/刪除會議成員、管理會議中的所有媒體流、控制每一個媒體流的輸出和混音配置、允許用戶自定義媒體屬性等。下面簡要概括這些會議功能：

l創(chuàng)建新的會議

當(dāng)?shù)谝粋€會議成員發(fā)起SIP會議呼叫到應(yīng)用服務(wù)器的時候，應(yīng)用服務(wù)器會通過媒體控制通道給媒體服務(wù)器發(fā)出建立新會議的請求。這個請求包含了會議的詳細(xì)設(shè)置和策略要求，如媒體格式、混音配置等。媒體服務(wù)器驗證請求并為會議分配媒體資源。

當(dāng)媒體服務(wù)器完成對請求的處理，會返回給應(yīng)用服務(wù)器結(jié)果。每個會議都會分配一個唯一的會議號，用來作為應(yīng)用和媒體服務(wù)器對后續(xù)會議操作的標(biāo)志。

l媒體控制

XCON工作組的通用數(shù)據(jù)模型定義了一些基本媒體相關(guān)的控制，可供會議成員使用，其中包括：調(diào)整語音音量、調(diào)整視頻輸出格式、靜音/取消靜音和停止/恢復(fù)視頻等。這些控制功能需要會議成員和會議中樞之間使用標(biāo)準(zhǔn)的會議控制協(xié)議。會議中樞在收到這種控制請求后，會把它轉(zhuǎn)換成媒體控制協(xié)議通知媒體服務(wù)器對相應(yīng)的媒體流進(jìn)行處理。取消靜音的例子示意圖：

l場景控制

場景控制是XCON提出來的，是指在會議里對共享資源共同或者獨(dú)享使用進(jìn)行管理的一種機(jī)制。這對于會議來說不是必須的，但它增加了會議對媒體流輸入的控制功能。場景對應(yīng)著會議提供的一組資源，以供用戶合法使用和控制。XCON還定義了BFCP(Binary Floor Control Protocol)來規(guī)范場景控制機(jī)制。

BFCP包括場景控制服務(wù)器和場景決策器。結(jié)合應(yīng)用和媒體服務(wù)器的架構(gòu)，場景決策器是應(yīng)用邏輯，屬于應(yīng)用服務(wù)器的一部分。而場景控制服務(wù)器則既跟媒體服務(wù)器有關(guān)聯(lián)也跟應(yīng)用服務(wù)器有關(guān)，本文只討論場景控制服務(wù)器屬于媒體服務(wù)器的情形，這與3GPP定義的H.248.19是兼容的。

下面的時序圖給出一個在應(yīng)用和媒體服務(wù)器架構(gòu)上的場景控制例子：

在例子中，用戶終端開始的時候?qū)鼍百Y源只有旁聽的權(quán)限，他想?yún)⑴c發(fā)言就必須向場景控制器發(fā)起請求，經(jīng)過場景決策器的同意，媒體服務(wù)器把用戶終端的媒體流加入場景資源的混音中，用戶就可以在場景中發(fā)言了。

總結(jié)

以上是生活随笔為你收集整理的媒体服务器协议,媒体服务器介绍（mediactrl架构）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。