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

RTCRtpSender.setStreams()RTCRtpTransceiver.currentDirectionRTCSctpTransport.maxChannelsRTCPeerConnection.onstatsendedRTCStatsEvent 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

Varun Singh 將在 RTC 2018 實時互聯網大會的“實時網絡與質量專場”上分享更多干貨與 WebRTC 的近期動態，席位有限，希望深入了解的話，就趕快掃碼報名吧。