多媒體系統(tǒng)中基于號碼分析的呼叫路由框架的設計和實現(xiàn)碩士學位論文

1、碩士學位論文多媒體系統(tǒng)中基于號碼分析的呼叫路由框架的設計與實現(xiàn) 摘要目前，多媒體系統(tǒng)已經(jīng)應用到各個重要場合，各種各樣的多媒體終端頻頻而出，從我們熟知的攝像機，監(jiān)視器，電視墻，到現(xiàn)在的高清ipc等等，這些終端的發(fā)展，使得多媒體系統(tǒng)的功能也越來越強大了。然而，現(xiàn)有的多媒體系統(tǒng)不是很完善，還有著許多需要改進的地方,比如多媒體系統(tǒng)中服務器與終端之間的交互以及服務器本身之間的交互的恢復機制等。呼叫路由是多媒體系統(tǒng)的組成部分，旨在通過呼叫路由模塊來找到各個終端和服務器的地址，以便完成服務器和終端之間的會話。本文基于對呼叫路由模塊的實現(xiàn)，分別從多媒體系統(tǒng)的組網(wǎng)、傳輸協(xié)議、數(shù)據(jù)庫等方面對多媒體系統(tǒng)進行分析，指

2、出了多媒體系統(tǒng)的一些需要改進的地方和改進的方案。同時，本文為多媒體系統(tǒng)提供了一個獨立的呼叫路由模塊并完成呼叫路由模塊數(shù)據(jù)庫的設計、編碼方案的設計和呼叫路由框架的設計。針對呼叫路由的框架，本文給出了呼叫路由模塊的幾個主要的數(shù)據(jù)結構和函數(shù)接口，以便進一步分析呼叫路由框架的實現(xiàn)過程。在呼叫路由模塊的實現(xiàn)中，本文參考了電話交換網(wǎng)絡中的號碼分析的應用技術，為多媒體系統(tǒng)制訂了一套基本的編碼方案?；诒疚脑O計的呼叫路由模塊，本文還為多媒體系統(tǒng)的業(yè)務的恢復提供了相關的實現(xiàn)策略并給出了多媒體系統(tǒng)中業(yè)務恢復的實例。關鍵詞：多媒體系統(tǒng)，終端，呼叫路由，號碼分析，會話abstractat present, ip mu

3、ltimedia operating system has been applied to many important occasions , various multimedia terminals come out more and more frequently as we know, from the camera, monitor, tv wall, to the present high definition ipc, etc, these terminals development makes the multimedia system being stronger and s

4、tronger. however, the existing multimedia system is not perfect enough, there are many areas in need of improvement in the multimedia system, such as the recovery mechanism of the interaction between servers and terminals in the multimedia system or the interaction between servers itself. call routi

5、ng is a component of the multimedia system, aims to find out addresses of the various terminals and servers from visiting call routing module in order to finish the sessions between servers and terminals. this article suggests some areas in need of improvement and the improvement plan by analyzing t

6、he multimedia system in the points of the multimedia systems networking, transfer protocol, database and so on which based on the realization of the call routing module. at the same time, this article provides a separate call routing module for multimedia system, completes the design for call routin

7、g modules database, coding scheme and framework. according to the framework of the call routing module, this paper gives several main data structures and interface functions in order to further analysis call routing frameworks implementation process. by learning the application technology of the tel

8、ephone exchange network, this essay develops a set of basic coding scheme for multimedia system in the realization of the call routing module. based on this design, this paper also provides some strategies for multimedia systems business recovery and gives some business recovery examples.key words：m

9、ultimedia system, terminals, call-routing, number analysis, session 目錄摘要iabstractii圖目錄iii表目錄iv第1章 緒論11.1 多媒體系統(tǒng)的發(fā)展11.1.1 多媒體系統(tǒng)簡介11.1.2 多媒體系統(tǒng)的應用11.2 多媒體系統(tǒng)的管理21.2.1 多媒體系統(tǒng)的終端管理21.2.2 多媒體系統(tǒng)的一些缺陷31.3 本課題的研究背景以及擬解決的問題41.3.1 課題來源41.3.2 呼叫路由技術在多媒體中的應用41.3.3 課題擬解決的問題41.4 本章小結5第2章 多媒體系統(tǒng)業(yè)務分析62.1 多媒體系統(tǒng)的基本架構62.1.

10、1 多媒體業(yè)務通用的三層架構體系62.1.2 ip多媒體系統(tǒng)的基本架構分析82.2 多媒體系統(tǒng)的協(xié)議分析112.2.1 h.323協(xié)議112.2.2 sip協(xié)議122.2.3 多媒體業(yè)務控制中協(xié)議的傳輸132.3 多媒體系統(tǒng)的組網(wǎng)設計分析142.3.1 多級多域模型142.3.2 終端交互的組網(wǎng)實現(xiàn)162.4 多媒體系統(tǒng)的會話類的業(yè)務分析182.4.1 終端注冊流程分析182.4.2 終端會話流程分析212.5 本章小結22第3章 多媒體系統(tǒng)的改進分析233.1 多媒體系統(tǒng)的一些策略與相關分析233.1.1 組網(wǎng)以及協(xié)議傳輸策略233.1.2 數(shù)據(jù)庫策略243.1.3 設備綁定策略253.2

11、多媒體系統(tǒng)一些改進的方案分析263.2.1 組網(wǎng)以及設備綁定改進分析263.2.2 數(shù)據(jù)庫改進分析283.2.3 編碼方案分析293.3 基于號碼分析的呼叫路由方案的提出303.3.1 號碼分析的應用303.3.2 號碼分析以及新的呼叫路由方案的提出313.4 本章小結32第4章 基于號碼分析的呼叫路由的框架的設計334.1 數(shù)據(jù)庫設計334.1.1 設備注冊路由表設計334.1.2 域路由表設計344.1.3 設備共享路由表設計354.2 編碼設計374.2.1 ip多媒體系統(tǒng)編碼應考慮的一些因素384.2.2 ip多媒體系統(tǒng)編碼設計394.3 呼叫路由模塊設計404.3.1 呼叫路由模塊框

