I think the issue most are expecting is for this to automatically adjust depending on the detected bandwidth of the user. I get that... people expect everything straight away. But Zoom and Teams etc have years on 3CX webmeeting.
Adaptive Rate Control:
Specifically about the "auto-handle-my-bandwidth" feature inbuilt into WebRTC, our MCU uses this, but this feature for technical reasons does not work great in an MCU/SFU architecture and is more suited for a peer-to-peer architecture.
We have plans to eventually build this functionality ourselves as to bypass the buggier inbuilt functions of WebRTC that handle this. I think you'll be pleasantly surprised at how far we are once the MCU and the feature documentation of it become available
The WebMeeting MCU itself has a few bandwidth management features inbuilt that can't be found in any other solution.
I think what we are all requesting is adaptive rate control detection that doesnt kick people. I am sure it will come!
To be clear, WebMeeting doesn't kick users out due to low bandwidth. I understand why you'd think that, but allow me to explain. What happens is that, due to a user's saturated internet connection, keep alives arrive too late and users time out and get disconnected after a while. That's all there is to it.
Instantly being kicked out of a meeting means the user's websocket to the MCU server gets forcefully disconnected by either a firewall kicking in, antivirus, network disconnect.
While media can be reconnected if the RTP connection is killed (and we do that with 'Media Reconnecting'), if the signaling websocket is killed, there is not much we can do and must consider this user as disconnected for technical reasons.
My point is, there is a lot to do with WebMeeting, most building blocks are there, just a few to go.
