馬 躍, 柴安穎,2, 于碧輝, 于 波

1(中國科學(xué)院 沈陽計算技術(shù)研究所,沈陽 110168)

2(中國科學(xué)院大學(xué),北京 100049)

隨著全球經(jīng)濟(jì)的不斷發(fā)展,互聯(lián)網(wǎng)不斷融入人們的生活,視頻通話越來越受人們青睞,多方音視頻通信成為一種很受歡迎的通信方式. 在各通信系統(tǒng)的媒體流傳輸中,存在兩種網(wǎng)絡(luò)傳輸方式： 一種是星狀網(wǎng)絡(luò)拓?fù)?另一種是網(wǎng)狀網(wǎng)絡(luò)拓?fù)? 但現(xiàn)有的通信方案往往只選取其中一種方法作為媒體流傳輸方式,沒有充分融合兩種方式的各自優(yōu)勢來提高系統(tǒng)對媒體流的處理能力.

實(shí)驗(yàn)室現(xiàn)有視頻會議系統(tǒng)方案采用星狀網(wǎng)絡(luò)拓?fù)溥@種傳統(tǒng)傳輸方式,系統(tǒng)客戶端采用WebRTC技術(shù)[1]進(jìn)行音視頻處理,服務(wù)端通過SIP信令集中模式對視頻會議進(jìn)行會議控制,并運(yùn)用WebRTC與SIP的轉(zhuǎn)換網(wǎng)關(guān)實(shí)現(xiàn)雙方互通,使視頻會議系統(tǒng)音視頻通話質(zhì)量有所保障,同時能夠更容易對接到IMS網(wǎng)絡(luò)[2],滿足融合通信的基本要求. 本系統(tǒng)雖然能夠正常提供音視頻通話,但當(dāng)會議組遇到網(wǎng)絡(luò)擁塞或系統(tǒng)負(fù)載過重時,系統(tǒng)本身無法改變媒體流轉(zhuǎn)發(fā)方式,更不能自適應(yīng)調(diào)整媒體流控制方式,使部分通話無法正常進(jìn)行[3].

本文通過對當(dāng)前音視頻通話方案所存在的問題進(jìn)行研究與分析,并基于實(shí)驗(yàn)室現(xiàn)有視頻會議系統(tǒng)進(jìn)行改進(jìn),提出了一種多方通話動態(tài)控制技術(shù),充分運(yùn)用會議組網(wǎng)絡(luò)中星狀拓?fù)浜途W(wǎng)狀拓?fù)涞母髯詢?yōu)點(diǎn),一方面在網(wǎng)絡(luò)通暢并且用戶數(shù)量較低情況下,發(fā)揮網(wǎng)狀拓?fù)涞谋憬菪?減輕服務(wù)器壓力; 另一方面當(dāng)系統(tǒng)發(fā)生網(wǎng)絡(luò)擁塞時,充分利用星狀拓?fù)渲蟹?wù)器集中收發(fā)媒體流的優(yōu)勢,節(jié)省網(wǎng)絡(luò)帶寬并保持通話暢通.

1 相關(guān)技術(shù)介紹

1.1 SIP協(xié)議分析

SIP(會話初始化協(xié)議)是IETF提出的一種支持多媒體會話的信令控制協(xié)議,在IP網(wǎng)絡(luò)中以其簡單、易擴(kuò)展的特性被廣泛應(yīng)用,具體工作流程如圖1.

圖1 SIP工作流程圖

SIP采用文本編碼方式,其獨(dú)立于傳輸層,屬于應(yīng)用層控制協(xié)議,主要由SIP服務(wù)器和SIP用戶代理兩個組件構(gòu)成,SIP服務(wù)器包括代理服務(wù)器、注冊服務(wù)器以及重定向服務(wù)器[4]. 在消息會話過程中,各系統(tǒng)以SDP(會話描述協(xié)議)傳遞消息內(nèi)容,各部分協(xié)同工作,讓會話更為流暢和高效[5].

1.2 MCU簡介

MCU全稱為Multi Control Unit,即多點(diǎn)控制單元,主要功能為協(xié)調(diào)和控制多個終端間的音視頻傳輸,為用戶提供群組會議服務(wù). 如圖2.

圖2 MCU傳輸方式圖