12、架414.3.2 呼叫路由模塊業(yè)務實現(xiàn)流程設計444.3.3 呼叫路由模塊擴展設計474.4 呼叫路由模塊的實現(xiàn)484.4.1 數(shù)據(jù)結構設計的實現(xiàn)484.4.2 函數(shù)接口設計的實現(xiàn)504.4.3 呼叫路由框架的實現(xiàn)分析564.5 本章小節(jié)56第5章 基于號碼分析的呼叫路由框架的實現(xiàn)585.1 呼叫路由模塊支持的業(yè)務585.2 呼叫路由模塊實現(xiàn)的實例595.2.1 實時監(jiān)控的實例與分析595.2.2 多級多域組網(wǎng)注冊恢復的實例與分析625.3 本章小結66第6章 總結67參考文獻68作者簡歷70致謝71圖目錄圖2.1 多媒體三層架構圖6圖2.2 imos架構簡圖8圖2. 3 imos系統(tǒng)部分業(yè)務

13、截圖9圖2. 4 sip請求消息14圖2. 5 多級多域模型16圖2. 6 本域終端交互的實現(xiàn)17圖2. 7 域間終端會話18圖2. 8 終端配置界面19圖2. 9 終端注冊簡圖20圖3. 1 域間消息傳遞24圖3. 2 組網(wǎng)以及設備綁定圖解26圖3. 3 消息傳遞方案27圖4. 1 呼叫路由模塊數(shù)據(jù)庫設計關系圖37圖4. 2 呼叫路由模塊簡圖42圖4. 3 呼叫路由流程圖44圖4. 4 呼叫路由業(yè)務實現(xiàn)45圖4. 5 呼叫路由模塊結合業(yè)務的實現(xiàn)47圖5. 1 配置ec界面60圖5. 2 實況界面60圖5. 3設備注冊路由表61圖5. 4 ec路由信息61圖5. 5 本域?qū)崨r實例報文62圖5.

14、 6 域間?；顚嵗?3圖5. 7 呼叫路由重注冊實例64圖5. 8 域路由表實例65圖5. 9 域路由表數(shù)據(jù)查詢實例65圖5. 10 域間故障恢復實例66表目錄表3.1 imos路由表25表4.1 設備注冊路由表33表4.2 域路由表35表4.3 設備推送路由表36表4.4 編碼規(guī)則表40第1章 緒論1.1 多媒體系統(tǒng)的發(fā)展1.1.1 多媒體系統(tǒng)簡介本課題所研究的多媒體系統(tǒng)，也即ip多媒體系統(tǒng)（ip multimedia operating system），簡稱imos1。ip多媒體系統(tǒng)是一個基礎的開發(fā)平臺，短期內(nèi)，支持監(jiān)控、視訊、媒體發(fā)布等業(yè)務，節(jié)約開發(fā)和維護成本。長遠上，為產(chǎn)品的不斷豐富和

15、完善奠定基礎，為價值鏈上的客戶和友商開發(fā)增值業(yè)務，技術合作、技術創(chuàng)新提供彈性的空間。目前，一些公司已經(jīng)研究出自己的多媒體系統(tǒng)供使用，本課題所研究的多媒體系統(tǒng)，也即imos系統(tǒng)，是目前國內(nèi)最普遍使用的多媒體系統(tǒng)之一。多媒體系統(tǒng)已經(jīng)形成了一個穩(wěn)定的開發(fā)平臺，基于這個開發(fā)平臺，多媒體系統(tǒng)將逐步地完善功能，系統(tǒng)也越來越智能化，人性化。1.1.2 多媒體系統(tǒng)的應用多媒體系統(tǒng)，包括多媒體軟件系統(tǒng)和硬件系統(tǒng)，結合相關的應用領域，充分利用多媒體技術的關鍵特性，集成多種媒體的關聯(lián)信息，就可以構成多媒體的應用系統(tǒng)2 。起初，多媒體終端類型并不是太多，并且應用場合很有限，還沒有形成一個真正的多媒體系統(tǒng)。隨著應用的逐

16、漸推廣，終端類型的增多，管理這些終端，保持終端之間的會話越來越麻煩，多媒體系統(tǒng)才逐漸的發(fā)展起來。目前多媒體系統(tǒng)還在進一步發(fā)展中，但是多媒體系統(tǒng)確實已經(jīng)得到了極大的應用。在電影里我們經(jīng)常能到一個個的“監(jiān)控室”，在監(jiān)控室里，你可以看到本樓內(nèi)幾乎所有地方的視頻，這就是多媒體監(jiān)控領域的應用之一，當然，現(xiàn)在監(jiān)控領域的應用遠比那個“監(jiān)控室”多的多，因為現(xiàn)在的多媒體系統(tǒng)支持的業(yè)務已經(jīng)有很多了。在交通系統(tǒng)中，我們需要監(jiān)視路段的車輛情況，在公安局內(nèi)，監(jiān)獄等重要地方，我們需要全方位的監(jiān)控各個角落，在景區(qū)內(nèi)，我們也需要對各個景點進行監(jiān)控，而且監(jiān)控的角度還需要能夠?qū)崟r的調(diào)整，有時候更需要遠距離監(jiān)控，這些都是監(jiān)控領域的

17、應用，當然，要完成這些監(jiān)控，需要一個足夠強大的系統(tǒng)來支持這些業(yè)務。ip多媒體系統(tǒng)發(fā)展至今，從功能上足夠完成這些功能，所以，在國內(nèi)的應用是非常廣的。早在20世紀80年代中期就投入人力與物理從事多媒體技術的開創(chuàng)性研究工作，涌現(xiàn)出一批具有代表性的公司和多媒體系統(tǒng)，如commodore公司的amiga系統(tǒng)，apple公司的hypercard系統(tǒng)，philips/sony公司的cd-i系統(tǒng)，intel/ibm公司的dvi系統(tǒng)等3 。隨著開發(fā)的逐步發(fā)展，多媒體系統(tǒng)的業(yè)務也會日益豐富，不難想象，將來的多媒體系統(tǒng)是十分智能和人性化的。1.2 多媒體系統(tǒng)的管理1.2.1 多媒體系統(tǒng)的終端管理上面我們說過多媒體的

18、一些應用，為了完成這些實際的需求的功能，系統(tǒng)應該足夠強大來支持這些終端業(yè)務。imos目前支持的業(yè)務有很多，比較重要的有下面幾類：實況，實況又可以分為硬解實況和軟解實況。完成實況首先需要的終端的采像設備，就是攝像機，采像設備把所得的媒體數(shù)據(jù)發(fā)送到編碼器上。編碼器會根據(jù)配置的一些規(guī)則，比如h.264碼流4，進行編碼，把媒體流變成數(shù)據(jù)流。要想看到實況，就需要另一樣設備，解碼器和播放器，解碼器用來解碼，接收編碼器發(fā)送過來的數(shù)據(jù)流，硬解實況的播放器是一個實體終端，比如監(jiān)視器，電視墻等，解碼器發(fā)送過來的媒體流可以在這些終端上播放。軟解實況的播放器是兼容在系統(tǒng)上的，有一個xp播放窗口，可以解碼和播放實況。云

