- RTCRtpSender.setStreams（）
- RTCRtpTransceiver.currentDirection
- RTCSctpTransport.maxChannels
- RTCPeerConnection.onstatsended
- TCStatsEvent interface
在本文中，我們一起來探討下 WebRTC 可能將發(fā)生的變化。
WebRTC的應(yīng)用場景
在我們討論 WebRTC API 未來的變化之前，我們應(yīng)該考慮它的實際應(yīng)用。當(dāng)我們在2011年構(gòu)建 WebRTC v1.0時，我們僅討論了幾個應(yīng)用場景。自2011年以來，行業(yè)發(fā)生了許多變化，其中最引人注目的就是移動互聯(lián)網(wǎng)。我們可以通過移動應(yīng)用、虛擬現(xiàn)實、增強(qiáng)現(xiàn)實和其他方式，為最終用戶提供完全身臨其境的體驗。我們還發(fā)現(xiàn)圖片的重要性也越發(fā)明顯，交互式網(wǎng)站也逐漸成為互聯(lián)網(wǎng)的新常態(tài)。因此，對于現(xiàn)在的 WebRTC API，及其未來可能出現(xiàn)的任何變化，都應(yīng)該以這些新的應(yīng)用趨勢作為出發(fā)點來考慮。
不過，遺憾的是，現(xiàn)在的 WebRTC API 還無法很好地實現(xiàn)或適應(yīng)其中部分應(yīng)用場景。因此，我們需要強(qiáng)化 API 的能力。這種強(qiáng)化主要涉及兩方面：應(yīng)用場景和開發(fā)易用性。
媒體與數(shù)據(jù)的統(tǒng)一
這次會議也廣泛討論了媒體與數(shù)據(jù)的統(tǒng)一，包括幾方面：
- 多個媒體流與數(shù)據(jù)流的同步；
- IoT 設(shè)備通信；
- 直播；
- 游戲，包括VR/AR；
- media pipline 的控制
為了可以更好地控制 media pipline，會議上討論了幾個策略，包括：
- 可插拔擁塞控制（Pluggable Congestion Control）：有幾個可插拔擁塞控制的支持者，包括 Callstats.io。支持它的主要原因之一就是會采用多路徑協(xié)議來做多媒體實時通訊。 我們在這個領(lǐng)域有長期的投入，包括在多媒體擁塞控制和相關(guān)優(yōu)化方面的工作。
- 取代瀏覽器實現(xiàn)的算法：能夠取代瀏覽器實現(xiàn)的算法，意味著開發(fā)者將能使用自己的 jitter buffer、FEC 算法（例如 LDPC，Raptor 等），編碼器和解碼器（編解碼器）等。
WebRTC 下一步的演進(jìn)
在會議上，Google 的 Peter Thatcher 提出了很多 WebRTC 下一步演進(jìn)的可能性。我們接下來逐一來聊聊這些提議。
請記住，隨著 API 的每一次更新，應(yīng)用開發(fā)者都將得到對信道更好的控制。同時，也意味著 API 將變得更加復(fù)雜，但對信令的把控上將更可靠且靈活。
通常來講，我們認(rèn)為應(yīng)用開發(fā)者獲得的可控性越高，就越能開發(fā)出好的產(chǎn)品。首先，要降低一些協(xié)議和算法為瀏覽器開發(fā)帶來的復(fù)雜度。
其次，Web 開發(fā)者已經(jīng)知道如何通過 shim 來進(jìn)行更好的開發(fā)，并讓其也能被其它開發(fā)者復(fù)用。
ORTC
在 ORTC 中首次提出的幾個對象被添加到WebRTC v1.0中。 ORTC 不使用 SDP 作為控制界面，開發(fā)者可直接控制媒體和數(shù)據(jù)傳輸通道，這一點與 WebRTC v1.0完全不同。更多對象可被直接控制。例如，使用 ORTC，您可以使用和控制可擴(kuò)展的視頻編解碼器。
可插拔傳輸
考慮到進(jìn)一步拆分 media pipeline 的對象，可插拔傳輸可實現(xiàn)更多對 media pipeline 控制功能。 例如，向編碼/解碼幀添加或移除元數(shù)據(jù)，或?qū)γ襟w質(zhì)量進(jìn)行控制。
為了實現(xiàn)這一點，并讓媒體傳輸更加可控。我們需要分別將編碼器和解碼器與 RTCRtpSender 和 RTCRtpReceiver 分隔開。進(jìn)一步，我們可以將媒體和數(shù)據(jù)分開傳輸，比如 RTP over UDP 或 QUIC 或 SCTP。 除了可插拔傳輸之外，這將能夠讓大規(guī)模會議服務(wù)使用不同的加密密鑰進(jìn)行 hop-by-hop 加密（通過DTLS / SRTP）和 end-to-end 加密。
媒體裸數(shù)據(jù)和完全控制
提供對 pipeline 完整的控制權(quán)限，將讓 App 可以完全控制編碼和解碼、媒體擁塞控制、安全性（任何形式的加密），媒體幀的處理（如 FEC、RTX），以及解碼這一端的媒體同步等。這種靈活度的提升，也會需要 App 支持更多功能，需要在開發(fā)方面下更多功夫，當(dāng)然，做與不做，這決定權(quán)也在開發(fā)者的手上。
小結(jié)
將有兩個方面的變化：
- 為音頻，視頻和數(shù)據(jù)的信道中的組件創(chuàng)建更多對象；
- 提供訪問媒體裸數(shù)據(jù)的權(quán)限。
這些變化也將帶來一些疑問：
- 裸數(shù)據(jù)加密與否；
- JavaScript 并不具備實時性。
關(guān)于安全性的討論，我們認(rèn)為媒體裸數(shù)據(jù)應(yīng)該是加密的，而且應(yīng)用不會接收未加密的數(shù)據(jù)。
關(guān)于JavaScript 的問題。如果在主線程中管理完整的 pipeline，每秒將只能處理1幀，甚至更低。因此，我們需要一系列新的 JavaScript 和瀏覽器功能，比如 WebWorkers、WebAssembly（wasm）。除此之外，JavaScript 還會帶來其它問題，在這種情況下， 也需要讓 Web 端能訪問媒體流，App 端可以跟蹤預(yù)期任務(wù)狀態(tài)。
對這些 WebRTC 將可能發(fā)生的變化，以及我們更多關(guān)于未來實時互聯(lián)網(wǎng)變革的想法。我們將在 RTC 2018 實時互聯(lián)網(wǎng)大會上與大家進(jìn)行深入分享和探討。
Tips
Varun Singh 將在 RTC 2018 實時互聯(lián)網(wǎng)大會的“實時網(wǎng)絡(luò)與質(zhì)量專場”上分享更多干貨與 WebRTC 的近期動態(tài)，席位有限，希望深入了解的話，就趕快掃碼報名吧。
