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