作者：Varun Singh，JÖRG OTT（原文链接）
翻译：刘通
原标题：Visions for WebRTC Next Steps: Fine-grained Media Control in the browser
在11月初，W3C宣布推出供候选推荐的WebRTC v1.0，这意味着社区认为该标准是设计完整的，并且正在征求对API实施的反馈。
根据开发人员和浏览器提供商的反馈意见和API实施经验，v1.0 CR预计将在未来几个月内进行修订。这也意味着，除了修正bug以外，当前候选推荐（CR）提案中不会增加新的主要功能。
在最近结束的W3C技术大会/咨询委员会（TPAC）上，我们就WebRTC v1.0的后续发展进行了公开讨论。其中一个主题就是在WebRTC中加入新的传输方式，具体来说就是在WebRTC中采用QUIC。
QUIC传输
一点背景知识：QUIC目前在IETF中作为HTTP/2的替代品。由于它是通过UDP定义的，因此WebRTC有机会试用QUIC作为当前正使用的SCTP/DTLS的数据通道传输的替代品。
在Google工作的Peter Thatcher有一个Chrome中的QUIC工作原型，并提出将QUICTransport和QuicStream加入作为WebRTC的扩展传输。QuicTransport做了繁重的工作，并且是DtlsTransport和SctpTransport的组合。QuicStream紧密映射到IETF中定义的QUIC流，这意味着应用程序可以：
# 往本地流中写数据（write）
# 从远端流中读数据（read）
# 当本地流完成时结束（finish）
# 重置远端流（reset）
QUIC默认是可靠的。因此，本地流会希望通过例如超时这样的方法进行重置，因为特定的QuicStream已经尝试在合理的时间内提供内容。或者远端感觉它不需要从特定的流中获取数据，因为它已经前进并且可以远程重置它。最后结果是可以在这些QuicStream上构建数据通道，也就是很容易构建“大-有序-可靠”的消息，以及“小-无序-可靠”的消息。
QUIC上的媒体
今年夏天，一些从事RTP的人讨论需要什么才能通过QUIC发送媒体。拓展Peter提出的通过QUIC发送数据的建议，通过QUIC发送媒体将是一件非常棒的事情。
在一个媒体会话的生命周期中，该会话预计将会产生数百万/数千万的流，因此QUIC非常适合发送媒体帧。
与用于媒体的UDP一样，应用程序对其放入QUIC流中的内容有着完全的控制，也就是它可以将MTU大小的包，或者帧，或者一组图像放入QUIC流中。最重要的是，QUIC流是可靠的，并且可以从远端进行控制。如果下一帧或者GoP已经被解码，我们就拥有内置的跳帧或者一组图像。而且，这些策略可以根据网络环境进行调整。
举个例子，在丢包率更高或者延迟更高的网络中，QUIC流的结构与更稳定网络环境中的结构会有所不同。再往下，我们可能会看到QUIC中不可靠的流，这将允许更细度的分化。我只是抛砖引玉，我相信如果人们更深入的思考就会想出更复杂的层次结构，也许会提供更好的质量体验。
我们可以在JS领域上做到这些吗？
目前，QUIC的WebRTC实现可以在Chrome中做实验使用，它可以通过QUIC发送媒体。缺少的部分中，最简单的是将媒体轨道连接到QuicTransport的方式。我们可以通过让浏览器像在PeerConnection API中创建连接的方式来实现它。
但是，我觉得让JavaScript控制这些是一个明智的做法。在WebRTC v1.0的PeerConnection API中，我们让浏览器管理媒体处理过程中的复杂部分：封装，调整帧速率，帧大小，媒体编码等等。在WebRTC v1.0的未来发展中，浏览器可以将每个加密的帧给JavaScript来进行封装以及发送给远端端点。远端端点可以决定是播放媒体流还是重置流。其中有无限的可能，对JS赋予更多的控制里意味着具有自适应能力的实时应用将会变成现实。