MCU將各終端的信息流同步分離,分析并提取音視頻數(shù)據(jù)和信令等信息,然后將信息送入各模塊進(jìn)行處理,完成相應(yīng)的音視頻混合與交換、路由選擇和會議控制等過程,最后將各會議場點(diǎn)所需的各種信息重新組合,發(fā)送給各客戶端.

1.3 會議系統(tǒng)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)

SIP會議系統(tǒng)模型[6]分為松耦合模式和緊耦合模式. 在緊耦合模式中存在兩種網(wǎng)絡(luò)拓?fù)湫问?分別為網(wǎng)狀拓?fù)浜托菭钔負(fù)?

在一個全聯(lián)通的網(wǎng)狀網(wǎng)絡(luò)中,存在N*(N-1)個連接,各端點(diǎn)之間相互連通能夠直接進(jìn)行數(shù)據(jù)通信,如圖3. 這種網(wǎng)絡(luò)的優(yōu)點(diǎn)在于各端點(diǎn)之間不需要媒體中繼服務(wù)器進(jìn)行媒體分發(fā)與管理,即可實(shí)現(xiàn)多方通信. 但缺點(diǎn)在于無法為大型會議系統(tǒng)提供通信服務(wù),系統(tǒng)的音視頻轉(zhuǎn)碼和混合在終端完成,且隨著網(wǎng)絡(luò)中參與者的增加,將大量消耗終端的CPU、內(nèi)存以及帶寬等資源.

圖3 4用戶全聯(lián)通網(wǎng)狀網(wǎng)絡(luò)圖

星狀網(wǎng)絡(luò)最廣泛的應(yīng)用是通過一個多點(diǎn)控制單元集中整合各終端媒體流,然后發(fā)送到每個端點(diǎn),如圖4.此類網(wǎng)絡(luò)對于網(wǎng)絡(luò)中任意客戶端,只需傳輸單個流,節(jié)省了帶寬并且減輕了CPU負(fù)載[7]. 但當(dāng)更多客戶端進(jìn)入會議后,服務(wù)器將對更多路媒體流進(jìn)行整合與轉(zhuǎn)發(fā),大量消耗服務(wù)端資源,因此服務(wù)器承載能力會成為此類網(wǎng)絡(luò)擴(kuò)展的瓶頸.

圖4 5用戶星狀網(wǎng)絡(luò)圖

2 動態(tài)控制方法的設(shè)計與實(shí)現(xiàn)

2.1 系統(tǒng)總體結(jié)構(gòu)設(shè)計

本系統(tǒng)采用SIP信令集中處理模式,實(shí)現(xiàn)視頻會議的會議控制功能,并支持SIP和WebRTC兩種類型客戶端,其中SIP客戶端可直接連接會議服務(wù)器進(jìn)行會話控制,而WebRTC客戶端在連接到WebRTC服務(wù)器后,通過WebRTC與SIP轉(zhuǎn)換網(wǎng)關(guān)實(shí)現(xiàn)雙方會議控制信息的轉(zhuǎn)換,再與會議服務(wù)器進(jìn)行交互[8]. MCU主要用來控制終端媒體流收發(fā),建立流暢的會議通話. 系統(tǒng)總體結(jié)構(gòu)如圖5.

圖5 系統(tǒng)總體結(jié)構(gòu)圖

系統(tǒng)利用終端采集本地網(wǎng)絡(luò)數(shù)據(jù)以及終端資源占用情況,并對SIP消息進(jìn)行擴(kuò)展,以擴(kuò)展后的SIP消息為載體向會議控制服務(wù)器發(fā)送各終端數(shù)據(jù).

SIP客戶端直接與會議服務(wù)器進(jìn)行連接,WebRTC客戶端則需要經(jīng)由網(wǎng)關(guān)轉(zhuǎn)換信息后才能上傳到會議服務(wù)器[9].

會議服務(wù)器包含SIP通信控制器和動態(tài)控制器兩部分,SIP通信控制器用來進(jìn)行會議控制,同時解析各終端數(shù)據(jù),并將其會話信息存入數(shù)據(jù)庫中. 動態(tài)控制器用來對終端提供的數(shù)據(jù)進(jìn)行計算和處理,建立系統(tǒng)終端連接狀態(tài)圖,并對各會議組成員進(jìn)行網(wǎng)絡(luò)和資源評估,分析會議組媒體流控制方式的各種條件,決定會議組媒體流由MCU進(jìn)行集中管理還是通過各終端自行分發(fā).

2.2 會議服務(wù)器設(shè)計

