Hi, I noticed that WebSocket is favored and that SCTP will become obsolete in Jitsi. I am wondering why is this the case, since I think TCP/IP, which is still the basis for WebSocket, suffers from waiting for late packages to present an ordered stream to the application, which can lead to delays in the audio-video stream in my understanding. True, over UDP, there are better protocols than SCTP, like QUIC. I am also sure that in certain situations (e.g. stable networks), TCP/WebSocket is better. I am a bit unclear why SCTP will not be supported, and also no other UDP based protocol will not be supported if i understand correctly, even though UDP would allow for more reliability for mobile devices, in the sense that all messages or packages will probably take effect immediately and not suffer from waiting a delayed packet (from head of line blocking), pls let me know your understanding, thanks
That channel of communication with the bridge is used for exchanging data packets between clients and the bridge only. Information like who is on stage and desired resolutions for videos and stats reported in the conference, it is not something that requires a lot of bandwidth.
In the past, we had problems with the SCTP libraries and crashes in the bridge due to it so we migrated on using the websockets to replace it. And as we are not using that code, that brings the problem of not supporting it enough and leaving it behind, so we decided to drop it so we don’t leave it to linger in that not supported state where people can hit problems with it.
Thank you. So the channel used for the main audio/video communication is a different one, right, and it will still be possible to select between UDP (I think in config it’s called something like data channel) vs WebSocket, right?
There is no change in audio or video channel, it is still UDP and it can fallback to turn TCP and etc. Nothing has changed there.
Here we are talking just for the direct connection to the bridge from the client about those info messages.