19、臺控制，云臺簡單的說是一個可以轉動的攝像機。攝像機的角度比較死，不能自動的去移動，如果想換一個角度，看下周圍的實況，就需要云臺了。多媒體系統(tǒng)支持云臺的控制，隨時可以控制云臺的角度。云臺的出現(xiàn)大大節(jié)省了攝像機資源，一個云臺足夠把周圍地區(qū)都監(jiān)視起來了。告警，告警是一個輔助功能，用來捕獲一些異常，比如運動告警，如果監(jiān)視器的某些地方出現(xiàn)畫面變化，就會啟動告警通知值班人員進行處理，這些應用大大節(jié)省了人力資源，還有很多告警類型，比如高溫告警，畫面丟失告警等等，告警的出現(xiàn)使管理方便很多。imos還有很多其他的功能，完成這些功能，如上面所說，就需要imos能夠管理這些終端，使終端能夠正常的會話。imos要管理

20、的終端類型很多，有軟終端和硬終端，如編碼器（ec），解碼器（dc），播放器（xp），媒體轉發(fā)服務器（ms），監(jiān)視器，攝像機，云臺等等。imos的終端管理與電話的管理有點類似。要完成終端的管理，首先需要把各個終端注冊到服務器上，不同的終端都在一個服務器上，這樣就通過服務器來完成本域的終端管理。當然不可能把所有的終端都注冊到一個服務器上，一則遠距離注冊不方便，二來服務器性能會受到很大挑戰(zhàn)。所以，imos為了解決這個麻煩，設計出了多級多域管理系統(tǒng)，服務器之間進行注冊管理，在一個服務器上能夠通過共享域資源，使用其他域的終端，這樣就完成了跨域的終端之間的交互。在跨地區(qū)的終端管理中，目前就是這種形式，不同

21、的是，imos的多級域有上下級域之分，就是，兩臺服務器的地位不是對等的，上級域能夠使用下級域共享（推送）的資源，而上級域不能像下級域推送資源，這樣做主要是為了完成管理的一個權限的劃分。1.2.2 多媒體系統(tǒng)的一些缺陷多媒體系統(tǒng)目前還在發(fā)展階段，作者所在的公司的多媒體開發(fā)部門一直在努力去打造一個綜合型的操作平臺，目前在國內(nèi)的業(yè)界發(fā)展已經(jīng)較為先進。小規(guī)模的終端應用簡單的多，我們通過其他硬件終端來分析一下多媒體的發(fā)展。就像電話機的出現(xiàn)一樣，電話在發(fā)展的初始階段，因為電話終端很少，所以可以通過簡單的直連等就可以接通電話，所以初期，電話就沒有什么較成型的管理方案。然而，隨著終端量的擴大，發(fā)現(xiàn)最初的管理相

22、當麻煩，大量排線等造成了電話業(yè)務的致命影響，所以才會有一個“服務器”管理系統(tǒng)的出現(xiàn)，電話機通過連接到服務器，由服務器進一步進行管理，這樣會少了很多麻煩，并且擴充了很多業(yè)務。然而，隨著終端數(shù)量的再一部擴大，電話的尋址方案越顯重要了，為了能夠完成電話間的尋址，服務器上有一套強大的路由尋址方案，而且經(jīng)過這么多年的發(fā)展，電話交換網(wǎng)的發(fā)展已經(jīng)相當成熟了。多媒體的發(fā)展也是一樣，隨著項目的逐步擴大，多媒體終端也會越來越多，多媒體系統(tǒng)的應用也會越來越廣。這樣問題就來了，如果把大量的終端都注冊到一個服務器上，那顯然是不行的，因此，本作者所在公司推出了多級多域管理方案，也就是把多臺服務器相互注冊，完成服務器間的資

23、源共享。在這套方案中，不可避免的會出現(xiàn)一個路由尋址的子方案，因為設備間終究是要尋址的。而目前的多媒體系統(tǒng)因為設備量，開發(fā)代價等，沒有把路由這一塊做的很好，只是簡單的和業(yè)務放在一起處理一下，提供了一個簡單的路由查詢接口供使用。這樣，業(yè)務的實現(xiàn)就會受到一定的限制，多臺服務器間的管理由于路由的限制會受到一些影響。還有，多媒體終端類型將會越來越多地出現(xiàn)，對這些終端的支持也是一個需要解決的問題。還有就是業(yè)務的實現(xiàn)了，這是目前正在逐步解決的，對于新業(yè)務的實現(xiàn)也是一個需要長期解決的問題。具體的缺陷會在第四章給出詳細的解釋與說明。1.3 本課題的研究背景以及擬解決的問題1.3.1 課題來源本課題源于多媒體系統(tǒng)

24、的業(yè)務和路由模塊和ipx系統(tǒng)5的呼叫路由方案的實現(xiàn)。作者經(jīng)過對目前多媒體系統(tǒng)的一些特征的分析，總結出一些改善的方案，同時吸取現(xiàn)在的電話交換網(wǎng)絡6的一些技術，完成一套分析設計文檔。本課題就是基于這套方案展開來，對路有模塊逐步分析，形成了一個獨立的路由的框架。1.3.2 呼叫路由技術在多媒體中的應用在解決路由的問題之前，我們先來看一看目前呼叫路由在多媒體系統(tǒng)中的實現(xiàn)方式。在目前的多媒體系統(tǒng)中，路由模塊與業(yè)務模塊集成在一起。數(shù)據(jù)庫中會有一張專門存放路有信息的路有表，在這張路由表中，存放的有終端設備的編碼，ip地址，地址類型，端口號，以及nat穿越的地址信息。路由模塊會提供一個查詢的接口來實現(xiàn)路由信息

