i am having a jitsi installation and i am using jitsi lib meet to control the videobridge. Videobridge is on a seperate dedicated server and it is configured to run on 443 port( ports 4443 and 10000 are open too). I also have disabled p2p.
Videobridge works perfectly most of the time , but i am having some issues from a couple of corporate firewalls that try to use the system. Although ice4j flags a pair of candidates as succeded and validated, no video and audio passes through . The users behind these firewalls join the conference and they recieve the text messages and some custom interactions i have set up, but audio and video doesn’t pass from and too these users.
Below there are the lines indicating the pair validation. I have also asked from the people inside this firewall to allow udp connections for port 10000 for the server ip.
12390:JVB 2018-10-26 09:31:22.130 INFO:  org.ice4j.ice.Component.log() Not adding duplicate remote candidate: 10.xx.xx.214:59385/udp
12393:JVB 2018-10-26 09:31:22.169 INFO:  org.ice4j.ice.ConnectivityCheckClient.log() Pair failed: xx.xxx.xxx.xxx:10000/udp/host -> 10.xx.xx.214:59385/udp/host (stream.RTP)
12394:JVB 2018-10-26 09:31:22.175 INFO:  org.ice4j.ice.ConnectivityCheckClient.log() Pair succeeded: xx.xxx.xxx.xxx:10000/udp/host -> xx.xxx.xx.202:59385/udp/prflx (stream.RTP). Local ufrag 7tumb1cqnrdfq1
12396:JVB 2018-10-26 09:31:22.176 INFO:  org.ice4j.ice.ConnectivityCheckClient.log() Pair validated: xx.xxx.xxx.xxx:10000/udp/host -> xx.xxx.xx.202:59385/udp/prflx (stream.RTP). Local ufrag 7tumb1cqnrdfq1
12397:JVB 2018-10-26 09:31:22.176 INFO:  org.ice4j.ice.DefaultNominator.log() Nominate (first valid): xx.xxx.xxx.xxx:10000/udp/host -> xx.xxx.xx.202:59385/udp/prflx (stream.RTP). Local ufrag 7tumb1cqnrdfq1
can someone please advice on what maybe the issue?
PS we have tested the system for tcp fallback through a very restrictive firewall (only 443) and the tcp fallback worked as it should.
*deleted post because probably wrong place
You should add turn server to your deployment. Have you tried from the places where there is the corporate firewall using meet.jit.si, does it work?
Most of the time with corporate firewall the link will fallback to TCP port 443, when using jvb tcp relay, it uses a google ssl faking over that channel where sometimes firewalls detect that and drop the traffic. When using turn server you will be using a communication channel which for the firewalls will look as a regular https connection and will not drop it. I think this is the issue you are experiencing, but if it works for you on meet.jit.si, means that your problem will be solved with adding a turn server.
meet.jit.si works through these enviroments.
Thank you very much for the very fast and very detailed response, i will implement the turn server and come back with the results.
Thank you for the help,
We where able to solve the problem by installing a turn server , and forcing the user to connect through it to the videobridge.
Of course this is not an optimal solution since tcp is used and udp is never attempted for any user, unfortunately we couldn’t find a way to only force the affected users to use the turn server and leave the others through regular connection. Is there a way for this functionality to happen without forcing it from starters ?
Another problem we are facing has to do with gum errors (device notfound) when someone enters the conference but doesn’t have a camera on his/her machine. localtracks never fire if a camera isn’t found in the system when using lib-jitsi , as oposed to using regular meet , which resolves this issue. I don’t know if this is related , but somehow remote audio tracks passed to a user dont hold audio in them , instead i you want to edit the volume of a user you need to target his video element It seems to be that audio and video are bundled prior to beeing sent to the users (is this possible)?
Thanks again and sorry for the long post.
How do you force only TCP?
I would say, leave only turn TCP using port 443 and disable jvb tcp harvester (
org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true). This way all clients will have one tcp candidate and udp candidates to the bridge, whatever succeeds will be used.