基于WebRTC技術的移動實驗輔導平臺構建

吳宏森, 李建洋

(鎮(zhèn)江市高等?？茖W校 電氣電競與交通學院, 江蘇 鎮(zhèn)江 212003)

基于MOOC(massive open online courses)的移動實驗學習是變被動學習為主動學習,實現(xiàn)翻轉課堂的重要手段[1-2]。教師從學生的操作中發(fā)現(xiàn)問題并進行有針對性的指導和問題解答,從而達到更好的教學效果[3]。MOOC的規(guī)模和開放性使得學生可以自由獲取海量學習內容[4-6],在實驗實踐教學指導環(huán)節(jié)具有非常好的教學效果。學生可以利用手機提前預習實驗實踐過程,快速熟悉實驗環(huán)境和注意事項。實訓教師可以將自己的知識和經(jīng)驗——特別是書本上沒有提到,但是在生產(chǎn)活動中會遇到的特殊情況和特別重要的知識點,通過MOOC視頻分享給學生[7]。

MOOC采用短視頻、過程測驗、在線交流、在線考核等環(huán)節(jié),建立了一種新型的在線學習模式。但目前基于安卓的移動實驗平臺并未提供實驗輔導、答疑工具和音視頻直播輔助通道[8]。因此,要實現(xiàn)理想的MOOC實驗平臺,必須增加移動端的音視頻直播和師生交互應用功能[9],滿足實驗過程中師生互動的需要。本文采用HTML5、WebRTC技術設計了一個基于WebRTC技術的移動實驗輔導平臺。該平臺既可以滿足移動端和PC端的同步使用；又可以提供低成本音視頻交互輔助通道。HTML5可以實現(xiàn)跨平臺無障礙訪問；WebRTC技術可以用較低的成本實現(xiàn)傳統(tǒng)移動實驗平臺沒有的音視頻交互功能,滿足師生雙向交流的需要。這對于課下實驗輔導非常必要。

1 系統(tǒng)設計方案

本文設計的基于HTML5和WebRTC技術的MOOC移動實驗輔導平臺,主要提供MOOC實驗課程的瀏覽和播放、存儲和管理課程資源、在線討論、跨平臺跨系統(tǒng)無障礙訪問,實現(xiàn)師生多人音視頻交流,實現(xiàn)學生公選課的移動教學。平臺提供教學系統(tǒng)的學分管理接口,實現(xiàn)精品課程教學資源支撐,實現(xiàn)高校優(yōu)質學習資源的共享,對社會提供知識服務。

基于WebRTC技術的移動實驗輔導平臺主要為學生課余實訓學習提供學習資源和音視頻輔導服務,實現(xiàn)“課堂翻轉”[10]。該平臺包括精品課程、公選課程、大眾課程、學分管理、音視頻輔導、在線考核、綜合測評等欄目。

系統(tǒng)流程圖如圖1所示。用戶通過4G/WiFi接入校園網(wǎng),登錄服務器并完成注冊。校內人員實名認證后可以免費使用資源。

圖1 系統(tǒng)流程圖

用戶分為教師用戶和學生用戶。學生用戶由班主任實名認證,教師用戶的身份由系統(tǒng)管理員實名認證。

教師用戶可以通過平臺發(fā)布和瀏覽MOOC課程視頻資料,學生用戶能瀏覽和下載視頻資料,可以發(fā)送學習需求信息和定制實訓課程。

移動實驗輔導平臺專設留言和解答界面,用戶可以對課程內容進行提問和討論。對于學生的提問,由課程教師團隊每日定時解答,系統(tǒng)提供音視頻直播,由教師發(fā)起、學生用戶參與,同屏提供音視頻服務、電子白板、文字討論區(qū)。

通過對傳統(tǒng)實訓平臺進行研究,滿足實驗教學的一般需求,設計了平臺的功能流程(見圖2)。流程包括教育規(guī)劃、需求分析、課程創(chuàng)建、在線討論、線下學習、課程評價等主要功能。