25、的查詢，在需要應用地址查詢的控制模塊就直接調(diào)用這個接口就行了。因為接口的代碼量不是很大，所以沒有單獨做成一個模塊，不劃算，就直接寫在控制模塊里了。路由表里還含有域的地址信息，通過查詢路由表能夠幫助業(yè)務控制模塊查詢到設備所在域的地址，然后再通過設備所在域服務器進一步查詢。這樣就可以順藤摸瓜，總能找到設備。1.3.3 課題擬解決的問題本課題擬解決一些路由方面的問題，設計了一個新的路由模塊，解決終端之間只有一條路徑可達的局限性問題，同時智能化了呼叫路由模塊的功能。具體來說可以分為以下幾個子問題。路由表的規(guī)劃。對目前的路由表重新規(guī)劃設計，使得數(shù)據(jù)庫能夠更方便地支持路由模塊的功能，進而能支持更多的業(yè)務和

26、增加效率。設備編碼。對終端設備進行編碼，為業(yè)務的實現(xiàn)增加提供方便，也為基于號碼分析的呼叫路由的實現(xiàn)打下基礎。呼叫路由框架設計。根據(jù)現(xiàn)有的一些呼叫路由技術和其他領域中的呼叫路由的應用，為多媒體系統(tǒng)提供一個有效的呼叫路由的模塊結構?；谝陨先c，本文的問題與工作也就有了初步的認識，在后面幾章里，作者將會對于多媒體的具體的一些會話的業(yè)務，多媒體系統(tǒng)的改進分析和呼叫路由的設計給出詳細的分析和說明。1.4 本章小結本章主要介紹了多媒體系統(tǒng)的一些應用，其中包括多媒體應用系統(tǒng)和終端設備等，基于這些指出了目前多媒體系統(tǒng)的一些缺陷。本章還指出本課題所做的工作與目前哪些多媒體系統(tǒng)的缺陷的關系，利用本課題研究的成果

27、，對多媒體系統(tǒng)有哪些改進。同時，在本章中引入了本課題研究的對象，也就是呼叫路由的尋址，由此進一步指明了本課題所做的工作，也就是設計和實現(xiàn)一個獨立的呼叫路由框架，以及在設計和實現(xiàn)過程中所需要的幾項具體的工作和參考的資料等，為后面的具體的分析和設計打下基礎。第2章 多媒體系統(tǒng)業(yè)務分析2.1 多媒體系統(tǒng)的基本架構多媒體系統(tǒng)的業(yè)務很多，涉及到會話類的業(yè)務也有數(shù)十種之多，但這些業(yè)務都有一個基本的流程，這些業(yè)務也都會基于一個基礎的多媒體架構來實現(xiàn)。下面我們分別對imos的架構，組網(wǎng)，會話業(yè)務進行分析。2.1.1 多媒體業(yè)務通用的三層架構體系用戶管理業(yè)務管理媒體網(wǎng)關呼叫控制呼叫路由數(shù)據(jù)庫sip適配層其他適配

28、層h.323適配層應用層控制層基礎設施層數(shù)據(jù)交互業(yè)務控制圖2.1 多媒體三層架構圖如圖2.1，這個是多媒體的基本三層架構5。目前許多的多媒體系統(tǒng)都是基于這個架構衍生而來，對每個層進行逐步的細化。我們能通過系統(tǒng)界面等看到一系列的業(yè)務，這些業(yè)務正是基于應用層的一些基本業(yè)務接口發(fā)展而來，這些業(yè)務接口是應用層的基礎，是最基本的業(yè)務接口，我們在界面上的看到業(yè)務就是這些基本業(yè)務的邏輯的組合。原子業(yè)務是最底層底層的業(yè)務，原子業(yè)務向前支持應用的業(yè)務，有了這些原子業(yè)務，就能構造出一系列的基礎業(yè)務，應用層只需要根據(jù)這些業(yè)務加以邏輯處理，就能實現(xiàn)許多各種各樣的新業(yè)務。應用層的各種業(yè)務就是由原子業(yè)務經(jīng)過控制層的邏輯組

29、合發(fā)展而來?？梢耘e個很形象的例子，在畫圖版中會有各種各樣的動作，比如多邊形，圓形，涂色，等等，有了這些最基本的功能就能畫出一副好看的圖片。那么，基本業(yè)務就是這些最基本的動作，在界面上展示的就是具體的應用。多媒體系統(tǒng)支持的業(yè)務有很多，很多業(yè)務看起來很靈活多變，細細分析起來，也就是幾個子業(yè)務的組合。應用層是關系到用戶體驗的直接層，因此，多媒體系統(tǒng)的好壞，與應用層的展現(xiàn)有著最直接的關系?？刂茖邮嵌嗝襟w系統(tǒng)的核心?？刂茖犹峁┝藨脤又械脑訕I(yè)務的實現(xiàn)和封裝，控制層在整個多媒體架構中起到了至關重要的作用。在控制層中，不同的多媒體系統(tǒng)會有不同的模塊劃分，作者所研究的多媒體系統(tǒng)的控制層相當復雜，有許多子模塊

30、組成，在下一節(jié)會做相關分析。呼叫控制是控制層實現(xiàn)業(yè)務的基本所在，呼叫控制與應用層的各種業(yè)務和底層的一些庫、插件接口相連，為了實現(xiàn)各種業(yè)務，呼叫控制也分為了許多子模塊進行。在呼叫控制中，不可避免的會用到地址查詢，對設備進行管理和控制，這樣，就產(chǎn)生了呼叫路由。呼叫路由模塊也是控制層中核心的一環(huán)，在目前的多媒體系統(tǒng)中，由于呼叫路由的應用還沒有較大的發(fā)展，目前呼叫路由的代碼量也不是很大，有很多多媒體系統(tǒng)就直接把呼叫路由模塊并入到呼叫控制中去了，沒有形成一個單獨的模塊，在作者所在的系統(tǒng)中也是這樣處理的。在呼叫控制的實現(xiàn)中，各個子模塊使用內(nèi)部消息進行聯(lián)系，消息構造出來在控制層中經(jīng)過逐步的轉化和處理，最后轉

31、換成符合規(guī)范的外部消息發(fā)送到設備終端等，在后面的業(yè)務流程分析中會有一定的介紹?；A設施層為控制層提供了最基本的一些協(xié)議解析庫、原子業(yè)務所需的硬件接口等。在控制層中需要的協(xié)議，如sip協(xié)議，h.323協(xié)議以及在處理這些協(xié)議中需要使用到的xml庫等都會由基礎設施層提供。在現(xiàn)在的多媒體開發(fā)中，基礎設施層都已經(jīng)開發(fā)好了，開發(fā)多媒體系統(tǒng)一般都是開發(fā)控制層和應用層。盡管基礎設施層上已經(jīng)為業(yè)務的實現(xiàn)提供了一些最基本的保障，但是這些和業(yè)務并沒有直接的關系，為了實現(xiàn)業(yè)務控制，還需要控制層做好多事情。2.1.2 ip多媒體系統(tǒng)的基本架構分析整個imos的架構十分復雜，但也是基于上面的三層架構演化而來。imos的簡

