WebRTC标准化状况-电子发烧友网

每年，我都会在IIT-RTC会议上与许多WebRTC标准人员进行交流，这场疫情显然让今年有所不同。虽然我们在今年的Kranky Geek会议上确实谈到了标准化和“WebRTC的未来”，但我们没有时间深入研究更多细节，所以我们将在这里讨论。

Bernard在实时通信领域有着长久而卓越的职业生涯。除了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在此发布了相关信息)。

WebRTC标准化状况作为W3C WebRTC工作组的Chair之一，Bernard是WebRTC标准化过程中的权威人物。我首先向他询问了工作组目前的章程。

Bernard：正如在2020年4月在W3C的演讲中所讨论的，WebRTC 工作组章程描述了三个领域的工作： 1. 完成第一优先的网络实时通信对等连接（WebRTC-PC），以及网络实时通信统计等相关规范，例如WebRTC-Stats。 2. 捕获、流和输出相关规范，包括媒体捕获和流、屏幕捕获、从DOM元素中捕获媒体、媒体流图像捕获、媒体流录制、音频输出设备和内容提示。 3. WebRTC-NV，WebRTC的“下一个版本”。 WebRTC-NV是WebRTC的“下一个版本”。这是当前1.0规范之后的内容。

Bernard：WebRTC-NV的工作分为四大类。 1. 一类是WebRTC对等连接的扩展。这包括WebRTC扩展，WebRTC-SVC和可插入流。我要提到的是，网络实时传输中心建议和所有依赖于实时传输中心连接的工作都需要RTCPeerConnection“统一计划”，这是所有浏览器中默认的SDP语言。例如，如果不首先支持“统一计划”，就不可能利用可插入流在您的应用程序中支持端到端加密。 2. 第二类涉及不符合WebRTC-PC建议中包含的实施或成熟度要求的功能，如WebRTC Identity、WebRTC Priority Control和WebRTC DSCP。 3. 第三类是对Capture的扩展，如MediaStreamTrack可插入流，Media Capture和Streams扩展以及MediaCapture深度流扩展(最近恢复)。 4. 第四类是我所说的独立规范，它不一定依赖于RTCPeerConnection或现有的Media Capture规范。WebRTC-ICE(目前已经作为独立的规范实现)属于这一类，W3C WEBRTC工作组之外开发的API规范也属于这一类，如WebTransport(W3C WebTransport工作组)、WebRTC-QUIC(ORTC工作组)和WebCodecades(WICG工作组)。鉴于不同的工作类别，“NV”一词有些模糊，可能会使人困惑。该术语最初指的是ORTC，但今天它通常指的是多个规范，而不是一个文件。在当前的用法中，有模糊之处，因为“NV”可能指的是RTCPeerConnection和现有捕获应用程序接口的扩展，或者与RTCPeerConnection或现有捕获应用程序接口无关的应用程序接口，如WebTransport 和WebCodecs。因此，当有人提到“WebRTC-NV”时，通常有必要询问后续问题，以了解他们想要的潜在含义。成为完整推荐的途径 WebRTC中使用的协议是由IETF定义的，而W3C定义了浏览器使用的API。W3C的正式标准化之路——以及关于应该包括什么的争论——有时是一个有争议的话题。 Bernard给出了这个过程的一些背景和状态。 Chad：你能带领我们的观众梳理一遍W3C规范阶段吗？ Bernard：第一个标准化阶段是CR-候选人推荐。候选人推荐意味着该规范已经过广泛审查，符合工作组的要求，并且是可实施的。在CR，规范可能没有完全实现(那里可能存在“功能风险”)，浏览器之间可能存在互通性问题。您在这（https://www.w3.org/2020/Process-20200915/）可以看到描述的全部过程细节。 Chad：你说的最后一个CR，我猜是暗示可以有多个CR，或者说CR过程是一个多阶段的事情？ Bernard：还有一个新的W3C过程，在这个过程中，基本上你有实时的规范。我们只能说，在我们就这两个问题提出建议之前，我们已经是最后一个了。所以PR [Proposed Recommendation]是你试图证明规范中的所有内容都已经实现并且通过了你的互通性标准的阶段。然后是推荐，甚至更远。下一步是PR，我们正在收集你需要的所有数据。在对等连接的情况下，这是大量的数据，因为您需要所有的互操作测试，包括您的WPT测试结果，还可能包括您的KITE测试结果。

