Alternative using binary instead of json for updates

[vincentfretin]

Alternative using binary instead of json for updates

[gfodor]

Heya, the reason I converted NAF to use flatbuffers was because when profiling the elixir servers for Hubs, for large events, the two major CPU bottlenecks on the server was the TLS encryption (unavoidable) and the JSON payload parsing. This codebase is a derivative of work I did previously that was trying to optimize this server side bottleneck, and I carried it forward to this adapter. Certainly binary serialization leads to more efficient use of the client CPU as well, but I don't think that would have been a sufficiently motivating reason to do it for a p2p library.

[gfodor]

Wrt using websockets for audio I would def caution against that, as the head of line blocking on spotty networks I would imagine would be very problematic for maintaining quality and avoiding stutters. If you wanted to go this route you could leverage WebTransport instead and use unreliable delivery streams.

[vincentfretin]

Thanks for the historical reasons. Hubs is still using the Elixir Jason library for json parsing today. I saw recently on twitter that someone did optimizations for json parsing in erlang with better perf than Jason. I couldn't find again the discussion. But yeah you still parse json.

I'm wondering how rust serde library that is used in the janus sfu compare with Elixir Jason library. We are several still using this solution without any additional backend.
For those that don't know, janus sfu was the previous sfu solution in Hubs, before they switch to the "dialog" service using nodejs/mediasoup WebRTC stack. Before Hubs switched to mediasoup, it used janus-plugin-sfu and naf-janus-adapter 3.0.x but with the Phoenix Channel/Presence (WebSocket) for the signaling part and data, using a function for the adapter.reliableTransport and adapter.unreliableTransport (those can be "websocket", "datachannel", or a function), so using only the janus sfu for audio and video, not data. There were changes in naf-janus-adapter master with the syncOccupants api to better handle the signaling part for Phoenix to be the source of truth of the connected participants, avoiding some ghost participants issues. I'm not sure if those changes were in production, but the Hubs team worked on mediasoup adapter without the signaling part soon after.

Yes I agree, WebSocket is not meant to stream media. WebTransport and WebCodecs would be a nice alternative to WebRTC when it will be supported in all browsers including Safari iOS.
I looked into this for a client that had heavy restriction to open ports on their corporate network. In the end they could do WebRTC via a TURN server via a relay-tls ice candidate. From my understanding relay-tcp or relay-tls have the head of line blocking issue. relay-udp would have been fine, but they blocked all UDP traffic. WebTransport is using UDP because it's using HTTP/3 over QUIC if I read correctly, so unless the client allows UDP ports, it won't work either.