[1.x]inconsistency happen when more than 6 users join at same time with different browsers (web and mobile) about janus-gateway HOT 10 OPEN

All the users does not get the all members streams. users get partial members stream.

Share a janus message/events log for a client with this issue. I suspect this is something related to client code.

Joining time also increasing based on the members count. last users took 10 to 20 sec to join the room

10 users joining at the same time is a quite common scenario. I never experienced a 20 secs waiting, again this smells like issue with the application code.

Could you share the best configuration with 8 members.

No idea what is the question.

from janus-gateway.

@venkateshcontus any update on what Alessandro asked?

from janus-gateway.

Hi,

 Please wait will share the logs

from janus-gateway.

Hi,

This is the Janus server configuration we are using, with this configuration while joining 8 members in a room we are facing the issue mentioned earlier.

cpu cores : 1
vCPU : 2
Memory : 6GB
Download: 1020.72 Mbit/s
Upload: 1004.01 Mbit/s
Ping : 64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=11.4 ms
Ping : 64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=1.34 ms

https://mf-janus-test.mirrorfly.com/?room=1 - more than 6 members join the same room with their own system we got the latency.

from janus-gateway.

This is not the information Alessandro asked for. Please share the message flow for a client with issues.

from janus-gateway.

On top of that, even mimicking the layout, that web app is not the one we have on our demos.

from janus-gateway.

Hi,

 Yes, we changed the limit size from 6 to 10 from your default demo page. Please find the event log in one of the client.It took almost 1.5 mins to render all the 9 users video.

websocket_messages.json

from janus-gateway.

This log seems to suggest some incorrect or broken network configuration you may have. We see, for instance, that it takes close to a minute for an attached event to be sent back in response to a new subscription. This could happen if a push_event with an SDP offer takes a long time to return, which can happen if Janus is configured to do half-trickle (the default) and it takes Janus a long time to gather all the candidates.

Apparently you're using some sort of docker or k8s environment (at least looking at the host address), and you have STUN enabled in Janus (which is usually not recommended, but that's a separate matter). If gathering the host candidate takes a long time, or the STUN server takes a long time to respond, push_event will sit there waiting until all candidates have been gathered before preparing the final SDP offer and sending it. For host candidates, the cause may be a network interface that is not working properly, or may not be configured correctly. You can check if that's the case by enabling full_trickle = true in janus.jcfg (which is in the nat section). You can also try disabling the STUN usage in Janus to see if that speeds up signalling too (in which case it would mean it's Janus waiting for the STUN server to respond that's the cause of the problem). If you can, if it's docker/k8s try configuring those instances to use host networking.

Please let us know if anything changes with that configuration. My assumption is that signalling would not be blocked as it is now, but you'd still have long setup times (caused by the very slow gathering of candidates). If that's the case, then it would be up to you to fix the network configuration.

from janus-gateway.