作者：Varun Singh，Callstats.io CEO堕绩，RTC 2018 實時互聯(lián)網(wǎng)大會受邀演講嘉賓策幼。
在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 可能將發(fā)生的變化。
WebRTC的應用場景
在我們討論 WebRTC API 未來的變化之前滤钱，我們應該考慮它的實際應用觉壶。當我們在2011年構建 WebRTC v1.0時，我們僅討論了幾個應用場景件缸。自2011年以來铜靶，行業(yè)發(fā)生了許多變化，其中最引人注目的就是移動互聯(lián)網(wǎng)他炊。我們可以通過移動應用争剿、虛擬現(xiàn)實、增強現(xiàn)實和其他方式痊末，為最終用戶提供完全身臨其境的體驗蚕苇。我們還發(fā)現(xiàn)圖片的重要性也越發(fā)明顯，交互式網(wǎng)站也逐漸成為互聯(lián)網(wǎng)的新常態(tài)凿叠。因此涩笤，對于現(xiàn)在的 WebRTC API，及其未來可能出現(xiàn)的任何變化盒件，都應該以這些新的應用趨勢作為出發(fā)點來考慮蹬碧。
不過，遺憾的是炒刁，現(xiàn)在的 WebRTC API 還無法很好地實現(xiàn)或適應其中部分應用場景恩沽。因此，我們需要強化 API 的能力翔始。這種強化主要涉及兩方面：應用場景和開發(fā)易用性罗心。
媒體與數(shù)據(jù)的統(tǒng)一
這次會議也廣泛討論了媒體與數(shù)據(jù)的統(tǒng)一片吊，包括幾方面：
多個媒體流與數(shù)據(jù)流的同步；
IoT 設備通信协屡；
直播俏脊；
游戲，包括VR/AR肤晓；
media pipline 的控制
為了可以更好地控制 media pipline爷贫，會議上討論了幾個策略，包括：
可插拔擁塞控制（Pluggable Congestion Control）：有幾個可插拔擁塞控制的支持者补憾，包括 Callstats.io漫萄。支持它的主要原因之一就是會采用多路徑協(xié)議來做多媒體實時通訊。 我們在這個領域有長期的投入盈匾，包括在多媒體擁塞控制和相關優(yōu)化方面的工作腾务。
取代瀏覽器實現(xiàn)的算法：能夠取代瀏覽器實現(xiàn)的算法，意味著開發(fā)者將能使用自己的 jitter buffer削饵、FEC 算法（例如 LDPC岩瘦，Raptor 等），編碼器和解碼器（編解碼器）等窿撬。
WebRTC 下一步的演進
在會議上启昧，Google 的 Peter Thatcher 提出了很多 WebRTC 下一步演進的可能性。我們接下來逐一來聊聊這些提議劈伴。
請記住密末，隨著 API 的每一次更新，應用開發(fā)者都將得到對信道更好的控制跛璧。同時严里，也意味著 API 將變得更加復雜，但對信令的把控上將更可靠且靈活追城。
通常來講刹碾，我們認為應用開發(fā)者獲得的可控性越高，就越能開發(fā)出好的產(chǎn)品漓柑。首先教硫，要降低一些協(xié)議和算法為瀏覽器開發(fā)帶來的復雜度叨吮。
其次辆布，Web 開發(fā)者已經(jīng)知道如何通過 shim 來進行更好的開發(fā)，并讓其也能被其它開發(fā)者復用茶鉴。
ORTC
在 ORTC 中首次提出的幾個對象被添加到WebRTC v1.0中锋玲。 ORTC 不使用 SDP 作為控制界面，開發(fā)者可直接控制媒體和數(shù)據(jù)傳輸通道涵叮，這一點與 WebRTC v1.0完全不同惭蹂。更多對象可被直接控制伞插。例如，使用 ORTC盾碗，您可以使用和控制可擴展的視頻編解碼器媚污。
可插拔傳輸
考慮到進一步拆分 media pipeline 的對象，可插拔傳輸可實現(xiàn)更多對 media pipeline 控制功能廷雅。 例如耗美，向編碼/解碼幀添加或移除元數(shù)據(jù)，或?qū)γ襟w質(zhì)量進行控制航缀。
為了實現(xiàn)這一點商架，并讓媒體傳輸更加可控。我們需要分別將編碼器和解碼器與 RTCRtpSender 和 RTCRtpReceiver 分隔開芥玉。進一步蛇摸，我們可以將媒體和數(shù)據(jù)分開傳輸，比如 RTP over UDP 或 QUIC 或 SCTP灿巧。 除了可插拔傳輸之外赶袄，這將能夠讓大規(guī)模會議服務使用不同的加密密鑰進行 hop-by-hop 加密（通過DTLS / SRTP）和 end-to-end 加密。
媒體裸數(shù)據(jù)和完全控制
提供對 pipeline 完整的控制權限抠藕，將讓 App 可以完全控制編碼和解碼弃鸦、媒體擁塞控制、安全性（任何形式的加密）幢痘，媒體幀的處理（如 FEC唬格、RTX），以及解碼這一端的媒體同步等颜说。這種靈活度的提升购岗，也會需要 App 支持更多功能，需要在開發(fā)方面下更多功夫门粪，當然喊积，做與不做，這決定權也在開發(fā)者的手上玄妈。
小結
將有兩個方面的變化：
????1. 為音頻乾吻，視頻和數(shù)據(jù)的信道中的組件創(chuàng)建更多對象；
? ? 2. 提供訪問媒體裸數(shù)據(jù)的權限拟蜻。
這些變化也將帶來一些疑問：
????1. 裸數(shù)據(jù)加密與否绎签；
????2. JavaScript 并不具備實時性。
關于安全性的討論酝锅，我們認為媒體裸數(shù)據(jù)應該是加密的诡必，而且應用不會接收未加密的數(shù)據(jù)。
關于JavaScript 的問題搔扁。如果在主線程中管理完整的 pipeline爸舒，每秒將只能處理1幀蟋字，甚至更低。因此扭勉，我們需要一系列新的 JavaScript 和瀏覽器功能鹊奖，比如 WebWorkers、WebAssembly(wasm)涂炎。除此之外嫉入，JavaScript 還會帶來其它問題，在這種情況下璧尸， 也需要讓 Web 端能訪問媒體流咒林，App 端可以跟蹤預期任務狀態(tài)。
對這些 WebRTC 將可能發(fā)生的變化爷光，以及我們更多關于未來實時互聯(lián)網(wǎng)變革的想法垫竞。我們將在 RTC 2018 實時互聯(lián)網(wǎng)大會上與大家進行深入分享和探討。
Tips
Varun Singh 將在 RTC 2018 實時互聯(lián)網(wǎng)大會的“實時網(wǎng)絡與質(zhì)量專場”上分享更多干貨與 WebRTC 的近期動態(tài)蛀序，席位有限欢瞪，希望深入了解的話，就趕快報名吧徐裸。