WPT是指Web平台测试，这是W3C检查API实现的一组测试。结果位于https://wpt.fyi。

KITE是一个开源的互通性测试项目，专门针对WebRTC。Alex Gouaillard博士在他的博客帖子《转折点：SFU博客负载测试》中讨论了这一点。

Chad：WPT是 wpt.fyi ，这是一种通用的自动化特性测试，而KITE是WebRTC特定的互操作测试。 Bernard：WPT网络广播公司的测试运行在单一的浏览器上。我们在WPT没有针对网络实时传输的服务器测试，但是有针对网络传输的服务器测试。因此，WebRTC WPT测试没有展示浏览器之间或浏览器和会议服务器之间的互操作性，而KITE测试是在浏览器和潜在的多个实体之间进行的。 Chad：这是WebRTC特有的——你实际上是在向不同的浏览器发送媒体。 Bernard：为了理解WPT测试覆盖率的水平，我们已经对规范进行了注释。因此，除了测试结果之外，你还想知道测试实际覆盖了多少规范。新冠疫情减缓了标准工作 WebRTC对WebRTC产生了一些有趣的影响。这让我们WebRTC社区的所有人都忙得不可开交，更加关注所有新流量的可扩展性和可靠性。然而，这种焦点的改变会对现有的过程造成很大的破坏。这也适用于标准化工作吗？ Bernard：底线是，我们正在努力收集所有这些证据，我们将向W3C提交这些证据，以表明我们已经为建议阶段做好了准备。这是非常大的一步，但进展被病毒拖慢了。我的意思是，我们认为我们会在实施过程中取得更大的进展，但病毒已经让每个人都慢了下来。 Chad：那是因为人们忙于做支持他们产品的事情，还是因为实际上你们不能经常聚在一起？ Bernard：新冠疫情打乱了很多事情。例如，KITE互操作测试通常是在IETF活动中亲自进行的，但是我们还没有能够亲自参加IETF。我们一直在努力弄清楚如何才能完成测试，但如果没有每个人都在同一个地方，这很难。如果你在世界各地，在同一时间同一地点组织每个人的能力真的很难。想象一下，现在是凌晨3点，你需要和世界另一端不同时区的人进行互操作性测试。这场全球性的疫情不仅破坏了测试，而且还影响了实施计划，如融合图所示。虽然建议中的几乎所有功能都已经在至少一个浏览器中实现，但我们最初认为，到2020年秋季，我们将在两个或多个浏览器代码库中实现更多功能。因此，实施进度和测试都不是我们所期望的。

