5.1.1MediaCtrl媒體控制草案

MediaCtrl是IETF下專門研究和制定媒體服務器控制標準的小組，以SIP和XML為所制定標準的基礎。這個工作組的工作包括：定義媒體服務器控制的技術需求說明、框架、控制協議簇和定位/連接協議。

5.1.1.1技術需求描述

這個技術需求描述媒體服務器控制協議需要實現的目標，給控制協議劃定適用范圍，主要內容包括：

l媒體控制要求：

1、協議應該支持一個或者多個應用服務器同時控制一個或者多個媒體服務器；

2、協議應該使用可靠的底層傳輸協議；

3、協議應該支持包括語音、音頻信號、文本和視頻在內的媒體類型；

4、協議應該使用SIP/SDP來建立到媒體服務器的連接；

5、應該支持跨媒體服務器的會議；

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

7、協議應該支持應用服務器查詢媒體服務器的會話狀態信息，信息報告應包括資源使用狀況和網絡質量等；

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

l媒體混合/合成要求：

9、應用服務器應該支持會議混音；

10、應用服務器應該支持用戶自定義的視頻輸出窗口；

11、應用服務器應該支持視頻流到指定輸出窗口的映射或者告知媒體服務器視頻流和輸出窗口的映射關系

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

13、媒體服務器應該支持告知應用服務器其所能支持的視頻合成格式；

14、協議應該支持應用服務器控制媒體服務器對會議進行錄音/像；

lIVR要求：

15、應用服務器可以通過協議控制媒體服務器執行一個或者多個IVR腳本，并得到運行結果；腳本可以在服務器上也可以承載在控制信令上；

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

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

l操控要求：

18、應用服務器可以通過協議在媒體會話過程中改變媒體服務器的狀態；

19、媒體服務器可以在媒體會話過程中上報自己的狀態；

5.1.1.2架構描述

架構描述為滿足上述技術需求，定義了媒體服務器控制的所有邏輯實體、實體之間的組成結構和SIP的使用，并對IVR業務和會議業務使用媒體服務器控制來實現進行描述。

5.1.1.2.1架構總述

基本的信令架構如下圖所示：

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

這個架構支持多對多的應用服務器和媒體服務器連接。實際應用中，一個應用服務器可以同時控制多個媒體服務器，一個媒體服務器也可以同時服務于多個應用服務器。

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

應用和媒體服務器之間交互的信息可分為三類：

l控制指令：應用服務器發給媒體服務器媒體控制信令，如播放某段媒體、檢測媒體流中的DTMF信號等；

l應答：媒體服務器完成控制指令的結果反饋；

l上報事件：當應用服務器訂閱的事件觸發或者狀態發生改變的時候，媒體服務器上報的消息，如上報DTMF信號、媒體連接網絡狀況變化等；

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

5.1.1.2.2SIP使用

在上述架構里，SIP應用于媒體連接的建立和媒體服務器控制通道的建立。關于使用SIP建立、管理和刪除媒體服務器控制通道會在5.2.4.3節里面詳細描述。

相對別的協議，使用SIP主要有以下幾點好處：

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

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

lSIP擁有很強的動態能力協商機制。

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

l使用SIP可以與IETF的協議和應用保持延續性。

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

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

lINFO是定義來傳遞可選的應用層信息的，如呼叫中在PSTN網關之間傳遞PSTN信令，而不應該用來傳遞會話層控制信息；

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

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

5.1.1.2.3IVR業務描述

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

根據架構描述，應用服務器使用SIP和SDP建立和配置與媒體服務器的媒體會話。同時，使用SIP建立媒體服務器控制通道。應用服務器通過控制通道調用IVR請求、接收應答和上報事件。拓撲示意圖如下：

對于使用VoiceXML描述的IVR業務，也可以通過媒體服務器控制通道進行調用。這就需要媒體服務器支持通過HTTP協議與VoiceXML文件所在服務器(可以是應用服務器本身)進行業務交互。

5.1.1.2.4會議業務描述

這里的會議業務描述遵循RFC4353和兼容集中式會議工作組(XCON)所制定的標準。

與IVR業務一樣，應用服務器使用SIP和SDP建立和配置與媒體服務器的媒體會話。同時，使用SIP第三方呼叫控制的方式建立會議成員與媒體服務器的媒體連接和進行添加/刪除會議成員的操作。有兩個會議成員的會議拓撲示意圖如下：

2m表示兩個會議成員與媒體服務器的媒體連接，1c表示應用和媒體服務器之間的媒體會話。作為會議中樞，應用服務器負責創建和管理在媒體服務器上的會議，以確保會議的媒體流可以正確的到達每個會議成員。

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

l創建新的會議

當第一個會議成員發起SIP會議呼叫到應用服務器的時候，應用服務器會通過媒體控制通道給媒體服務器發出建立新會議的請求。這個請求包含了會議的詳細設置和策略要求，如媒體格式、混音配置等。媒體服務器驗證請求并為會議分配媒體資源。

當媒體服務器完成對請求的處理，會返回給應用服務器結果。每個會議都會分配一個唯一的會議號，用來作為應用和媒體服務器對后續會議操作的標志。

l媒體控制

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

l場景控制

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

BFCP包括場景控制服務器和場景決策器。結合應用和媒體服務器的架構，場景決策器是應用邏輯，屬于應用服務器的一部分。而場景控制服務器則既跟媒體服務器有關聯也跟應用服務器有關，本文只討論場景控制服務器屬于媒體服務器的情形，這與3GPP定義的H.248.19是兼容的。

下面的時序圖給出一個在應用和媒體服務器架構上的場景控制例子：

在例子中，用戶終端開始的時候對場景資源只有旁聽的權限，他想參與發言就必須向場景控制器發起請求，經過場景決策器的同意，媒體服務器把用戶終端的媒體流加入場景資源的混音中，用戶就可以在場景中發言了。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。