多方通話的動態(tài)控制技術(shù)以服務(wù)器為基礎(chǔ),實(shí)現(xiàn)媒體流控制變換,該系統(tǒng)的會議服務(wù)器由SIP通信控制器和動態(tài)控制器兩部分組成,圖6為服務(wù)器總體架構(gòu)圖.

圖6 服務(wù)器總體架構(gòu)圖

SIP通信控制器分為用戶代理模塊[10]、注冊服務(wù)模塊、重定向服務(wù)模塊和數(shù)據(jù)寫入模塊： 1) 用戶代理模塊,主要作用是根據(jù)目標(biāo)用戶的位置信息將SIP信令代理轉(zhuǎn)發(fā)給目標(biāo)用戶. 2) 注冊服務(wù)模塊,實(shí)現(xiàn)對用戶進(jìn)行認(rèn)證并登記用戶的位置信息. 3) 重定向服務(wù)模塊,作用為向用戶代理返回最新訪問地址列表,讓用戶代理與新的訪問地址進(jìn)行通信. 4) 數(shù)據(jù)寫入模塊,作用是將客戶端傳來的SIP消息進(jìn)行提取,從中解析出SWIT CHINFO消息內(nèi)容,并存入數(shù)據(jù)庫.

動態(tài)控制器包含數(shù)據(jù)讀取模塊、圖分析模塊和動態(tài)調(diào)整模塊3部分： 1) 數(shù)據(jù)讀取模塊,主要作用為提取數(shù)據(jù)庫中存放的通話信息,并傳遞給圖分析模塊. 2) 圖分析模塊,將數(shù)據(jù)讀取模塊傳來的信息分析處理,進(jìn)行系統(tǒng)會話連接圖的還原操作,掌握系統(tǒng)現(xiàn)存會話狀態(tài)及各終端網(wǎng)絡(luò)數(shù)據(jù),并結(jié)合終端CPU和內(nèi)存資源使用狀況,采用基于帶寬估計的擁塞檢測方法實(shí)現(xiàn)對終端擁塞情況的計算與評估. 3) 動態(tài)調(diào)整模塊,根據(jù)終端網(wǎng)絡(luò)狀況以及MCU資源占用情況,對系統(tǒng)現(xiàn)存會議組網(wǎng)絡(luò)最終作出評估,決策各會議組媒體流控制方式是否做出調(diào)整.

2.3 終端會議狀態(tài)信息采集方案設(shè)計

多方通話動態(tài)控制技術(shù)通過終端向服務(wù)器發(fā)送各用戶網(wǎng)絡(luò)狀況和資源占用情況等數(shù)據(jù),因此需要一種消息載體實(shí)現(xiàn)終端和服務(wù)器之間的數(shù)據(jù)傳遞. 針對以上問題,系統(tǒng)對SIP消息進(jìn)行擴(kuò)展,增加SWITCHINFO消息,由終端每5 s采集數(shù)據(jù),通過SWITCHINFO消息為服務(wù)器傳遞實(shí)時數(shù)據(jù).

SWITCHINFO消息內(nèi)包含sip_id,conference_id,contact_points,conference_type,和network_condition五種數(shù)據(jù). sip_id為各客戶端在服務(wù)器中的唯一標(biāo)識,conference_id 為多方通話中各會議唯一標(biāo)識,contact_points 為各客戶端媒體流分發(fā)時連接的所有端點(diǎn),內(nèi)部數(shù)據(jù)存儲為各連接端點(diǎn)的sip_id. conference_type 為通話類別,此類別分為“focus”和“dispersion”兩種,根據(jù)客戶端之間媒體流連接狀況,當(dāng)終端檢測到?jīng)]有其他端點(diǎn)與自己連接時,將conference_type賦值為“focus”,代表該會議組利用MCU為每個客戶端收發(fā)媒體流,選擇了集中控制的方式; 當(dāng)檢測本終端與若干通話終端有媒體流交互時,conference_type被賦值為“dispersion”,表明該終端媒體流處理方式為基于網(wǎng)狀網(wǎng)絡(luò)的分散處理模式.

network_condition則包含了各端點(diǎn)網(wǎng)絡(luò)狀況及CPU、內(nèi)存的使用情況,此消息中所包含字符串較多,由SIP通信服務(wù)器解析后會有以下參數(shù)存入數(shù)據(jù)庫,分別為max_bandwidth、time_interval、consumption_send、consumption_receive、num_package、time_delay、cpu_alltime、cpu_freetime、ram_maxcapacity和ram_usedcapacity. 以上各參數(shù)會分別應(yīng)用于圖分析模塊和動態(tài)調(diào)整模塊中.

