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

聲網Agora發表於2018-07-25
WebAPI

作者：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 來進行更好的開發，並讓其也能被其它開發者複用。

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

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 的未來計劃。大會門票限時免費中，席位有限，希望深入瞭解的話，就趕快點選報名吧。

相關文章