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