下面給出SWITCHINFO方法工作流程,User A向SIP Server發(fā)送SWITCHINFO消息,向服務(wù)器傳遞各終端網(wǎng)絡(luò)信息,SIP Server響應(yīng)并返回200 OK,表明系統(tǒng)服務(wù)器已經(jīng)接收到了來自User A的SWITCHINFO消息,如圖7.

圖7 SWITCHINFO工作流程圖

2.4 圖分析方案設(shè)計與實(shí)現(xiàn)

動態(tài)控制器每5 s向數(shù)據(jù)庫讀取數(shù)據(jù),進(jìn)行會話分析及終端網(wǎng)絡(luò)評估,并以30 s為時間段檢測終端和MCU資源占用情況,在此時間段中得出6次處理結(jié)果,并根據(jù)這6次統(tǒng)計結(jié)果綜合判斷會話媒體流控制方式是否做出調(diào)整.

在媒體流控制方式調(diào)整過程中,圖分析模塊獲得最新數(shù)據(jù)后,立即執(zhí)行系統(tǒng)圖分析及還原操作,并采用基于帶寬估計的擁塞檢測方法計算各終端的可用帶寬及資源占用情況,得出其擁塞程度指標(biāo).

數(shù)據(jù)讀取模塊將SIP會議控制器存儲在數(shù)據(jù)庫中的各項(xiàng)數(shù)據(jù)進(jìn)行提取,發(fā)送給圖分析模塊進(jìn)行系統(tǒng)的圖還原操作. 圖分析模塊以conference_id作為會議群組區(qū)分,如果contact_points不為空且conference_type值為“dispersion”,控制器將各端點(diǎn) contact_points內(nèi)包含的端點(diǎn)解析出來并存儲在鄰接鏈表中,以無向圖構(gòu)造算法還原各點(diǎn)連接狀況,并計算正在進(jìn)行的各會議組內(nèi)終端數(shù)量participant_ count,以4端點(diǎn)連接為例,相關(guān)結(jié)構(gòu)如圖8和圖9.

圖分析模塊對各終端network_condition解析出的10種參數(shù)進(jìn)行轉(zhuǎn)換和計算,利用基于帶寬估計的擁塞檢測方法,求取擁塞程度指標(biāo)Q. 采用基于帶寬估計的擁塞檢測方法可實(shí)時估計終端帶寬使用情況,并將終端CPU使用率和內(nèi)存占用率一起納入終端擁塞判定標(biāo)準(zhǔn),以加權(quán)形式得到最終計算值Q,具體原理如下.

圖8 4端點(diǎn)連接圖

圖9 4端點(diǎn)鄰接鏈表圖

檢測終端最大帶寬表示為B,終端由于排隊延遲所占用的帶寬表示為Bi,外部應(yīng)用占用網(wǎng)絡(luò)帶寬為Be,則終端可用帶寬為.

Be所表示占用帶寬為接收占用帶寬和發(fā)送占用帶寬的總和,設(shè)T為采樣時間間隔,Tr為間隔內(nèi)接收數(shù)據(jù)消耗時間,Ts為間隔內(nèi)發(fā)送數(shù)據(jù)消耗時間,由公式(1)可以得出一個采樣間隔內(nèi)網(wǎng)絡(luò)占用帶寬計算值.

同時系統(tǒng)采用指數(shù)加權(quán)平均算法對實(shí)時網(wǎng)絡(luò)占用帶寬Be進(jìn)行計算,α為常數(shù)且.

排隊延遲造成的占用帶寬Bi可通過來表示,其中m代表隊列存在的數(shù)據(jù)包,n代表采樣數(shù)據(jù)包數(shù)量,Ti代表第i個包的傳輸延遲,B代表終端最大帶寬. 已知Bi與Be便可計算出Ba,進(jìn)一步求得終端帶寬使用率.

檢測終端CPU在T1到T2時間段內(nèi),總使用時間表示為T,空閑使用時間表示為Ta,可估計出CPU即時利用率. 根據(jù)從數(shù)據(jù)庫提取的參數(shù)可知終端最大內(nèi)存空間為R,已使用內(nèi)存空間為Re,可計算出內(nèi)存使用率. 由公式(2)計算得出終端擁塞程度指標(biāo)Q,β和γ均為加權(quán)系數(shù),.

