WebRTC 客户端是否可以与仅支持 Channels 而不是 Data/Send 机制的 TURN 服务器一起工作？
Will WebRTC clients work with TURN servers which support only Channels and Not Data/Send mechanisms?
我正在阅读 TURN 服务器 RFC。所有相关的 RFC（5766 和更新的 8656）都支持通道机制，以避免 send/data 方法所需的 STUN headers（RFC 5766 的第 2.5 节）的 36 字节开销：
For some applications (e.g., Voice over IP), the 36 bytes of overhead
that a Send indication or Data indication adds to the application
data can substantially increase the bandwidth required between the
client and the server. To remedy this, TURN offers a second way for
the client and server to associate data with a specific peer.
对于WebRTC，显然没有必要使用send/data机制。浏览器如何在两种中继机制之间进行选择？ send/data 是后备吗？在 TURN 服务器中单独支持 Channels 是否足以支持 WebRTC use-case？
他们通常会在等待创建 Channel 时执行 SendIndications。
如果您在创建频道之前在中继上获得某些内容，SendIndications 也很重要。有些客户端只在发送时创建通道，而不是在创建权限时创建。
Firefox 不支持 TURN 频道：https://bugzilla.mozilla.org/show_bug.cgi?id=857736
Chrome 也使用 send/binding 指示直到 ICE 完成（大概是为了避免创建以后不使用的通道的开销）
不要依赖规范的部分实现，那是行不通的。
我正在阅读 TURN 服务器 RFC。所有相关的 RFC（5766 和更新的 8656）都支持通道机制，以避免 send/data 方法所需的 STUN headers（RFC 5766 的第 2.5 节）的 36 字节开销：
For some applications (e.g., Voice over IP), the 36 bytes of overhead
that a Send indication or Data indication adds to the application
data can substantially increase the bandwidth required between the
client and the server. To remedy this, TURN offers a second way for
the client and server to associate data with a specific peer.
对于WebRTC，显然没有必要使用send/data机制。浏览器如何在两种中继机制之间进行选择？ send/data 是后备吗？在 TURN 服务器中单独支持 Channels 是否足以支持 WebRTC use-case？
他们通常会在等待创建 Channel 时执行 SendIndications。
如果您在创建频道之前在中继上获得某些内容，SendIndications 也很重要。有些客户端只在发送时创建通道，而不是在创建权限时创建。
Firefox 不支持 TURN 频道：https://bugzilla.mozilla.org/show_bug.cgi?id=857736 Chrome 也使用 send/binding 指示直到 ICE 完成（大概是为了避免创建以后不使用的通道的开销）
不要依赖规范的部分实现，那是行不通的。