WebRTC標準化狀況

每年，我都會在IIT-RTC會議上與許多WebRTC標準人員進行交流，這場疫情顯然讓今年有所不同。雖然我們在今年的Kranky Geek會議上確實談到了標準化和“WebRTC的未來”，但我們沒有時間深入研究更多細節(jié)，所以我們將在這里討論。

Bernard在實時通信領域有著長久而卓越的職業(yè)生涯。除了W3C WebRTCCo-Chair 的角色之外，他還是WEBTRANS和AVTCORE工作組的Co-Chair以及ORTC、WebRTC-SVC、WebRTC-NV Use Cases、WebRTC-ICE、WebTransport和WebRTC-QUIC文檔的編輯。不要忘記，WebRTC在IETF中也是部分標準化的，同時Bernard也是WEBTRANS和AVTCORE WGs的Co-Chair。在微軟，他是微軟團隊媒體組織的首席架構師，該組織名為IC3，支持微軟團隊和基于團隊基礎設施的其他項目，如Azure通信服務(Gustavo在此發(fā)布了相關信息)。

WebRTC標準化狀況 作為W3C WebRTC工作組的Chair之一，Bernard是WebRTC標準化過程中的權威人物。我首先向他詢問了工作組目前的章程。

Bernard：正如在2020年4月在W3C的演講中所討論的，WebRTC 工作組章程描述了三個領域的工作： 1. 完成第一優(yōu)先的網(wǎng)絡實時通信對等連接（WebRTC-PC），以及網(wǎng)絡實時通信統(tǒng)計等相關規(guī)范，例如WebRTC-Stats。 2. 捕獲、流和輸出相關規(guī)范，包括媒體捕獲和流、屏幕捕獲、從DOM元素中捕獲媒體、媒體流圖像捕獲、媒體流錄制、音頻輸出設備和內(nèi)容提示。 3. WebRTC-NV，WebRTC的“下一個版本”。 WebRTC-NV是WebRTC的“下一個版本”。這是當前1.0規(guī)范之后的內(nèi)容。

Bernard：WebRTC-NV的工作分為四大類。 1. 一類是WebRTC對等連接的擴展。這包括WebRTC擴展，WebRTC-SVC和可插入流。我要提到的是，網(wǎng)絡實時傳輸中心建議和所有依賴于實時傳輸中心連接的工作都需要RTCPeerConnection“統(tǒng)一計劃”，這是所有瀏覽器中默認的SDP語言。例如，如果不首先支持“統(tǒng)一計劃”，就不可能利用可插入流在您的應用程序中支持端到端加密。 2. 第二類涉及不符合WebRTC-PC建議中包含的實施或成熟度要求的功能，如WebRTC Identity、WebRTC Priority Control和WebRTC DSCP。 3. 第三類是對Capture的擴展，如MediaStreamTrack可插入流，Media Capture和Streams擴展以及MediaCapture深度流擴展(最近恢復)。 4. 第四類是我所說的獨立規(guī)范，它不一定依賴于RTCPeerConnection或現(xiàn)有的Media Capture規(guī)范。WebRTC-ICE(目前已經(jīng)作為獨立的規(guī)范實現(xiàn))屬于這一類，W3C WEBRTC工作組之外開發(fā)的API規(guī)范也屬于這一類，如WebTransport(W3C WebTransport工作組)、WebRTC-QUIC(ORTC工作組)和WebCodecades(WICG工作組)。 鑒于不同的工作類別，“NV”一詞有些模糊，可能會使人困惑。該術語最初指的是ORTC，但今天它通常指的是多個規(guī)范，而不是一個文件。在當前的用法中，有模糊之處，因為“NV”可能指的是RTCPeerConnection和現(xiàn)有捕獲應用程序接口的擴展，或者與RTCPeerConnection或現(xiàn)有捕獲應用程序接口無關的應用程序接口，如WebTransport 和WebCodecs。因此，當有人提到“WebRTC-NV”時，通常有必要詢問后續(xù)問題，以了解他們想要的潛在含義。 成為完整推薦的途徑 WebRTC中使用的協(xié)議是由IETF定義的，而W3C定義了瀏覽器使用的API。W3C的正式標準化之路——以及關于應該包括什么的爭論——有時是一個有爭議的話題。 Bernard給出了這個過程的一些背景和狀態(tài)。 Chad：你能帶領我們的觀眾梳理一遍W3C規(guī)范階段嗎？ Bernard：第一個標準化階段是CR-候選人推薦。候選人推薦意味著該規(guī)范已經(jīng)過廣泛審查，符合工作組的要求，并且是可實施的。在CR，規(guī)范可能沒有完全實現(xiàn)(那里可能存在“功能風險”)，瀏覽器之間可能存在互通性問題。 您在這（https://www.w3.org/2020/Process-20200915/）可以看到描述的全部過程細節(jié)。 Chad：你說的最后一個CR，我猜是暗示可以有多個CR，或者說CR過程是一個多階段的事情？ Bernard：還有一個新的W3C過程，在這個過程中，基本上你有實時的規(guī)范。我們只能說，在我們就這兩個問題提出建議之前，我們已經(jīng)是最后一個了。 所以PR [Proposed Recommendation]是你試圖證明規(guī)范中的所有內(nèi)容都已經(jīng)實現(xiàn)并且通過了你的互通性標準的階段。然后是推薦，甚至更遠。下一步是PR，我們正在收集你需要的所有數(shù)據(jù)。在對等連接的情況下，這是大量的數(shù)據(jù)，因為您需要所有的互操作測試，包括您的WPT測試結果，還可能包括您的KITE測試結果。