32、單架構圖如圖2.2所示。圖2.2 imos架構簡圖下面我們就根據(jù)imos的架構1來簡單分析下多媒體的一些業(yè)務的實現(xiàn)。從imos的架構上我們明顯可以看出多媒體系統(tǒng)的三成架構的輪廓。imos平臺分為5個層次，依次為os基礎設施層、數(shù)據(jù)訪問層、多媒體基礎設施層、業(yè)務邏輯層和業(yè)務展示層;這其中涵括9個組件：用于用戶交互的gui組件、用于業(yè)務實現(xiàn)的as應用服務組件和cs調(diào)度服務組件、用于信令調(diào)度的cc呼叫組件、用于媒體調(diào)度的mc組件、用于媒體處理的mp組件、用于配置管理的mm組件、底層框架的bp基礎平臺和dao數(shù)據(jù)庫組件。imos的業(yè)務展示層展示了較為豐富的多媒體業(yè)務，有實時監(jiān)控，點播回放，存儲計劃，云

33、臺操作，會議控制，設備管理，權限配置等等。多媒體系統(tǒng)由一個系統(tǒng)的登陸頁面，通過ie輸入服務器地址可以登陸imos系統(tǒng)。目前imos系統(tǒng)統(tǒng)一配置在一個linux服務器6上，以普通的pc機作為客戶端登陸。在登陸界面上可以看到imos業(yè)務的分布情況。圖2. 3 imos系統(tǒng)部分業(yè)務截圖圖2.3是imos登陸界面的部分截圖。從imos的登陸界面上可以看出業(yè)務的大致分布。每個業(yè)務項都含有一堆子業(yè)務項，這些基于原子業(yè)務發(fā)展起來的各個業(yè)務共同構成了imos系統(tǒng)。由于imos業(yè)務很多，而且還有很多不同的類型，為了更好的實現(xiàn)、維護和擴展這些業(yè)務，imos對控制層進行了一系列的劃分，imos的每一個業(yè)務的實現(xiàn)都會

34、遵循一個業(yè)務的流程。從圖2.2上，我們看到了imos的業(yè)務的一個簡單流程，imos在應用層的調(diào)用接口之后，控制層首先對接口調(diào)用情況進行處理，在處理業(yè)務時會構造一條業(yè)務控制的消息，并且發(fā)送到下面一層。控制層有xp播放器控制主要是因為imos系統(tǒng)本身兼容了xp播放器，imos支持硬解實況（利用單獨的電視墻，監(jiān)視器來播放實況）和軟解實況（利用系統(tǒng)自帶的播放器來播放實況），所以系統(tǒng)本身還需要對播放器進行處理。消息處理層在接收到來自主線的消息后，根據(jù)消息的內(nèi)容進行處理，轉換消息并且轉發(fā)消息到下面的具體的業(yè)務處理層進行處理。消息管理層處理各種業(yè)務的消息。業(yè)務控制層是控制層的關鍵層，實現(xiàn)具體的業(yè)務，業(yè)務控制

35、層根據(jù)業(yè)務的不同又有具體的劃分，比如呼叫控制模塊（cc），媒體控制模塊（mc）等等1，每個模塊都會處理部分業(yè)務。呼叫控制模塊是業(yè)務控制中的最重要的模塊之一，本課題所研究的呼叫路由目前就是兼容在cc控制塊之中的。在呼叫控制的實現(xiàn)中，又會有一系列的具體的劃分，在業(yè)務控制層中也是通過內(nèi)部信令消息來完成模塊之間的聯(lián)系。數(shù)據(jù)管理也是控制層中的一個重要的控制部分，在imos系統(tǒng)的數(shù)據(jù)庫中存有大量的數(shù)據(jù)，控制層的其他模塊不會去直接調(diào)用數(shù)據(jù)庫進行數(shù)據(jù)管理，而是通過訪問數(shù)據(jù)管理模塊的接口間接的去完成。同其他多媒體系統(tǒng)一樣，控制層也是imos的核心，從imos控制層這么細致的劃分就能有一定的體現(xiàn)。控制層的好壞決定

36、了系統(tǒng)的好壞。imos在本服務器（本域）的業(yè)務和服務器間（跨域）的業(yè)務并存，控制層分別對其進行處理，但是不管是本域還是跨域，都會對設備資源進行管理，呼叫路由無疑是解決這些業(yè)務中關鍵的一環(huán)，在下一章中我們會針對呼叫路由方面展開分析?；A設施層為控制層提供了最基本的保障。在控制層處理業(yè)務時，會用到數(shù)據(jù)庫、各種必要的原子業(yè)務接口等。基礎設施層的協(xié)議棧是處理控制層的信令處理的基礎，在對信令消息進行分解，組合等都需要協(xié)議棧的支持，在解析消息中用到xml解析庫無疑會大大增加解析的方便性和安全性，控制層需要對設備進行管理，這些設備管理的接口對于控制曾來說又是實現(xiàn)業(yè)務的基礎?？刂茖有枰獙崿F(xiàn)imos的功能，這些

37、功能需要根據(jù)基礎設施層提供的原子業(yè)務進行處理，原子業(yè)務的提供保障了最上層業(yè)務的實現(xiàn)。2.2 多媒體系統(tǒng)的協(xié)議分析多媒體系統(tǒng)采用的協(xié)議主要有h.3238和sip9協(xié)議，比如目前大公司內(nèi)流行正熱的的視頻會議系統(tǒng)大多是采用h.323協(xié)議的，然而，鑒于sip協(xié)議的靈活性，sip協(xié)議在多媒體系統(tǒng)中也慢慢的應用起來，比如imos系統(tǒng)所采用的就是sip協(xié)議。h.323協(xié)議和sip協(xié)議并不是指某個具體的協(xié)議，它們是一個協(xié)議族，h.323和sip協(xié)議族中包含了ras協(xié)議，q.931協(xié)議，h.245協(xié)議10，h.225協(xié)議等11，在實際的應用中會根據(jù)具體的業(yè)務來選擇協(xié)議。2.2.1 h.323協(xié)議h.323是19

