[thecleaner]

I think Zoom doesn't use WebRTC, they have their own decoder, transmission, retry layer. If you try to transmit raw frames directly, you end up with codec issues since frames have dependencies among them. E.g. VPX series cannot decide frames without a golden frame or a key frame so these need to be kept as state for a decoder. Every other intra-frame needs to refer to these frames and there's no limit usually as to how many intra-frames one can have between inter-frames (key-frame or a golden frame).

[Sean-Der]

I don't work at Zoom/only have outsider information. It looks like they are using Media over DataChannels[0]. So they are still using WebRTC!

When Google announced WebCodecs/WebTransport they said Zoom was involved, so maybe they will switch to that eventually?

[0] https://webrtchacks.com/zoom-avoids-using-webrtc/

[thecleaner]

Does data channels over WebRTC enforce different semantics than say QUIC/Http2 ? I understand that the difference b/w TCP and WebRTC based comm would be application level transmission guarantee but does it really differ from UDP based HTTP implementations ?

[kwindla]

The biggest problem with sending media over data channels is that there's no good way to do bandwidth estimation. Data channels weren't designed to be used for media, and the current WebRTC spec (and javascript implementation) doesn't expose enough control of either the codec or the network stack to implement real bandwidth estimation and bandwidth control. This is presumably the main reason that Zoom's in-browser implementation is so limited in functionality.

There's a spec for RTP over QUIC [1]. It's really cool! But obviously very early days.

[1] https://datatracker.ietf.org/doc/draft-engelbart-rtp-over-qu...

[avrionov]

Zoom uses Media over DataChannels only for the browser version of their product. For the desktop and mobile clients they use their own implementation.