圖分析模塊以5 s為時間單位對數(shù)據(jù)讀取模塊傳來的更新數(shù)據(jù)進(jìn)行處理,重構(gòu)系統(tǒng)端點(diǎn)連接圖并重新對各終端網(wǎng)絡(luò)進(jìn)行評估,并將計算出的各終端擁塞程度指標(biāo)Q連同系統(tǒng)連接圖一并交給動態(tài)調(diào)整模塊進(jìn)行下一步操作.

2.5 動態(tài)調(diào)整方案設(shè)計與實(shí)現(xiàn)

動態(tài)調(diào)整模塊接收由圖分析模塊傳來的數(shù)據(jù),同時向MCU發(fā)出消息請求,獲取MCU的CPU使用率、內(nèi)存使用率和通化路數(shù)等數(shù)據(jù). 并通過MCU資源占用的綜合評估法,得出MCU資源占用指標(biāo)M,具體方法如下.

動態(tài)控制器將MCU所傳遞數(shù)據(jù)進(jìn)行解析,獲得CPU即時利用率Ec,內(nèi)存使用率Er和通化路數(shù)He. 已知MCU最大支持通話路數(shù)H,已存在通話路數(shù)為He可得通話線路使用率. 系統(tǒng)為更全面衡量MCU資源占用情況,將3個參數(shù)進(jìn)行加權(quán)處理,綜合評估當(dāng)前MCU負(fù)載能力,得出MCU資源占用指標(biāo)M,具體公式為

動態(tài)調(diào)整模塊以conference_id作為通話組區(qū)分,利用各通話組連接圖尋找各組成員,并以各終端擁塞程度指標(biāo)Q和MCU資源占用指標(biāo)M作為標(biāo)準(zhǔn),對各會議群組的媒體流控制方式進(jìn)行評估,采用公式得出綜合評判指標(biāo)Z.

當(dāng) conference_type值為“dispersion”時,表明會議組網(wǎng)絡(luò)為網(wǎng)狀網(wǎng)絡(luò),若會議組內(nèi)所有終端存在participant_count/2以上數(shù)目綜合評判指標(biāo)Z>0.8,表明會議組內(nèi)多數(shù)終端出現(xiàn)網(wǎng)絡(luò)擁塞狀況,則該會議組必須做出調(diào)整. 若會議組內(nèi)存在participant_count/2以上數(shù)目終端綜合評判指標(biāo)0.6＜Z＜0.8,判斷會議組網(wǎng)絡(luò)將要發(fā)生擁塞,此時系統(tǒng)對本會議組進(jìn)行標(biāo)記,進(jìn)入觀察狀態(tài). 若會議組內(nèi)存在participant_count/2以上數(shù)目終端綜合評判指標(biāo)Z＜0.6,則表明會議組無需進(jìn)行調(diào)整.

當(dāng) conference_type 值為“focus”時,若會議組participant_count＜=5且MCU資源占用指標(biāo)M>0.6,則適合會議組媒體流控制方式進(jìn)行調(diào)整.

動態(tài)控制器每5 s對各會議組進(jìn)行評估并記錄,以30 s為時間段所得到的6次評估結(jié)果作為最終決策標(biāo)準(zhǔn).

若會議組6次評估結(jié)果中存在3次及以上符合調(diào)整條件,動態(tài)調(diào)整模塊向SIP會議控制器發(fā)送調(diào)整消息,由SIP會議控制器對該會議組進(jìn)行媒體流控制方式的調(diào)整,實(shí)現(xiàn)網(wǎng)狀網(wǎng)絡(luò)與星狀網(wǎng)絡(luò)之間的切換,如圖10為媒體流控制方式切換過程圖.

圖10 媒體流控制方式切換過程圖

3 測試

本次實(shí)驗(yàn)采用5臺相同配置WebRTC客戶端進(jìn)行測試,選用10 Mbps網(wǎng)絡(luò)帶寬進(jìn)行數(shù)據(jù)流傳輸,客戶端配置如表1.

表1 客戶端配置列表

多方通話建立之初,系統(tǒng)采用分散控制方式對媒體流在客戶端之間進(jìn)行收發(fā),網(wǎng)絡(luò)中則形成20條進(jìn)行數(shù)據(jù)交互的數(shù)據(jù)通路. 5臺客戶端音視頻效果均能夠滿足通話需求,系統(tǒng)運(yùn)行流暢.