38、97年itu-t第16工作組的建議，h.323由一組協(xié)議構成，其中有負責音頻與視頻信號的編碼、解碼和包裝，有負責呼叫信令收發(fā)和控制的信令，還有負責能力交換的信令8。 h.323標準標準建立在tcp/ip這一協(xié)議基礎之上，可以提供豐富的管理功能，從h.323剛定義起經(jīng)歷了幾個版本的變化，目前以及到版本五。h.323協(xié)議網(wǎng)絡在視頻會議的應用上是屬于總線型結構，h.323的終端都通過本身主機上的普通lan網(wǎng)卡掛接在網(wǎng)絡上。h.323是多媒體通信的基礎，基于h.323協(xié)議可以開發(fā)出許多業(yè)務層的應用，這些應用與底層網(wǎng)絡傳輸無關，比如現(xiàn)在的視頻會議系統(tǒng)，網(wǎng)上ip電話系統(tǒng)，網(wǎng)上ip傳真系統(tǒng)等等，這些都是利用

39、h.323技術發(fā)展起來，因此可以說，h.323是一個很好的發(fā)展平臺。在多媒體的發(fā)展中，h.323得到了極大的應用，多媒體的一些關鍵技術，比如視頻廣播，多媒體組網(wǎng)等可以用h.323得到很好的實現(xiàn)。h.323定義了4個主要部件構筑基于網(wǎng)絡的通信系統(tǒng)：終端、網(wǎng)關、網(wǎng)守、多點控制單元（mcu）8?？梢酝ㄟ^網(wǎng)閘(gatekeeper)對網(wǎng)絡上的h.323多媒體通信終端進行名稱登記、會議登記、地址解析、訪問控制、帶寬管理、帶寬控制，域管理以及一些呼叫補充業(yè)務的實現(xiàn)。h.323的出現(xiàn)，根本原因是來自于“三網(wǎng)合一”8。1997年正是基于異步傳遞技術（atm）實現(xiàn)三網(wǎng)合一的勢頭最猛烈的一年，但此時以太網(wǎng)技術和i

40、p技術的發(fā)展勢頭更為迅猛。大量的企事業(yè)單位擁有了帶寬非常可觀的局域網(wǎng)，語音、視訊、數(shù)據(jù)這三個業(yè)務基于以太網(wǎng)或ip網(wǎng)這種沒有嚴格保障的網(wǎng)絡的需求已經(jīng)非常迫切。h.323協(xié)議就是在這樣的背景下應運而生的。在呼叫控制和信令方面，h.323主要參考了傳統(tǒng)pstn的呼叫控制和信令架構。因此，h.323的血統(tǒng)中帶有濃厚的pstn的思想痕跡。本課題中的編碼方案的實現(xiàn)參考就是pstn中的撥號計劃，畢竟pstn是集人類百年智慧經(jīng)驗于一身，在承載話音單業(yè)務方面效率最高、質(zhì)量最好、成本最低的網(wǎng)絡。h.323在分組網(wǎng)絡上模擬了pstn的結構，因此它本身也是分層、主從、集中式的控制方式。但分組網(wǎng)絡不同于pstn網(wǎng)絡，在

41、技術實現(xiàn)上有本質(zhì)的區(qū)別。h.323在分組網(wǎng)絡上模擬pstn的呼叫控制和信令，必然繼承了pstn的優(yōu)點，也繼承了pstn的缺點。因此，h.323也處在不斷的進步當中，從版本一到版本五，一直在改正不足，增加新特性。動態(tài)發(fā)展的看待h.323這個協(xié)議，作為通信思想在分組網(wǎng)絡上的多媒體具體實現(xiàn)，其前景是比較廣闊的。2.2.2 sip協(xié)議sip是由ietf在1999年提出來的一個應用控制（信令）協(xié)議9。正如名字所隱含的用于發(fā)起會話。它可用來創(chuàng)建、修改以及終結多個參與者參加的多媒體會話進程。參與會話的成員可以通過組播方式、單播連網(wǎng)或者兩者結合的形式進行通信。sip中有客戶機和服務器之分?？蛻魴C是指為了向服務

42、器發(fā)送請求而與服務器建立連接的應用程序。用戶代理（user agent）和代理（proxy）中含有客戶機。服務器是用于向客戶機發(fā)出的請求提供服務并回送應答的應用程序。共有四類基本服務器9：1. 用戶代理服務器：當接到sip請求時它聯(lián)系用戶，并代表用戶返回響應。2. 代理服務器：代表其它客戶機發(fā)起請求，既充當服務器又充當客戶機的媒介程序。在轉發(fā)請求之前，它可以改寫原請求消息中的內(nèi)容。3. 重定向服務器：它接收sip請求，并把請求中的原地址映射成零個或多個新地址，返回給客戶機。4. 注冊服務器：它接收客戶機的注冊請求，完成用戶地址的注冊。用戶終端程序往往需要包括用戶代理客戶機和用戶代理服務器。代理

43、服務器、重定向服務器和注冊服務器可以看出是公眾性的網(wǎng)絡服務器。在sip中還經(jīng)常提到定位服務器的概念，但是定位服務器不屬于sip服務。imos系統(tǒng)也有一個服務器(vm)，但是不是這四個服務器簡單的服務器之一，而是這幾個服務器的綜合。目前多媒體服務器沒有幾個只有單一功能的服務器了，大多都兼容了用戶代理，注冊和重定向功能。sip協(xié)議比h.323協(xié)議更等得到計算機開發(fā)人員的喜愛，如果說h.323是搞通信的人提出的協(xié)議，那么sip就是搞計算機的人提出的協(xié)議12。上世紀90年代末，隨著internet網(wǎng)絡應用的逐步普及，計算機網(wǎng)絡工作者想基于計算機和internet進行多媒體通信。因此，ietf充分參考了

44、h.323的得失，制定了sip協(xié)議。顧名思義，它突出了簡單二字。sip這個協(xié)議完全傳承了internet的特點，是計算機網(wǎng)絡流派的杰作12。internet是一個分布、客戶機/服務器、水平控制的網(wǎng)絡，sip協(xié)議本身實現(xiàn)的通信方式也是一個分布、客戶機/服務器、水平的控制結構。任何一個協(xié)議的提出，都不可能考慮的完美無缺，sip協(xié)議也不例外。任何一個優(yōu)點的獲得，往往都導致另一個或幾個缺陷的產(chǎn)生。因此，sip協(xié)議也一直都在進步當中。sip協(xié)議自1999年推出以來，ietf一直在不停的推出增補版本，充實安全、身份驗證等領域的內(nèi)容。動態(tài)來看待sip協(xié)議，它作為計算機思想在分組網(wǎng)絡上的多媒體實現(xiàn)手段，其發(fā)展