资料来源：TPAC-2020-Meetings https://docs.google.com/presentation/d/1WHocMl47fukck4YQ6RuPzfagAj6bW0SjUELzwguC3qs/edit#slide=id.ga427533723_4_218 标准化有多重要？在过去的几年里，几乎每一个更新的Web浏览器都实现了WebRTC。WebRTC正在支持世界上很大一部分的IP语音(VoIP)流量。在这一点上，进入标准化的下一个阶段是否重要？ Bernard指出，标准化不仅仅是编写规范——它实际上是关于互操作性的。 Bernard：标准化把注意力集中在测试和稳定性上。WebRTC对等连接的最大挑战之一就是它的广度。我们每天都只是从重要的bug中学习。我们发现我们的覆盖面并不是我们理想中的样子。我们还了解到，即使是我所说的可接受的测试覆盖率，也是多么困难。最近出现了一堆像复用这样的问题，它们实际上对现有的服务有很大的影响，我们没有对它们进行测试。我们在这些错误身上看到的是，它们不是WPT遇到的那种问题。本质上需要像KITE框架这样的东西来做的事情，我们在KITE中还没有达到百分之百的测试覆盖率。总的来说，我在实时通信和网络其他方面经历的最大区别之一是测试矩阵的巨大规模。如果我告诉你Chad，我想让你去开发，得到95%的覆盖率。我认为通过测试的过程是有帮助的，但它也让我们意识到真正涵盖一切的挑战的规模。这很艰难。 WebRTC扩展你可以用WebRTC做的事情越来越多。正如Bernard刚才提到的，WebRTC 1.0正在通过标准过程，所以他们必须在某个地方添加新功能。正如Bernard将解释的那样，WebRTC扩展是一些没有进入WebRTC 1.0的功能的家园。 Bernard：有一系列的规范依赖于RTCPeerConnection。WebRTC扩展就是其中之一。这些是为WebRTC PC增加功能的规范。这里有很多东西，例如，实时传输协议报头扩展加密。WebRTC SVC（可拓展视频编码）不在WebRTC扩展文档中，但我认为它是一个扩展。我认为可插入流是WebRTC PC（其编码版本）的扩展，它的编码版本。这些都是在假设你有RTCPeerConnection的基础上。 getCurrentBrowsingContextMedia 随着视频会议使用的增加，已经有几个关于网络摄像头出错和意外屏幕共享的高调故事。与此同时，快速访问网络摄像头通常是WebRTC服务的一个问题。平衡访问速度和隐私控制是一个难题。此外，使用getMediaDevices提供的媒体设备信息进行指纹识别一直是一项隐私挑战。 getCurrentBrowsingContextMedia提案是解决这些挑战的一种尝试。 Chad：我们能报道一下getCurrentBrowsingContextMedia媒体提案吗？ Bernard：这真是一个扩展，我认为这是对屏幕截图的扩展。让我来谈谈[媒体]的捕获问题——捕获的很多焦点都集中在隐私和安全上。我们发现媒体捕捉流对隐私并没有什么好处。假设你将为应用程序提供设备上的所有信息，无论它们是否被选中，然后让它创建自己的选择器。这是指纹识别的一个真正问题，因为现在我知道你机器上的所有设备。即使你不想用那个相机，但我知道它在那里。因此，这真的有助于识别你的指纹，Jan-Ivar一直建议我们转向另一种更类似于屏幕截图的模型。在屏幕捕捉中，你只能访问用户选择的捕捉表面。所以，我不能访问你所有的应用程序，我可以看到每个窗口，然后我决定作为一个应用程序来购买我想看的东西。现在用户选择了源，您只能访问它。这是Jan-Ivar提出的媒体捕捉和流模式。本质上，它将成为浏览器选择器的一部分。该应用程序只能访问用户选择的设备上的信息。这是一个很大的变化。它也对媒体捕捉和screams的一些基础提出了质疑。例如，如果用户无论如何都要选择，那么约束的目的是什么？ Chad：这是否意味着更多关于设备选择器的规范？ Bernard：我认为它的作用是。然而，我们已经决定将我们的模型进行或多或少改进。然后， Jan-Ivar 为这个新模型创建了一个单独的规范，可以解决所有这些问题。棘手的是，这是一个非常不同的模式。当人们习惯于应用选择器时，如何过渡到新的模式？这可能从用户习惯来看需要很长时间。