WPT是指Web平臺測試，這是W3C檢查API實現(xiàn)的一組測試。結果位于https://wpt.fyi。

KITE是一個開源的互通性測試項目，專門針對WebRTC。Alex Gouaillard博士在他的博客帖子《轉折點：SFU博客負載測試》中討論了這一點。

Chad：WPT是 wpt.fyi ，這是一種通用的自動化特性測試，而KITE是WebRTC特定的互操作測試。 Bernard：WPT網(wǎng)絡廣播公司的測試運行在單一的瀏覽器上。我們在WPT沒有針對網(wǎng)絡實時傳輸?shù)姆掌鳒y試，但是有針對網(wǎng)絡傳輸?shù)姆掌鳒y試。因此，WebRTC WPT測試沒有展示瀏覽器之間或瀏覽器和會議服務器之間的互操作性，而KITE測試是在瀏覽器和潛在的多個實體之間進行的。 Chad：這是WebRTC特有的——你實際上是在向不同的瀏覽器發(fā)送媒體。 Bernard：為了理解WPT測試覆蓋率的水平，我們已經(jīng)對規(guī)范進行了注釋。因此，除了測試結果之外，你還想知道測試實際覆蓋了多少規(guī)范。 新冠疫情減緩了標準工作 WebRTC對WebRTC產(chǎn)生了一些有趣的影響。這讓我們WebRTC社區(qū)的所有人都忙得不可開交，更加關注所有新流量的可擴展性和可靠性。然而，這種焦點的改變會對現(xiàn)有的過程造成很大的破壞。這也適用于標準化工作嗎？ Bernard：底線是，我們正在努力收集所有這些證據(jù)，我們將向W3C提交這些證據(jù)，以表明我們已經(jīng)為建議階段做好了準備。這是非常大的一步，但進展被病毒拖慢了。我的意思是，我們認為我們會在實施過程中取得更大的進展，但病毒已經(jīng)讓每個人都慢了下來。 Chad：那是因為人們忙于做支持他們產(chǎn)品的事情，還是因為實際上你們不能經(jīng)常聚在一起？ Bernard：新冠疫情打亂了很多事情。例如，KITE互操作測試通常是在IETF活動中親自進行的，但是我們還沒有能夠親自參加IETF。我們一直在努力弄清楚如何才能完成測試，但如果沒有每個人都在同一個地方，這很難。如果你在世界各地，在同一時間同一地點組織每個人的能力真的很難。想象一下，現(xiàn)在是凌晨3點，你需要和世界另一端不同時區(qū)的人進行互操作性測試。 這場全球性的疫情不僅破壞了測試，而且還影響了實施計劃，如融合圖所示。雖然建議中的幾乎所有功能都已經(jīng)在至少一個瀏覽器中實現(xiàn)，但我們最初認為，到2020年秋季，我們將在兩個或多個瀏覽器代碼庫中實現(xiàn)更多功能。因此，實施進度和測試都不是我們所期望的。

