Videoroomtest. a/v stream doesn’t work for some networks on client side

86 views
Skip to first unread message

Aleks Ritor

unread,
Feb 24, 2017, 3:07:54 AM2/24/17
to meetecho-janus

Hi,

 

I am fighting with issue to receive audio/video stream on my home network using videoroomtest webclient and Janus gateway (videoroom plugin; tag v. 0.2.1) installed on my dedicated server (ubuntu 14.04.4 LTS 64-bit).

 

The issue is that I don’t see (hear) anyone from video room event on my home network; but with the absolutely the same setup, backend & client PC everything works fine on my office network. All other users can hear and see me just fine from both home and office networks. Also interesting is that videorromtest.html from janus.conf.meetecho.com site works fine without any issues on my home network (!)…

 

I do not see any errors in client and server logs, Janus config was not modified… What could be wrong? Should I use specific turn/stun servers? Please advise!

Lorenzo Miniero

unread,
Feb 24, 2017, 4:50:49 AM2/24/17
to meetecho-janus
Check what's wrong with the affected handles using something like the Admin API:

Aleks Ritor

unread,
Feb 27, 2017, 2:03:56 AM2/27/17
to meetecho-janus
Hi.
Thank you for advise. When i checked handles in admin monitor i found that handles from my home client is normal, but handles from my work network has two 'false' values in dtls section. May be that is visualization of my problem? But i still don't know how to fix it, May be you can advise something?

пятница, 24 февраля 2017 г., 12:50:49 UTC+3 пользователь Lorenzo Miniero написал:
monitor1.png
monitor2.png

Lorenzo Miniero

unread,
Feb 27, 2017, 4:58:38 AM2/27/17
to meetecho-janus
It says DTLS still trying in that case, which means the handshake has not completed. Are you using large certificates for DTLS? Have you checked with wireshark/tcpdump both on server and client (if you have access to both) to see if any of those DTLS packets are lost somewhere in between? Try forcing a smaller MTU in janus.cfg (e.g., uncommenting the dtls_mtu=1200 the sample has). As an alternative, you may want to check if using BoringSSL instead and passing --enable-dtls-settimeout to the configure helps too, as it may result in a quicker fragmentation.

L.
Reply all
Reply to author
Forward
0 new messages