2 數(shù)據(jù)庫設計

Redis數(shù)據(jù)庫的使用不必像關系型數(shù)據(jù)庫那樣需先設計表的結構和關系。Redis數(shù)據(jù)庫沒有表概念,可以隨時根據(jù)需要非常方便地增加字段。在研發(fā)NoSQL數(shù)據(jù)庫時,可以邊設計、邊實現(xiàn),后續(xù)增加的字段對前面無影響,非常適合快速開發(fā)系統(tǒng)。

圖2 功能流程圖

Redis是一個鍵值對數(shù)據(jù)庫,只能通過鍵查找值,而不能通過值查找鍵。在進行數(shù)據(jù)庫設計時,必須考慮系統(tǒng)需要,進行檢索的關鍵字都要建立對應的記錄。非關系型數(shù)據(jù)庫的設計更注重速度而不是存儲空間。傳統(tǒng)的關系型數(shù)據(jù)庫,數(shù)據(jù)是存放在硬盤里的,任何查詢操作都需要先讀取硬盤,然后加載內存；而Redis是一個內存數(shù)據(jù)庫,所有數(shù)據(jù)都在內存當中,不用花費讀取硬盤的時間,直接在內存中讀取數(shù)據(jù),處理更加迅速。由于Redis基于內存操作,因而需要的服務器內存越大越好,當用戶數(shù)量足夠多時,可以考慮采用云計算服務器集群技術進行快速擴展[11]。

3 音視頻會話設計與實現(xiàn)

3.1 P2P通信設計原理

客戶端之間采用對等網(wǎng)絡(peer-to-peer networking)模式交換音視頻信息,但是部分任務仍然需要服務器的介入。有4個階段任務需要服務器參與處理:

(1) 客戶端獲取移動MOOC實訓課程平臺的服務,要通過訪問Web服務器獲取信息；

(2) 在通信過程中,客戶端需要交換數(shù)據(jù)，如信令(signaling)、會話控制信息以及處理錯誤信息、元數(shù)據(jù)、網(wǎng)絡數(shù)據(jù)等,需要服務器的中介和處理；

(3) 不在相同網(wǎng)段的通信雙方穿透NAT和防火墻時,需要STUN服務器、TURN服務器的中介和處理；

(4) 對等網(wǎng)絡適合小規(guī)模、低成本的音視頻服務；而中大規(guī)模擴展服務需要專門的流媒體服務器進行音視頻的壓縮處理和轉發(fā)。

通信過程中,通信雙方處于平等地位。每一個客戶端同時充當客戶端和服務器的角色,二者之間可以直接通信,傳遞數(shù)據(jù)量較大的音視頻信息。WebRTC在建立點對點連接時采用ICE協(xié)議,能夠穿透全錐型、限制錐型以及對稱型NAT和防火墻。ICE協(xié)議最重要的特點是融合了STUN和TURN協(xié)議,能夠提供更加高效的公網(wǎng)候選地址。

通信開始,ICE協(xié)議首先嘗試直接連接另一方客戶端。如果能夠順利連通,說明該客戶端在公網(wǎng)環(huán)境或者通信雙方在相同網(wǎng)段；否則開始嘗試使用STUN協(xié)議,連接該客戶端對應的NAT公網(wǎng)地址。若成功連通,則說明該客戶端處于非對稱性NAT；若仍然失敗,則說明該客戶端處于對稱型NAT,必須使用TURN服務器進行中轉(見圖3)。

圖3 系統(tǒng)架構圖

3.2 音視頻輔導功能的實現(xiàn)

音視頻會話模式分為對等網(wǎng)絡模式和服務器模式。

在對等網(wǎng)絡模式下,用戶之間端對端連接,視頻和音頻的傳遞不經(jīng)過服務器,因此成本低、安全性和實時性高,適合中小型交合服務場景。根據(jù)客戶端設備性能和網(wǎng)絡帶寬的不同,對等網(wǎng)絡模式下最大可以支持數(shù)百人的中型會話。