WebRTC NV 标准之争的一个后果是不愿意指定正式的版本名称，因为每个人对什么是主要版本(即1.0、2.0)和次要版本(即1.1、1.2等)有不同的看法。曾经也有一个被称为ORTC的替代推荐，有时被定位为WebRTC的继任者，我们将在一个大型的。WebRTC 1.0围绕我们讨论的当前规范进行了整合。尽管如此，关于接下来会发生什么仍有很多争论。他们最终决定用一个非常温和、不精确的术语来命名接下来的一切：“WebRTC下一个版本”或WebRTC-NV。 Bernard解释了这意味着什么。 Chad：我们谈了一点关于我们将在“下一个版本”的WebRTC中看到什么——我想我们不会称之为2.0，因为1.0还没有完成？ Bernard：我想也许是时候我们应该考虑去掉整个NV这个术语了，因为它实际上可以指两种潜在的非常不同的东西。一个是我提到的对等连接的扩展——比如可插入流、WebRTC扩展、WebRTC SVC。我的想法是，当你把所有这些规格放在一起时，它们加起来的功能水平和ORTC一样。因此，我们已经将大部分ORTC对象模型整合到了WebRTC PC中。另一个非常独立的轨道是我所说的独立规格。这包括像网络传输、WebCodecs、网络实时通信等——这些都是完全独立的东西，不依赖于RTCPeerConnection。所以这真的是下一代与现在的一种决裂。显然，还早着呢。WebTransport是一个原始试用版。WebCodecs是Chrome的原始试用版。现在，这是非常不同的，因为你曾经作为整体WebRTC PC的一部分获得的许多东西现在必须用Web Assembly编写。所以这是一个非常非常不同的开发模型。有些东西不在那里。例如WebTransport现在本质上是客户端服务器。我们已经编写了一个对等扩展，不久前有一个最初的试用版，但是现在是客户端服务器。因此，您不能只使用现有的WebCodecs和网络传输来编写完整的WebRTC PC用例。我要说的是，在WebRTC NV中发生的另一件事已经变得非常重要，那就是人们对机器学习和访问原始媒体有了真正的关注。这是ORTC没有提供的。在某种意义上，我想说的是，网络传输或WebCodecs模型在这方面甚至比ORTC还低。ORTC没有让你直接访问解码器和编码器。这就是你从WebCodecs中得到的。所以我认为我们采纳了ORTC的想法，并将其应用到更低的传输层。 ORTC怎么了？对象实时传输控制(ORTC)是网络实时传输控制的一个替代模型，它提供了不使用软件开发平台的低级控制。Bernard是它的作者之一，微软在ORTC的支持下推出了最初的Edge。我们再也听不到很多关于ORTC的事情了，那么它发生了什么？正如Bernard刚才解释的那样，大部分内容都被吸收到了WebRTC的核心标准中。这是ORTC愿景的失败还是胜利？ Chad：你是ORTC原始规范的作者之一。与您最初的ORTC愿景相比，您认为我们现在的状况如何？ Bernard：对象模型完全在Chromium浏览器中。因此，我们几乎拥有了来自ORTC的所有对象——Ice Transport、DTLS Transport传输、SCTP Transport (来自数据通道)——所有这些对象现在都在WebRTC PC和Chromium浏览器中。 RTC也有先进的功能，如联播和SVC，我们已经纳入。此外，我们有比原始的ORTC通过端到端加密，可以通过可插入的流支持。因此，我们已经用对象模型和所有这些扩展将WebRTC PC等同于ORTC。我们期待的场景是像物联网这样只关注数据传输的东西。您可以看到这反映在WebRTC和用例中——这些场景就像对等数据交换一样。网络传输 WebTransport是W3C的另一个规范，有自己的工作组和规范。你会看到很多熟悉的涉及WebRTC 的名字，包括Bernard。 QUIC是一种改进的传输协议——有点像网络传输可以使用的“TCP/2”。 Chad：那么什么是WebTransport，它是从哪里来的，和WebRTC有什么关系呢？ Bernard：网络传输既是一个API，又是W3C网络传输组的成员。它也是IETF中的一系列协议——一系列传输。协议包括QUIC上的网络传输，称为QUIC传输，也包括HTTP/3和潜在的HTTP/2上的网络传输。所以W3C中的网络传输API只适用于QUIC和HTTP/3。HTTP/2被认为是一种故障转移传输，它可能有一个单独的API。那个API是客户端服务器API。构造函数和一切都很像WebSocket。在构造函数网络传输构造函数中，你给它一个网址，然后你会得到一个网络传输。但是它是不同的，因为您可以创建可靠的流和数据报。 Chad：数据包，就像UDP中用于快速但不可靠的传输一样。 Bernard：它是双向的，也就是说，一旦网络传输由客户端发起，但是一旦连接建立，服务器可以向客户端发起单向双向流，数据报可以来回流动。 Chad：双向，就像双向通信一样？ Bernard：WebSocket实际上只是客户端。WebSocket不能由服务器启动，但网络传输可以。在基于QUIC的网络传输中，连接不是共享的。在针对HTTP/3的网络传输中，它可以被汇集在一起——这创造了一系列非常有趣的场景，其中一些场景恢复了IETF BoF。考虑一下，你可以同时进行HTTP/3请求-响应和网络传输，包括流，以及在同一个QIUC连接上的数据报。这是Justin Uberti为IETF的一个名为RIPT BOF的项目设计的一个场景，让人们大吃一惊。在这种情况下，你有一个来回的RPC-请求-响应，但RPC-导致从服务器到客户端的流。所以把它想象成一个客户说，我想播放这部电影，或者玩这个游戏，再或者参加这个视频会议，然后一个可能是可靠的QUIC流的流，或者可能是一个来自服务器的数据报流。我认为WebTransport有潜力给网络带来革命性的变化。HTTP/3本身就是对Web的革命性改变。这场革命的大部分是在更复杂的版本中，即HTTP/3池传输。QUIC传输要简单得多，它只给了我一个socket，我可以在上面来回发送东西。 Chad：WebTransport还有多远？ Bernard：我想说WebTransport API现在已经相当完善了，它刚刚完成它的原始测试，试用版本以M88结束。有几个bug，有些东西不太好用，但是API比较打磨。您可以用它编写一个相当复杂的示例代码。我想这是因为我们用实际代码更新了规范。所以如果你读了这个规范，你就可以用代码来做这些事情了。希望我们很快会在那里提供一个完整的例子，你可以尝试一下。在服务器端，仍然有一些QUIC互操作问题。所以我认为人们使用的服务器是aioquic（Python库），你也可以使用quiche作为服务器，但是它没有集成到框架中。不幸的是，我们没有Node.JS服务器，拥有它真的很好——那可能很遥远。 Chad：正如Bernard所说，WebTransport是客户端服务器，而不是像WebRTC那样的对等(P2P)。然而，我们已经看到了P2P QUIC的预览版。事实上，Fippo早在2019年2月就在QUIC数据频道上写了一篇文章。与这种新的网络传输方法相比有何不同？ Bernard：那是ORTC风格的。它不支持WHATWG/W3C流，也是基于gQUIC协议，而不是IETF的QUIC。WebTransport——代码在Chrome中——基于WHATWG流，也基于IETF QUIC。所以RTCQuicTransport代码非常过时，因为它既是一个旧的API，也是一个旧的协议。那个代码已经从Chromium中删除了。 Chad：那么，对于低延迟的场景，我们如何实现Peer-to-Peer WebTransport呢？ Bernard：我们有一个小的扩展规范，它仍然在ORTC CG中。基本上认为它只是一个WebTransport，但是你让它运行在RTCIceTransport上，而不是一个URL上。所以要做构建，你不给它一个URL，而是给它一个ICE Transport。你就是这么构造的。有一些ORTC的东西基本上是从RTCDtlsTransport中提取的，你可以添加到对等的东西中。但是扩展规范只有几页。它非常非常小，就像95%的网络传输规范完全一样。 Chad：有人构建过吗？ Bernard：我们还没有新的应用编程接口和新的QUIC库的工作版本。没有新东西的版本。RTCQuicTransport的一个特点是它是独立的。今天Chromium中有一个代码，叫做WebRTC ICE。想象一下从网络实时传输中心到PC的洲际交易所传输——这是一个独立的实时传输中心版本。当您从一个RTCQuicTransport构造一个RTCQuicTransport时，它不会与您的对等连接组件复用。它在一个单独的端口上。现在我们不得不在过去的RTCQuicTransport中这样做，因为gQUIC不能与RTP/RTCP STUN和TURN复用。IETF QUIC可以复用。 Chad：gQUIC是来自谷歌的QUIC的原版。这听起来可能会对IP端口的使用产生很大影响，捆绑有助于通过防火墙限制端口使用。 Bernard：开发人员会希望在同一个端口上使用QUIC作为他们所有其他的音频和视频工具吗？如今在WebRTC PC中，捆绑销售非常非常流行。每个人都在同一个端口上把所有东西推在一起——这远远超过了WebRTC所有使用的99%。有人可能会认为QUIC会有类似的需求。如果这是他们真正想要的，我们不想用ORTC风格化的交通工具来建造(快速传输)；你希望能够从一个网络传输中心的PC上构建它。这有点奇怪，因为现在你说部分网络传输依赖于RTCPeerConnection。

