Only port 443 and 80 and no udp

Is it possible to use jitsi meet, when the client has access to internet through proxy only and 443 and 80 are the only allowed ports? All udp-Trafic is completely blocked, this means, that the stun protocol, does not work.

Is that possible to configure jitsi for stunserver and tcp? How can do that?

use coturn. It works correctly with chrome based browsers, it may be more problematic with Firefox currently.

Hi ,

I 'm using coturn and chrome, but the meet-client obviously tries to contact the StunServer via udp. udp is blocked. So the client never gets an answer.

Hello gpatel-fr, forgot to say thank you for your response. I read a few of your comments from you to other topics and the way your answer seems to me very cautious on the one side and on the other side, your are skilled in at least some of the topics stun, turn and so on. Thats why I am encouraged to ask you some more questions: 1. Whenever possible jitsi Media go via udp. When impossible tcp is used. Is this a tunneling or of udp data, or is thas an redirection of data via another transport protocoll, I asked this because using tcp media is said to have less quality.
Next question: On my private laptop, when I start a jitsi meeting it uses udp/10000, when I block 10000 and stun port on my laptop tcp 443 is used. Everything is fine. Video is colourful, and audio cool. No matter if there are two, three or more participants. In case of my proxy: Udp seems to me not realy blocked, but it seems to be ignored. I think this because again and again the jitsi client sends adresses port 10000/udp on jitsiserver though it is not reachalbe. The proxy does not allow udp. Do you know a solution?
Thanks for reading. Greetings Lorenz

That’s about it, when udp fails the Jitsi-meet client tries to connect to coturn using tcp. Coturn relays this to the videobridge.

it’s a performance issue, tcp is great for retrying in case of errors, but for real time communications this is disastrous because it’s introducing many delays, it’s better to drop missed data altogether. So if your network is very reliable, tcp will be good enough. If it’s not (as is very often the case with wifi) tcp is very bad.

in this case your coturn seems to be working. I don’t really know what can happen. Maybe by ‘proxy’ you mean ‘vpn’. Vpn are known to have issues with webrtc, the underlying technology for Jitsi-meet.

Before I forget it -:slight_smile: Thanks, that helps a lot!