服務器模式面向大型的交互會話。在該模式下,音視頻流經(jīng)過服務器壓縮轉發(fā)給其他客戶端,能支持人數(shù)更多的會話。

本移動實驗輔導平臺采取低成本的對等網(wǎng)絡模式進行音視頻會話功能設計。

3.3 會話模塊

HTML5新增了Audio和Video標簽,不需安裝插件就可以通過瀏覽器播放音頻和視頻。音視頻會話模塊是整個平臺最難實現(xiàn)的核心模塊,涉及建立通信、接入、音視頻處理和網(wǎng)絡傳輸?shù)恼麄€流程。

3.3.1 建立會話流程

為避免音視頻會話的無效使用,造成系統(tǒng)負擔過大和系統(tǒng)不穩(wěn)定,只有教師身份才有開通實時會話的權限、設定實時會話功能參數(shù),例如指定參與對象為特定的學生或者指定班級成員對象。這個階段會有一個建立連接的過程。教師客戶端發(fā)起信令(signaling)請求后,首先會建立一個連接池(connection pool),然后與流媒體服務器和Web服務器建立連接。流媒體服務器向本地客戶端添加通信的各個用戶信息和監(jiān)控媒體流的變化,本地客戶端發(fā)起請求給服務器,服務器向遠程學生客戶端發(fā)起連接請求,同意后建立連接。

會話(session)建立時,授課涉及到的教師、課程、學生ID等信息存入會話的自定義參數(shù)組(customized dataset)中,以供連接各方調用。默認情況下,會話僅在1天內有效,通過服務器實時生成。會話發(fā)起者在任一時間只可以創(chuàng)建1個會話,因為根據(jù)實際情況,教師也不可能同時為多個班級學生輔導。

學生客戶端若要連入會話,需要有效的令牌(token),令牌由會話生成。會話創(chuàng)建后,生成的會話ID(session ID)在會話生成端進行存儲和維護。會話代表授課“容器”,那么令牌就是進入的“門卡”,用來驗證用戶的身份和權限。一個令牌只對應一個會話,會話和令牌是一對多的關系。

令牌分為兩類：課程發(fā)布者(publisher)和課程訂閱者(subscriber)。某一時間點上只有會話發(fā)布者有權發(fā)布視頻、音頻、文字、文件、共享屏幕和白板等；而訂閱者此時只能接收這些信息,在其需要發(fā)布權限的時候提出請求,由會話發(fā)布者授權后才有臨時發(fā)布權限,同時發(fā)布者有強制取消和刪除的權利。

使用會話之前,需要通過“Session.Connect”創(chuàng)建連接,創(chuàng)建成功后觸發(fā)Connected事件,并回調獲取所有在線用戶的令牌,之后可以通過Session.Send函數(shù)給所有相關訂閱者發(fā)送自己的Stream對象,或使用Session.SendTo函數(shù)給某個具體用戶發(fā)送Stream對象,如果需要在連接時增加額外的信息,可以通過發(fā)送的對象里增加Attribute屬性。

在發(fā)送Stream之后,如果連接成功,本地觸發(fā)Local事件,回調返回本地通道Sender。遠程觸發(fā)Remote事件,回調返回遠程通道Receiver。

連接成功后,可以監(jiān)聽In事件,在其他人連入此Session時觸發(fā)。此時可以發(fā)送本次討論內容提要和課件等相關信息,回調返回連入人的令牌；同樣可以監(jiān)聽Out事件,在其他人退出此Session時觸發(fā)斷開連接Disconnected事件?？梢酝ㄟ^Session.Disconnect函數(shù)主動斷開Session連接。

3.3.2 接通會話

遠程客戶端接到發(fā)送端會話請求后,服務器將其加入會話發(fā)起者建立的連接池,與會話服務器和Web服務器建立連接。隨后,服務器向本地客戶端發(fā)送信令(signaling)消息,本地客戶端添加媒體流給服務器,同時服務器監(jiān)控本地媒體流的變化情況。最后,本地客戶端與遠程客戶端之間開始直接會話。

