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

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

WebRTC標(biāo)準(zhǔn)化狀況 作為W3C WebRTC工作組的Chair之一，Bernard是WebRTC標(biāo)準(zhǔn)化過程中的權(quán)威人物。我首先向他詢問了工作組目前的章程。

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

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

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

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

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

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

RPC設(shè)置以通過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視頻會議服務(wù)中都有Simulcast，參與者眾多，并且在標(biāo)準(zhǔn)化和互操作性方面一直處于掙扎狀態(tài)。 Chad：Simulcasts是如何進行的？ Bernard：據(jù)稱，在Chromium中，所有編解碼器都支持with simulcast，或者至少是現(xiàn)在所有的編解碼器。因此，從理論上講，你應(yīng)該能夠使用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標(biāo)頭擴展。所以，實際上該環(huán)回測試無效。 我們發(fā)現(xiàn)無論何時編寫測試，都會發(fā)現(xiàn)一些不太清楚的地方。 我再給你舉一個奇怪的例子，我們一直在進行硬件加速方面的工作。事實證明，當(dāng)你使用硬件加速器時，可以獲得不同的比特流。它不僅使事情變得更快，實際上是改變了編解碼器的比特流，然后你就可以開始破壞互操作了。你進行了Simulcast測試，突然SFU無法處理即將發(fā)生的一切。我真的希望我們能夠在這些IETF會議之一中親自見面，進行另一次Simulcast測試，就像Alex博士能夠做的那樣，看看我們在哪里。 你知道，如果每個人都在交付統(tǒng)一計劃，我們會很好。 Chad：統(tǒng)一計劃是一種新的、標(biāo)準(zhǔn)化的SDP格式，除其他外，它指定了應(yīng)如何在SDP中處理聯(lián)播流。統(tǒng)一計劃不應(yīng)該成為節(jié)省一天的規(guī)范嗎？而我們?yōu)槭裁礇]有這么做？ Bernard：如果每個人都對所有編解碼器都使用統(tǒng)一計劃，并且[互操作測試]都很高興，那么你會知道一切正常。我們還不在附近。讓我這樣說–我們功能完善。我認為這是事實，但是事情在測試范圍內(nèi)不斷下滑。我不會說每個瀏覽器都具有發(fā)布商業(yè)應(yīng)用程序所需的所有功能。舉例來說，例如，我認為確實有很多商業(yè)應(yīng)用程序都在多個瀏覽器上發(fā)布，但我認為在所有瀏覽器上都發(fā)布的應(yīng)用很少。 因此，考慮到這種情況的一種方法（可能比所有這些測試結(jié)果要容易一些）是，如果你對所有主要會議服務(wù)及其運行的所有瀏覽器以及所有不同的模式進行了矩陣分析，則可能會發(fā)現(xiàn)最好看看我們實際上在哪里。 一直以來這都不是很令人鼓舞。多數(shù)服務(wù)都支持大多數(shù)瀏覽器是很好的，但是你經(jīng)常會看到各種功能支持以及跨瀏覽器的稍微不同的體驗。

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

責(zé)任編輯：lq