45、前景是非常廣闊的12。2.2.3 多媒體業(yè)務控制中協(xié)議的傳輸不管是h.323協(xié)議還是sip協(xié)議，終究是為了實現(xiàn)業(yè)務的控制。那么，就需要對協(xié)議進行細化，通過協(xié)議下達具體的控制命令，因此我們也可以說，協(xié)議是含有控制命令的載體。在多媒體的實際應用中，控制消息由協(xié)議進行傳輸?？刂葡?，簡單的說可以分成三類，請求消息，成功響應消息，錯誤響應消息。請求消息中會帶有具體的業(yè)務類型，地址，端口等信息，如圖2.4，這就是一個請求消息的實例。從請求消息中可以看出消息的各種信息，比如from字段中的源地址，to字段中的目的地地址，頭里面的端口信息，還有body下面的具體的消息體的內(nèi)容。這就是imos中一個實際應用的

46、協(xié)議，為了使各個多媒體廠商能夠相互的兼容，大家都會按照一定的規(guī)范來發(fā)送消息，圖2.4也是基于imos的一種協(xié)議規(guī)范的具體應用。響應消息也一樣，都是基于這份規(guī)范而來，只是所含有的信息不一樣，如果是成功響應，消息的名稱多是以200ok為準，錯誤的響應消息根據(jù)錯誤的類型會有多種響應，并且都含有各自的錯誤碼。圖2. 4 sip請求消息2.3 多媒體系統(tǒng)的組網(wǎng)設計分析2.3.1 多級多域模型多級多域模型1是imos組網(wǎng)的一個基本模型。所謂多級多域，就是指多臺服務器通過分級分域的方法來進行組網(wǎng)。一般地，一個多媒體系統(tǒng)服務器自己就可以構成一個域，通過把終端設備注冊到服務器上來完成對終端的管理。為了方便遠距離

47、設備間的資源交互等，很多情況下都需要多臺服務器進行設備間的管理，這些服務上的設備也大多都需要會話，那么就需要把這些服務器通過某種關系進行聯(lián)系起來，這就是多域模型，而不同的服務器之間的關系可能是不對等的，假定我們想要服務器i有訪問服務器ii的權限，但是倒過來不行，我們就需要對服務器的等級作個劃分，這樣，就有多級的概念。在imos系統(tǒng)的應用中，已經(jīng)支持多級多域的配置。imos系統(tǒng)在實際的應用中也逐漸的去推廣這種解決方案。我們從實際的應用來分析，如果一個應用方案只有兩個終端，而且兩個終端交互很方便，比如說就只有一個監(jiān)視器需要播放一個攝像機的實況，那么解決方案就很簡單了，甚至不需要imos服務器的存在

48、，因為這樣會浪費很多資源。但是，一個實際的應用，往往是由很多設備終端存在的，而且設備終端的類型也各種各樣，imos支持的終端，有虛擬的終端，如xp播放器，也有實際的終端，如攝像機，編碼器，解碼器，監(jiān)視器，電視墻，存儲設備等等，應用的業(yè)務也多種多樣，這樣一來imos系統(tǒng)的存在就很重要了。完成這些設備的管理和業(yè)務的實現(xiàn)，就需要這些終端注冊到服務器上，使imos能夠管理這些設備。在本域管理中，直接登錄imos系統(tǒng)就能完成服務器上的設備的交互。imos的vm服務器1之間有上級域，平級域和下級域的概念?？梢詾楸居蛱砑右粋€上級域，同樣在上級域上添加本域為下級域，這樣上級域就有權限使用本域的一些資源。由于上

49、級域的權限比下級域的高，所以資源共享是單方向的，由下級域把資源共享到上級域，我們稱這一過程為資源推送。如圖2.5，這是一個多級多域模型的實例，在下級域上掛載了很多終端設備，然后可以把這些設備推送到中間域上，中間域再把這些設備推送到上級域上。在上級域上可以完成下級域的資源的管理。比如，可以在上級域的xp播放器上播放和存儲下級域攝像機的錄像。域和域之間還有平級域關系，就是兩個域可以是對等的，資源可以互訪，這樣與上下級域結合起來，可以構成許多種組網(wǎng)方案。目前imos 的應用還在推廣中，在實際的應用中多級多域的組網(wǎng)也不是很麻煩，imos設定最大只允許七級組網(wǎng)，從目前的應用場景來看，已經(jīng)足夠使用。當然，

50、如果需求進一步加大，碰到了“超級組網(wǎng)”之類，imos值需要在性能上做相應的調(diào)整，就可以實現(xiàn)多級多域組網(wǎng)的管理。多級多域組網(wǎng)雖然已經(jīng)足夠強大，但是還在進一步的發(fā)展中，根據(jù)業(yè)務的需要，將來可能會開發(fā)出更好的組網(wǎng)。上級域中間域下級域下級域中間域下級域終端設備圖2. 5 多級多域模型2.3.2 終端交互的組網(wǎng)實現(xiàn)經(jīng)過上面的討論分析，我們對本域的組網(wǎng)管理有了一定的了解，下面來深入了解在組網(wǎng)中具體怎么實現(xiàn)終端的會話。服務器終端a終端b業(yè)務請求1響應1業(yè)務請求2響應2圖2. 6 本域終端交互的實現(xiàn)imos終端間的信令采用的是sip協(xié)議1，服務器向終端間發(fā)送信令消息來完成各個終端的控制。比如注冊時，終端會向服

51、務器發(fā)送register請求消息，等待服務器響應，當服務器回復200ok成功響應消息時，終端系統(tǒng)再進行處理，注冊成功。兩個終端間進行會話，如圖2.6所示，這是一個終端會話的3pp模型，服務器首先向其中一個終端發(fā)送sip請求消息，消息中包含請求的指令，請求的地址等信息，終端系統(tǒng)收到請求后，判斷消息的合法性，業(yè)務的合理性，權限等，都符合條件后向服務器回復成功的響應。如果請求非法，那么終端會向服務器發(fā)送錯誤響應，并且攜帶相關的錯誤碼，服務器再進一步對錯誤響應進行處理。如果終端a收到了服務器的請求，并且回復成功響應，此時服務器收到成功響應后向終端b發(fā)送業(yè)務請求，同終端a的請求一樣，消息中也會攜帶相關的

