WebRTC 1.0 以後，那些 WebRTC API 還將發生的演進

做者：Varun Singh，Callstats.io CEO。IETF、IEEE成員，持有多項發明專利。曾是意法半導體開發工程師、Nokia技術顧問、赫爾辛基工業大學研究員。2013年，Varun Singh創辦了CALLSTATS I/O，專一於互聯網音視頻通訊的質量監測QoE。

歡迎訪問 RTC 開發者社區，與更多WebRTC開發者交流經驗。

在6月19日至20日，WebRTC 工做組進行了一次臨時會議，討論 WebRTC 的將來。 全部瀏覽器供應廠商都對WebRTC v1.0作出了很正向的評價。WebRTC v1.0在2018年6月更新修復了多個 bug。WebRTC v1.0新 API 包括：

• RTCRtpSender.setStreams()
• RTCRtpTransceiver.currentDirection
• RTCSctpTransport.maxChannels
• RTCPeerConnection.onstatsended
• RTCStatsEvent interface

在本文中，咱們一塊兒來探討下 WebRTC 可能將發生的變化。

WebRTC的應用場景

在咱們討論 WebRTC API 將來的變化以前，咱們應該考慮它的實際應用。當咱們在2011年構建 WebRTC v1.0時，咱們僅討論了幾個應用場景。自2011年以來，行業發生了許多變化，其中最引人注目的就是移動互聯網。咱們能夠經過移動應用、虛擬現實、加強現實和其餘方式，爲最終用戶提供徹底身臨其境的體驗。咱們還發現圖片的重要性也愈加明顯，交互式網站也逐漸成爲互聯網的新常態。所以，對於如今的 WebRTC API，及其將來可能出現的任何變化，都應該以這些新的應用趨勢做爲出發點來考慮。

不過，遺憾的是，如今的 WebRTC API 還沒法很好地實現或適應其中部分應用場景。所以，咱們須要強化 API 的能力。這種強化主要涉及兩方面：應用場景和開發易用性。

媒體與數據的統一

此次會議也普遍討論了媒體與數據的統一，包括幾方面：

• 多個媒體流與數據流的同步；

• IoT 設備通訊；

• 直播；

• 遊戲，包括VR/AR；

• media pipline 的控制

爲了能夠更好地控制 media pipline，會議上討論了幾個策略，包括：

可插拔擁塞控制（Pluggable Congestion Control）：有幾個可插拔擁塞控制的支持者，包括 Callstats.io。支持它的主要緣由之一就是會採用多路徑協議來作多媒體實時通信。 咱們在這個領域有長期的投入，包括在多媒體擁塞控制和相關優化方面的工做。

取代瀏覽器實現的算法：可以取代瀏覽器實現的算法，意味着開發者將能使用本身的 jitter buffer、FEC 算法（例如 LDPC，Raptor 等），編碼器和解碼器（編解碼器）等。

WebRTC 下一步的演進

在會議上，Google 的 Peter Thatcher 提出了不少 WebRTC 下一步演進的可能性。咱們接下來逐一來聊聊這些提議。

請記住，隨着 API 的每一次更新，應用開發者都將獲得對信道更好的控制。同時，也意味着 API 將變得更加複雜，但對信令的把控上將更可靠且靈活。

一般來說，咱們認爲應用開發者得到的可控性越高，就越能開發出好的產品。首先，要下降一些協議和算法爲瀏覽器開發帶來的複雜度。

其次，Web 開發者已經知道如何經過 shim 來進行更好的開發，並讓其也能被其它開發者複用。

ORTC

在 ORTC 中首次提出的幾個對象被添加到WebRTC v1.0中。 ORTC 不使用 SDP 做爲控制界面，開發者可直接控制媒體和數據傳輸通道，這一點與 WebRTC v1.0徹底不一樣。更多對象可被直接控制。例如，使用 ORTC，您可使用和控制可擴展的視頻編解碼器。

可插拔傳輸

考慮到進一步拆分 media pipeline 的對象，可插拔傳輸可實現更多對 media pipeline 控制功能。 例如，向編碼/解碼幀添加或移除元數據，或對媒體質量進行控制。

爲了實現這一點，並讓媒體傳輸更加可控。咱們須要分別將編碼器和解碼器與 RTCRtpSender 和 RTCRtpReceiver 分隔開。進一步，咱們能夠將媒體和數據分開傳輸，好比 RTP over UDP 或 QUIC 或 SCTP。 除了可插拔傳輸以外，這將可以讓大規模會議服務使用不一樣的加密密鑰進行 hop-by-hop 加密（經過DTLS / SRTP）和 end-to-end 加密。

媒體裸數據和徹底控制

提供對 pipeline 完整的控制權限，將讓 App 能夠徹底控制編碼和解碼、媒體擁塞控制、安全性（任何形式的加密），媒體幀的處理（如 FEC、RTX），以及解碼這一端的媒體同步等。這種靈活度的提高，也會須要 App 支持更多功能，須要在開發方面下更多功夫，固然，作與不作，這決定權也在開發者的手上。

小結

將有兩個方面的變化：

• 爲音頻，視頻和數據的信道中的組件建立更多對象；

• 提供訪問媒體裸數據的權限。

這些變化也將帶來一些疑問：

• 裸數據加密與否；

• JavaScript 並不具有實時性。

關於安全性的討論，咱們認爲媒體裸數據應該是加密的，並且應用不會接收未加密的數據。

關於JavaScript 的問題。若是在主線程中管理完整的 pipeline，每秒將只能處理1幀，甚至更低。所以，咱們須要一系列新的 JavaScript 和瀏覽器功能，好比 WebWorkers、WebAssembly(wasm)。除此以外，JavaScript 還會帶來其它問題，在這種狀況下， 也須要讓 Web 端能訪問媒體流，App 端能夠跟蹤預期任務狀態。

對這些 WebRTC 將可能發生的變化，以及咱們更多關於將來實時互聯網變革的想法。咱們將在 RTC 2018 實時互聯網大會上與你們進行深刻分享和探討。

Tips

WebRTC 在近期還有很新的動態。對於開發者來說，要面對不少 WebRTC 開發中的問題，Varun Singh 將在 RTC 2018 實時互聯網大會的「實時網絡與質量專場」上分享更多幹貨。與此同時，Google WebRTC 產品經理 Huib Kleinhout也將在次日的主會上分享更多 WebRTC 的將來計劃。大會門票限時免費中，席位有限，但願深刻了解的話，就趕快點擊報名吧。