然后在各客戶端運(yùn)行筆者編寫的Python程序,提高客戶端內(nèi)存和CPU占用比,將客戶端兩種資源占用率分別提高到70%和80%,同時使用WANem網(wǎng)絡(luò)模擬工具自定義網(wǎng)絡(luò)帶寬,將各客戶端可用帶寬比率控制在20%以下,此時發(fā)現(xiàn)客戶端音視頻通話出現(xiàn)卡頓現(xiàn)象,媒體流丟包嚴(yán)重. 后臺管理系統(tǒng)從圖分析模塊獲取實(shí)時數(shù)據(jù),經(jīng)過處理得到當(dāng)前會議組網(wǎng)絡(luò)狀況圖,如圖11.

圖11 調(diào)整前媒體流傳輸圖

經(jīng)過30秒后,系統(tǒng)服務(wù)器做出響應(yīng)和決策,對會議組媒體流控制方式進(jìn)行切換,將會議組網(wǎng)絡(luò)由網(wǎng)狀網(wǎng)絡(luò)切換為星狀網(wǎng)絡(luò),控制臺輸出信息如圖12.

圖12 控制臺輸出信息圖

此時,后臺管理系統(tǒng)的會議組網(wǎng)絡(luò)狀況圖發(fā)生變化,具體如圖13,表明該會議組媒體流控制方式已經(jīng)改變,并且通過分析端點(diǎn)顏色含義,說明各客戶端網(wǎng)絡(luò)狀況良好,系統(tǒng)音視頻通信運(yùn)行流暢,達(dá)到用戶通話的滿意效果.

圖13 調(diào)整后媒體流傳輸圖

4 結(jié)語

本文通過對SIP會議模型中網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的深入研究,設(shè)計了一種基于多方通話的動態(tài)控制技術(shù),將集中式和散布式兩種媒體流控制方式進(jìn)行有效結(jié)合,并在實(shí)驗(yàn)室現(xiàn)有視頻會議系統(tǒng)中予以實(shí)現(xiàn). 通過最后的測試結(jié)果,驗(yàn)證了該技術(shù)的可行性以及優(yōu)越性,當(dāng)終端發(fā)生網(wǎng)絡(luò)擁塞時系統(tǒng)能夠合理調(diào)整媒體流傳輸方式,使用戶獲得流暢通話體驗(yàn).

1Chiang CY,Chen YL,Tsai PS,et al. A video conferencing system based on webRTC for seniors. Proceedings of 2014 International Conference on Trustworthy Systems and Their Applications (TSA). Taichung,China. 2014. 51-56.

2Chen XQ,Jones HM,Jayalath ADS. Congestion-aware routing protocol for mobile ad hoc networks. Proceedings of the 66th Vehicular Technology Conference. Baltimore,MD,USA. 2007. 21-25.

3Rosenberg J. RFC 4353,A Framework for Conferencing with the Session Initiation Protocol (SIP). New York： IETF,2006.

4Rosenberg J,Schulzrinne H,Camarillo G,et al. RFC 3261,SIP： Session Initiation Protocol. New York： IETF,2002.

5竹洪濤. 一種基于SIP和WebRTC的實(shí)時可視對講方案設(shè)計[碩士學(xué)位論文]. 成都： 西南交通大學(xué),2013.

6黎忠侃. 基于SIP的視頻會議控制服務(wù)器的設(shè)計與實(shí)現(xiàn)[碩士學(xué)位論文]. 廣州： 華南理工大學(xué),2010.

7王森. SIP多方視頻會議應(yīng)用服務(wù)器設(shè)計與實(shí)現(xiàn)[碩士學(xué)位論文]. 沈陽： 中國科學(xué)院研究生院(沈陽計算技術(shù)研究所),2008.

8李冬. 一種基于WebRTC的視頻會議系統(tǒng)的架構(gòu). 智能計算機(jī)與應(yīng)用,2015,5(4)： 39-41.

9胡敏,劉六程,劉鵬. 基于WebRTC的視頻會議系統(tǒng)的設(shè)計與實(shí)現(xiàn). 電視技術(shù),2013,37(1)： 141-143,150.

10曲冠樺. 基于SIP協(xié)議的視頻會議系統(tǒng)實(shí)現(xiàn)[碩士學(xué)位論文].成都： 電子科技大學(xué),2012.