3.3.3 音視頻處理和網(wǎng)絡傳輸

音視頻引擎采用了WebRTC技術。WebRTC為基于瀏覽器的音視頻功能開發(fā)提供了一個開發(fā)框架,實現(xiàn)了音視頻采集、編碼、傳輸、顯示的全部功能。音視頻引擎通過會話發(fā)起端的攝像頭采集本地音視頻數(shù)據(jù)并編碼,然后經(jīng)過網(wǎng)絡傳輸層,由音視頻會話服務器發(fā)送到各個音視頻會話客戶端?？蛻舳送ㄟ^Chrome瀏覽器WebRTC技術進行數(shù)據(jù)的接收和處理。最后,處理好的音視頻流在客戶終端上播放。

本系統(tǒng)采用了VP8編解碼技術。VP8能以較少的數(shù)據(jù)通信實現(xiàn)高質量的視頻傳輸,并且只需較低的處理能力即可播放視頻,專為低遲延而設計開發(fā),特別適合應用于基于瀏覽器的音視頻通信系統(tǒng)。

4 結果與分析

建立了系統(tǒng)測試環(huán)境。利用學校公網(wǎng)服務器搭建Web服務器、STUN服務器和TURN服務器,PC和Android智能終端安裝最新的Chrome瀏覽器。

我校教師每年都要帶畢業(yè)班學生做畢業(yè)設計,學生還要到校外完成畢業(yè)實習,且95%的實習在外地進行,為教師的畢業(yè)設計輔導帶來了很大的困擾。本系統(tǒng)的構建提供了一個很好的畢業(yè)設計遠程實驗輔導手段。作為本系統(tǒng)的測試案例,在系統(tǒng)中開設一個畢業(yè)設計指導課程,制作了“信息系統(tǒng)設計畢業(yè)設計指導及規(guī)范”MOOC課程,進行遠程實驗指導和視頻輔導,測試了全組討論等音視頻會話功能。教師可以隨時查閱學生參與課程學習的記錄,對畢業(yè)設計的工作量進行統(tǒng)計備案。

在手機界面上,有教師的視頻圖像、參與視頻輔導的學生的視頻圖像和電子白板區(qū)域。由于手機屏幕顯示范圍較小,只能顯示1位教師和4位學生的視頻圖像,但可以通過滑動屏幕顯示其他在線的學生的圖像。電子白板顯示的圖像可以放大至全屏,能更好地看清課件信息。測試結果顯示,觀看和下載MOOC課程功能正常,視頻會話輔導效果良好,語音清晰、圖像流暢,基本達到了設計目標。

經(jīng)實際測量,語音通信實時碼率為35～40 KB/s,視頻通信為620～700 KB/s。教師端在4 MB/s已可以滿足5畫面同時視頻交流,如學生端需要減少移動流量消耗,可以只打開音頻會話,輔導45 min只消耗流量1.8 MB。目前普通家庭寬帶、移動4G和局域網(wǎng)環(huán)境都可以滿足這一速率要求。

5 結語

基于WebRTC技術的移動實驗輔導平臺,系統(tǒng)地融合了目前先進的HTML5和WebRTC技術,實現(xiàn)了一種新穎的視頻會話功能和結構,可用于視頻會議、網(wǎng)絡課堂、網(wǎng)絡社交中。由于實驗條件和成本的考量,目前該平臺只能滿足一對多實時遠程教學輔導。進一步的研究將采用多點控制單元MCU(multipoint control nit),在大量參與者之間分發(fā)流媒體。MCU是一個起到橋梁作用的服務器,可以應對不同的分辨率、編解碼器和幀速率的多人音視頻通信,可做選擇性流媒體的轉發(fā),混合音頻和視頻流。但這種服務方式需要添加MCU服務器,進行音視頻的壓縮和轉發(fā),也會增加實驗成本。