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

吳宏森, 李建洋

(鎮江市高等專科學校 電氣電競與交通學院, 江蘇 鎮江 212003)

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

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

1 系統設計方案

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

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

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

圖1 系統流程圖

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

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

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

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

2 數據庫設計

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

圖2 功能流程圖

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

3 音視頻會話設計與實現

3.1 P2P通信設計原理

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

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

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

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

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

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

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

圖3 系統架構圖

3.2 音視頻輔導功能的實現

音視頻會話模式分為對等網絡模式和服務器模式。

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

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

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

3.3 會話模塊

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

3.3.1 建立會話流程

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

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

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

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

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

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

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

3.3.2 接通會話

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

3.3.3 音視頻處理和網絡傳輸

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

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

4 結果與分析

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

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

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

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

5 結語

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