資料來源：TPAC-2020-Meetings https://docs.google.com/presentation/d/1WHocMl47fukck4YQ6RuPzfagAj6bW0SjUELzwguC3qs/edit#slide=id.ga427533723_4_218 標準化有多重要？ 在過去的幾年里，幾乎每一個更新的Web瀏覽器都實現(xiàn)了WebRTC。WebRTC正在支持世界上很大一部分的IP語音(VoIP)流量。在這一點上，進入標準化的下一個階段是否重要？ Bernard指出，標準化不僅僅是編寫規(guī)范——它實際上是關于互操作性的。 Bernard：標準化把注意力集中在測試和穩(wěn)定性上。WebRTC對等連接的最大挑戰(zhàn)之一就是它的廣度。我們每天都只是從重要的bug中學習。我們發(fā)現(xiàn)我們的覆蓋面并不是我們理想中的樣子。我們還了解到，即使是我所說的可接受的測試覆蓋率，也是多么困難。最近出現(xiàn)了一堆像復用這樣的問題，它們實際上對現(xiàn)有的服務有很大的影響，我們沒有對它們進行測試。我們在這些錯誤身上看到的是，它們不是WPT遇到的那種問題。本質(zhì)上需要像KITE框架這樣的東西來做的事情，我們在KITE中還沒有達到百分之百的測試覆蓋率。 總的來說，我在實時通信和網(wǎng)絡其他方面經(jīng)歷的最大區(qū)別之一是測試矩陣的巨大規(guī)模。如果我告訴你Chad，我想讓你去開發(fā)，得到95%的覆蓋率。我認為通過測試的過程是有幫助的，但它也讓我們意識到真正涵蓋一切的挑戰(zhàn)的規(guī)模。這很艱難。 WebRTC擴展 你可以用WebRTC做的事情越來越多。正如Bernard剛才提到的，WebRTC 1.0正在通過標準過程，所以他們必須在某個地方添加新功能。正如Bernard將解釋的那樣，WebRTC擴展是一些沒有進入WebRTC 1.0的功能的家園。 Bernard：有一系列的規(guī)范依賴于RTCPeerConnection。WebRTC擴展就是其中之一。這些是為WebRTC PC增加功能的規(guī)范。這里有很多東西，例如，實時傳輸協(xié)議報頭擴展加密。WebRTC SVC（可拓展視頻編碼）不在WebRTC擴展文檔中，但我認為它是一個擴展。我認為可插入流是WebRTC PC（其編碼版本）的擴展，它的編碼版本。這些都是在假設你有RTCPeerConnection的基礎上。 getCurrentBrowsingContextMedia 隨著視頻會議使用的增加，已經(jīng)有幾個關于網(wǎng)絡攝像頭出錯和意外屏幕共享的高調(diào)故事。與此同時，快速訪問網(wǎng)絡攝像頭通常是WebRTC服務的一個問題。平衡訪問速度和隱私控制是一個難題。此外，使用getMediaDevices提供的媒體設備信息進行指紋識別一直是一項隱私挑戰(zhàn)。 getCurrentBrowsingContextMedia提案是解決這些挑戰(zhàn)的一種嘗試。 Chad：我們能報道一下getCurrentBrowsingContextMedia媒體提案嗎？ Bernard：這真是一個擴展，我認為這是對屏幕截圖的擴展。讓我來談談[媒體]的捕獲問題——捕獲的很多焦點都集中在隱私和安全上。我們發(fā)現(xiàn)媒體捕捉流對隱私并沒有什么好處。假設你將為應用程序提供設備上的所有信息，無論它們是否被選中，然后讓它創(chuàng)建自己的選擇器。這是指紋識別的一個真正問題，因為現(xiàn)在我知道你機器上的所有設備。即使你不想用那個相機，但我知道它在那里。因此，這真的有助于識別你的指紋，Jan-Ivar一直建議我們轉向另一種更類似于屏幕截圖的模型。 在屏幕捕捉中，你只能訪問用戶選擇的捕捉表面。所以，我不能訪問你所有的應用程序，我可以看到每個窗口，然后我決定作為一個應用程序來購買我想看的東西?，F(xiàn)在用戶選擇了源，您只能訪問它。這是Jan-Ivar提出的媒體捕捉和流模式。本質(zhì)上，它將成為瀏覽器選擇器的一部分。該應用程序只能訪問用戶選擇的設備上的信息。這是一個很大的變化。它也對媒體捕捉和screams的一些基礎提出了質(zhì)疑。例如，如果用戶無論如何都要選擇，那么約束的目的是什么？ Chad：這是否意味著更多關于設備選擇器的規(guī)范？ Bernard：我認為它的作用是。然而，我們已經(jīng)決定將我們的模型進行或多或少改進。然后， Jan-Ivar 為這個新模型創(chuàng)建了一個單獨的規(guī)范，可以解決所有這些問題。棘手的是，這是一個非常不同的模式。當人們習慣于應用選擇器時，如何過渡到新的模式？這可能從用戶習慣來看需要很長時間。