52、業(yè)務信息和終端a的信息。終端b同樣會對該請求消息進行判斷，如果請求合法，那么會回復成功響應消息，然后終端b會根據(jù)消息中關于終端a的信息與終端a建立會話1。上面是本域的終端的管理，域間的終端交互比本域麻煩了一些，多了服務器與服務器之間的交互。如圖2.7，終端a想要與終端b會話，首先需要服務器b把終端b共享到服務器a上來，然后服務器a向終端a發(fā)起業(yè)務請求，成功后再向服務器b發(fā)起請求，這個請求包含服務器b和終端b的相關信息。當服務器b收到來自服務器a的請求后，會根據(jù)域間的消息，對消息進行處理，獲取業(yè)務信息，然后向終端b發(fā)起業(yè)務請求，收到終端b的成功響應后繼而向服務器a回復成功響應。至此，終端b獲取了

53、終端a的信息，開始會話。服務器a服務器b終端a終端b9終端會話3.本域業(yè)務請求4.本域業(yè)務響應7.本域業(yè)務響應6.本域業(yè)務請求8.域間響應2.成功響應1.共享請求5.域間請求圖2. 7 域間終端會話目前的imos系統(tǒng)的本域業(yè)務業(yè)務比較多，域間的業(yè)務類也得到了很大的發(fā)展。隨著新的終端類型的出現(xiàn)和業(yè)務類型的增多，本域和域間的終端交互還會有進一步的發(fā)展。2.4 多媒體系統(tǒng)的會話類的業(yè)務分析2.4.1 終端注冊流程分析如圖2.9，這個是終端注冊的一個簡單的流程，當然由于每個模塊內(nèi)部都有非常細的子流程，我們不可能把每一個詳細的業(yè)務過程都說的很細，只需要關注業(yè)務在內(nèi)部大致的實現(xiàn)就行了。人工的操作顯然是從界

54、面開始的，圖2.8就是一個攝像機的登陸界面，在界面上可以對服務器進行配置，從而由系統(tǒng)完成注冊。圖2. 8 終端配置界面在界面上配置了設備id，服務器ip等信息以后，終端界面會調(diào)用終端系統(tǒng)得的消息構造模塊，構造出一條簡單的注冊消息，包含界面配置的一些信息，消息構造模塊會繼續(xù)調(diào)用內(nèi)部的消息轉發(fā)模塊，把構造的內(nèi)部注冊消息發(fā)送到終端系統(tǒng)的控制模塊?？刂颇K對消息進行處理，根據(jù)消息的內(nèi)容從新構造一條符合一定規(guī)范的注冊消息，發(fā)送到信令網(wǎng)關模塊。信令網(wǎng)關會對消息再次進行處理，轉換消息為符合域間規(guī)范的注冊消息，這里會調(diào)用一個協(xié)議轉換庫進行操作。消息轉換完成之后，由消息發(fā)送模塊負責把注冊消息發(fā)送到imos服務器

55、系統(tǒng)。至此，在終端內(nèi)部的注冊流程已經(jīng)完成。服務器系統(tǒng)的消息接收模塊接收到消息之后，同樣會在網(wǎng)關模塊對消息進行轉換，使得注冊消息符合服務器內(nèi)部的消息規(guī)范，然后發(fā)送到控制模塊進行處理。控制模塊解析消息，獲取消息的內(nèi)容，然后構造出一條符合其他模塊的消息，發(fā)送到相關的處理模塊，最后對數(shù)據(jù)庫進行操作把注冊的相關信息儲存到數(shù)據(jù)庫中。域間消息終端系統(tǒng)界面消息構造模塊消息轉發(fā)模塊控制模塊信令網(wǎng)關模塊消息發(fā)送模塊消息接收模塊控制模塊消息轉發(fā)數(shù)據(jù)庫操作域內(nèi)消息域內(nèi)消息終端系統(tǒng)內(nèi)部處理大致流程服務器內(nèi)部處理流程圖2. 9 終端注冊簡圖同樣，在服務器系統(tǒng)的界面上也要配置終端的相關信息，用來檢測終端的注冊信息。當服務器

56、收到終端的注冊信息，并且成功處理注冊請求之后，服務器上的終端設備就會顯示在線狀態(tài)，此時服務器就可以管理終端的資源。2.4.2 終端會話流程分析終端的會話流程與注冊流程有點類似，因為在內(nèi)部的處理上也是由這幾個模塊處理，不同的是處理的具體過程會不同。終端會話首先需要在服務器系統(tǒng)的界面上來完成配置，配置后終端的信息會顯示在服務器客戶端的界面上。服務器系統(tǒng)的界面操作指定的終端交互業(yè)務，比如實況，就需要啟動攝像機到播放器上。這樣，播放器和攝像機是兩個終端，觸發(fā)實況業(yè)務時，服務器的界面會調(diào)用一個消息構造模塊，構造出指定模塊的業(yè)務消息發(fā)送的服務器的主線上，主線層會根據(jù)消息的內(nèi)容等轉發(fā)消息到消息處理模塊，消息

57、處理模塊收到來自界面的消息，對消息做轉換處理，發(fā)送到指定的模塊進行處理，如實況消息會發(fā)送到媒體控制模塊，協(xié)議控制模塊等分別進行處理，最后消息會發(fā)送到網(wǎng)關，由網(wǎng)關對消息進行轉換，再調(diào)用消息發(fā)送模塊把消息發(fā)送到域間的指定地址。消息在終端系統(tǒng)和多級多域中域間的其他服務器內(nèi)的處理情況也是類似，因為每一個模塊的處理都是由很多的子模塊合作完成，具體的流程相當復雜，并且不是本課題研究的重點，限于篇幅，在這里不多作詳細介紹。終端會話在內(nèi)部處理的流程比較類似，業(yè)務由幾個模塊分別處理完成，在這里，我們關注一個問題，就是呼叫控制控制模塊（call control），簡稱cc，作者目前所在的項目就是呼叫控制項目組，本課題也可以說是此模塊的一個子模塊的研究。cc主要完成的工作是提供組合目標業(yè)務的原子操作功能,并支持在sip協(xié)議上進行擴展，以滿足更多