RPC设置以通过WebTransport发送媒体。来源：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实现的一些棘手问题主要是，几乎每一个主要的WebRTC视频会议服务中都有Simulcast，参与者众多，并且在标准化和互操作性方面一直处于挣扎状态。 Chad：Simulcasts是如何进行的？ Bernard：据称，在Chromium中，所有编解码器都支持with simulcast，或者至少是现在所有的编解码器。因此，从理论上讲，你应该能够使用H.264，VP8和VP9做到这一点。我们一直在寻找错误，也遇到过一些非常可怕的错误，例如H264无法正常工作。我们已经进行了完整的KITE测试，但是还需要一个简单的回送测试测试基本操作，你可以在其中向自己发送Simulcast。最终Fippo编写了回送测试。如果你想查看该测试，在Fippo的“simulcast playground”（https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/）帖子中。 Bernard：该测试并未在所有浏览器上通过。它之所以没有通过，是因为你发送了RID，被SDP欺骗了，并以MID的形式接收了它们。因此，从本质上讲，如果你发送了三个流，则可以取回三个流，但是它们各自位于不同的MID上。 Firefox不支持MID RTP标头扩展。所以，实际上该环回测试无效。我们发现无论何时编写测试，都会发现一些不太清楚的地方。我再给你举一个奇怪的例子，我们一直在进行硬件加速方面的工作。事实证明，当你使用硬件加速器时，可以获得不同的比特流。它不仅使事情变得更快，实际上是改变了编解码器的比特流，然后你就可以开始破坏互操作了。你进行了Simulcast测试，突然SFU无法处理即将发生的一切。我真的希望我们能够在这些IETF会议之一中亲自见面，进行另一次Simulcast测试，就像Alex博士能够做的那样，看看我们在哪里。你知道，如果每个人都在交付统一计划，我们会很好。 Chad：统一计划是一种新的、标准化的SDP格式，除其他外，它指定了应如何在SDP中处理联播流。统一计划不应该成为节省一天的规范吗？而我们为什么没有这么做？ Bernard：如果每个人都对所有编解码器都使用统一计划，并且[互操作测试]都很高兴，那么你会知道一切正常。我们还不在附近。让我这样说–我们功能完善。我认为这是事实，但是事情在测试范围内不断下滑。我不会说每个浏览器都具有发布商业应用程序所需的所有功能。举例来说，例如，我认为确实有很多商业应用程序都在多个浏览器上发布，但我认为在所有浏览器上都发布的应用很少。因此，考虑到这种情况的一种方法（可能比所有这些测试结果要容易一些）是，如果你对所有主要会议服务及其运行的所有浏览器以及所有不同的模式进行了矩阵分析，则可能会发现最好看看我们实际上在哪里。一直以来这都不是很令人鼓舞。多数服务都支持大多数浏览器是很好的，但是你经常会看到各种功能支持以及跨浏览器的稍微不同的体验。