WebRTC NV 標準之爭的一個后果是不愿意指定正式的版本名稱，因為每個人對什么是主要版本(即1.0、2.0)和次要版本(即1.1、1.2等)有不同的看法。曾經(jīng)也有一個被稱為ORTC的替代推薦，有時被定位為WebRTC的繼任者，我們將在一個大型的。WebRTC 1.0圍繞我們討論的當前規(guī)范進行了整合。盡管如此，關于接下來會發(fā)生什么仍有很多爭論。他們最終決定用一個非常溫和、不精確的術語來命名接下來的一切：“WebRTC下一個版本”或WebRTC-NV。 Bernard解釋了這意味著什么。 Chad：我們談了一點關于我們將在“下一個版本”的WebRTC中看到什么——我想我們不會稱之為2.0，因為1.0還沒有完成？ Bernard：我想也許是時候我們應該考慮去掉整個NV這個術語了，因為它實際上可以指兩種潛在的非常不同的東西。一個是我提到的對等連接的擴展——比如可插入流、WebRTC擴展、WebRTC SVC。我的想法是，當你把所有這些規(guī)格放在一起時，它們加起來的功能水平和ORTC一樣。因此，我們已經(jīng)將大部分ORTC對象模型整合到了WebRTC PC中。 另一個非常獨立的軌道是我所說的獨立規(guī)格。這包括像網(wǎng)絡傳輸、WebCodecs、網(wǎng)絡實時通信等——這些都是完全獨立的東西，不依賴于RTCPeerConnection。所以這真的是下一代與現(xiàn)在的一種決裂。 顯然，還早著呢。WebTransport是一個原始試用版。WebCodecs是Chrome的原始試用版?，F(xiàn)在，這是非常不同的，因為你曾經(jīng)作為整體WebRTC PC的一部分獲得的許多東西現(xiàn)在必須用Web Assembly編寫。所以這是一個非常非常不同的開發(fā)模型。 有些東西不在那里。例如WebTransport現(xiàn)在本質(zhì)上是客戶端服務器。我們已經(jīng)編寫了一個對等擴展，不久前有一個最初的試用版，但是現(xiàn)在是客戶端服務器。因此，您不能只使用現(xiàn)有的WebCodecs和網(wǎng)絡傳輸來編寫完整的WebRTC PC用例。 我要說的是，在WebRTC NV中發(fā)生的另一件事已經(jīng)變得非常重要，那就是人們對機器學習和訪問原始媒體有了真正的關注。這是ORTC沒有提供的。在某種意義上，我想說的是，網(wǎng)絡傳輸或WebCodecs模型在這方面甚至比ORTC還低。ORTC沒有讓你直接訪問解碼器和編碼器。這就是你從WebCodecs中得到的。所以我認為我們采納了ORTC的想法，并將其應用到更低的傳輸層。 ORTC怎么了？ 對象實時傳輸控制(ORTC)是網(wǎng)絡實時傳輸控制的一個替代模型，它提供了不使用軟件開發(fā)平臺的低級控制。Bernard是它的作者之一，微軟在ORTC的支持下推出了最初的Edge。我們再也聽不到很多關于ORTC的事情了，那么它發(fā)生了什么？正如Bernard剛才解釋的那樣，大部分內(nèi)容都被吸收到了WebRTC的核心標準中。這是ORTC愿景的失敗還是勝利？ Chad：你是ORTC原始規(guī)范的作者之一。與您最初的ORTC愿景相比，您認為我們現(xiàn)在的狀況如何？ Bernard：對象模型完全在Chromium瀏覽器中。因此，我們幾乎擁有了來自ORTC的所有對象——Ice Transport、DTLS Transport傳輸、SCTP Transport (來自數(shù)據(jù)通道)——所有這些對象現(xiàn)在都在WebRTC PC和Chromium瀏覽器中。 RTC也有先進的功能，如聯(lián)播和SVC，我們已經(jīng)納入。此外，我們有比原始的ORTC通過端到端加密，可以通過可插入的流支持。因此，我們已經(jīng)用對象模型和所有這些擴展將WebRTC PC等同于ORTC。 我們期待的場景是像物聯(lián)網(wǎng)這樣只關注數(shù)據(jù)傳輸?shù)臇|西。您可以看到這反映在WebRTC和用例中——這些場景就像對等數(shù)據(jù)交換一樣。 網(wǎng)絡傳輸 WebTransport是W3C的另一個規(guī)范，有自己的工作組和規(guī)范。你會看到很多熟悉的涉及WebRTC 的名字，包括Bernard。 QUIC是一種改進的傳輸協(xié)議——有點像網(wǎng)絡傳輸可以使用的“TCP/2”。 Chad：那么什么是WebTransport，它是從哪里來的，和WebRTC有什么關系呢？ Bernard：網(wǎng)絡傳輸既是一個API，又是W3C網(wǎng)絡傳輸組的成員。它也是IETF中的一系列協(xié)議——一系列傳輸。協(xié)議包括QUIC上的網(wǎng)絡傳輸，稱為QUIC傳輸，也包括HTTP/3和潛在的HTTP/2上的網(wǎng)絡傳輸。所以W3C中的網(wǎng)絡傳輸API只適用于QUIC和HTTP/3。HTTP/2被認為是一種故障轉移傳輸，它可能有一個單獨的API。那個API是客戶端服務器API。構造函數(shù)和一切都很像WebSocket。在構造函數(shù)網(wǎng)絡傳輸構造函數(shù)中，你給它一個網(wǎng)址，然后你會得到一個網(wǎng)絡傳輸。但是它是不同的，因為您可以創(chuàng)建可靠的流和數(shù)據(jù)報。 Chad：數(shù)據(jù)包，就像UDP中用于快速但不可靠的傳輸一樣。 Bernard：它是雙向的，也就是說，一旦網(wǎng)絡傳輸由客戶端發(fā)起，但是一旦連接建立，服務器可以向客戶端發(fā)起單向雙向流，數(shù)據(jù)報可以來回流動。 Chad：雙向，就像雙向通信一樣？ Bernard：WebSocket實際上只是客戶端。WebSocket不能由服務器啟動，但網(wǎng)絡傳輸可以。在基于QUIC的網(wǎng)絡傳輸中，連接不是共享的。在針對HTTP/3的網(wǎng)絡傳輸中，它可以被匯集在一起——這創(chuàng)造了一系列非常有趣的場景，其中一些場景恢復了IETF BoF。考慮一下，你可以同時進行HTTP/3請求-響應和網(wǎng)絡傳輸，包括流，以及在同一個QIUC連接上的數(shù)據(jù)報。 這是Justin Uberti為IETF的一個名為RIPT BOF的項目設計的一個場景，讓人們大吃一驚。在這種情況下，你有一個來回的RPC-請求-響應，但RPC-導致從服務器到客戶端的流。所以把它想象成一個客戶說，我想播放這部電影，或者玩這個游戲，再或者參加這個視頻會議，然后一個可能是可靠的QUIC流的流，或者可能是一個來自服務器的數(shù)據(jù)報流。 我認為WebTransport有潛力給網(wǎng)絡帶來革命性的變化。HTTP/3本身就是對Web的革命性改變。這場革命的大部分是在更復雜的版本中，即HTTP/3池傳輸。QUIC傳輸要簡單得多，它只給了我一個socket，我可以在上面來回發(fā)送東西。 Chad：WebTransport還有多遠？ Bernard：我想說WebTransport API現(xiàn)在已經(jīng)相當完善了，它剛剛完成它的原始測試，試用版本以M88結束。有幾個bug，有些東西不太好用，但是API比較打磨。您可以用它編寫一個相當復雜的示例代碼。我想這是因為我們用實際代碼更新了規(guī)范。所以如果你讀了這個規(guī)范，你就可以用代碼來做這些事情了。希望我們很快會在那里提供一個完整的例子，你可以嘗試一下。 在服務器端，仍然有一些QUIC互操作問題。所以我認為人們使用的服務器是aioquic（Python庫），你也可以使用quiche作為服務器，但是它沒有集成到框架中。不幸的是，我們沒有Node.JS服務器，擁有它真的很好——那可能很遙遠。 Chad：正如Bernard所說，WebTransport是客戶端服務器，而不是像WebRTC那樣的對等(P2P)。然而，我們已經(jīng)看到了P2P QUIC的預覽版。事實上，F(xiàn)ippo早在2019年2月就在QUIC數(shù)據(jù)頻道上寫了一篇文章。與這種新的網(wǎng)絡傳輸方法相比有何不同？ Bernard：那是ORTC風格的。它不支持WHATWG/W3C流，也是基于gQUIC協(xié)議，而不是IETF的QUIC。WebTransport——代碼在Chrome中——基于WHATWG流，也基于IETF QUIC。所以RTCQuicTransport代碼非常過時，因為它既是一個舊的API，也是一個舊的協(xié)議。那個代碼已經(jīng)從Chromium中刪除了。 Chad：那么，對于低延遲的場景，我們?nèi)绾螌崿F(xiàn)Peer-to-Peer WebTransport呢？ Bernard：我們有一個小的擴展規(guī)范，它仍然在ORTC CG中?；旧险J為它只是一個WebTransport，但是你讓它運行在RTCIceTransport上，而不是一個URL上。所以要做構建，你不給它一個URL，而是給它一個ICE Transport。 你就是這么構造的。有一些ORTC的東西基本上是從RTCDtlsTransport中提取的，你可以添加到對等的東西中。但是擴展規(guī)范只有幾頁。它非常非常小，就像95%的網(wǎng)絡傳輸規(guī)范完全一樣。 Chad：有人構建過嗎？ Bernard：我們還沒有新的應用編程接口和新的QUIC庫的工作版本。沒有新東西的版本。RTCQuicTransport的一個特點是它是獨立的。今天Chromium中有一個代碼，叫做WebRTC ICE。想象一下從網(wǎng)絡實時傳輸中心到PC的洲際交易所傳輸——這是一個獨立的實時傳輸中心版本。當您從一個RTCQuicTransport構造一個RTCQuicTransport時，它不會與您的對等連接組件復用。 它在一個單獨的端口上?，F(xiàn)在我們不得不在過去的RTCQuicTransport中這樣做，因為gQUIC不能與RTP/RTCP STUN和TURN復用。IETF QUIC可以復用。 Chad：gQUIC是來自谷歌的QUIC的原版。這聽起來可能會對IP端口的使用產(chǎn)生很大影響，捆綁有助于通過防火墻限制端口使用。 Bernard：開發(fā)人員會希望在同一個端口上使用QUIC作為他們所有其他的音頻和視頻工具嗎？如今在WebRTC PC中，捆綁銷售非常非常流行。每個人都在同一個端口上把所有東西推在一起——這遠遠超過了WebRTC所有使用的99%。有人可能會認為QUIC會有類似的需求。如果這是他們真正想要的，我們不想用ORTC風格化的交通工具來建造(快速傳輸)；你希望能夠從一個網(wǎng)絡傳輸中心的PC上構建它。 這有點奇怪，因為現(xiàn)在你說部分網(wǎng)絡傳輸依賴于RTCPeerConnection。

RPC設置以通過WebTransport發(fā)送媒體。來源：IETF 107 – Justin Uberti，107-ript-rtc-implementation-experiences（https://www.ietf.org/proceedings/107/slides/slides-107-ript-rtc-implementation-experiences-00） Simulcasts WebTransport似乎是一種全新的潛在處理方式。但如今困擾WebRTC實現(xiàn)的一些棘手問題主要是，幾乎每一個主要的WebRTC視頻會議服務中都有Simulcast，參與者眾多，并且在標準化和互操作性方面一直處于掙扎狀態(tài)。 Chad：Simulcasts是如何進行的？ Bernard：據(jù)稱，在Chromium中，所有編解碼器都支持with simulcast，或者至少是現(xiàn)在所有的編解碼器。因此，從理論上講，你應該能夠使用H.264，VP8和VP9做到這一點。 我們一直在尋找錯誤，也遇到過一些非常可怕的錯誤，例如H264無法正常工作。我們已經(jīng)進行了完整的KITE測試，但是還需要一個簡單的回送測試測試基本操作，你可以在其中向自己發(fā)送Simulcast。最終Fippo編寫了回送測試。 如果你想查看該測試，在Fippo的“simulcast playground”（https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/）帖子中。 Bernard：該測試并未在所有瀏覽器上通過。它之所以沒有通過，是因為你發(fā)送了RID，被SDP欺騙了，并以MID的形式接收了它們。因此，從本質(zhì)上講，如果你發(fā)送了三個流，則可以取回三個流，但是它們各自位于不同的MID上。 Firefox不支持MID RTP標頭擴展。所以，實際上該環(huán)回測試無效。 我們發(fā)現(xiàn)無論何時編寫測試，都會發(fā)現(xiàn)一些不太清楚的地方。 我再給你舉一個奇怪的例子，我們一直在進行硬件加速方面的工作。事實證明，當你使用硬件加速器時，可以獲得不同的比特流。它不僅使事情變得更快，實際上是改變了編解碼器的比特流，然后你就可以開始破壞互操作了。你進行了Simulcast測試，突然SFU無法處理即將發(fā)生的一切。我真的希望我們能夠在這些IETF會議之一中親自見面，進行另一次Simulcast測試，就像Alex博士能夠做的那樣，看看我們在哪里。 你知道，如果每個人都在交付統(tǒng)一計劃，我們會很好。 Chad：統(tǒng)一計劃是一種新的、標準化的SDP格式，除其他外，它指定了應如何在SDP中處理聯(lián)播流。統(tǒng)一計劃不應該成為節(jié)省一天的規(guī)范嗎？而我們?yōu)槭裁礇]有這么做？ Bernard：如果每個人都對所有編解碼器都使用統(tǒng)一計劃，并且[互操作測試]都很高興，那么你會知道一切正常。我們還不在附近。讓我這樣說–我們功能完善。我認為這是事實，但是事情在測試范圍內(nèi)不斷下滑。我不會說每個瀏覽器都具有發(fā)布商業(yè)應用程序所需的所有功能。舉例來說，例如，我認為確實有很多商業(yè)應用程序都在多個瀏覽器上發(fā)布，但我認為在所有瀏覽器上都發(fā)布的應用很少。 因此，考慮到這種情況的一種方法（可能比所有這些測試結果要容易一些）是，如果你對所有主要會議服務及其運行的所有瀏覽器以及所有不同的模式進行了矩陣分析，則可能會發(fā)現(xiàn)最好看看我們實際上在哪里。 一直以來這都不是很令人鼓舞。多數(shù)服務都支持大多數(shù)瀏覽器是很好的，但是你經(jīng)常會看到各種功能支持以及跨瀏覽器的稍微不同的體驗。

由于原文篇幅較長，為保證讀者的閱讀體驗，本文后半部分內(nèi)容將安排在下周發(fā)布。

責任編輯：lq