Install ngrep
apt-get install ngrep
and start to watch the UDP/10000 traffic
ngrep -q 'is accessable' udp port 10000
Install netcat
apt-get install netcat
and send a message to the server through UDP/10000
echo 'yes, it is accessable' | nc -u your.server.com 10000
If you can see the sent message on the server side, this means that there is no UDP/10000 connectivity problem between this client and the server.
Also I have tested this way: This is on a Mac…
Open a Chrome window with 3 tabs, all of which are connected to the same room.
Open a local terminal window and run:
(you will see lots of traffic on 10000 with 3 Chrome tabs running)
sudo tcpdump -ni en0 port 10000
Open another terminal window,
Run the following to block 10000 udp traffic.
echo "block drop quick on en0 proto udp from any to any port = 10000" | sudo pfctl -ef -
Run the following to enable 10000 udp traffic
echo "block drop quick on en0 proto udp from any to any port = 10000" | sudo pfctl -d
If you have three tabs open with 10000 udp open you will see a lot of activity. When you block 10000 you will see activity slow down, the video in the Chrome tabs will stop and the Chrome tabs will eventually reload. If the tabs reload with 3 good video signals you know failover to 443 worked.
I found this to be a nice visual way to test.
Audio/video does not work if two clients are on different networks
Using this to monitor traffic:
sudo tcpdump -ni ens160 udp port 10000 -vv -X
port 10000 is accessible if I use netcat to connect to it
echo 'yes, it is accessible' | nc -u your.server.com 10000
on the server:
tcpdump: listening on ens160, link-type EN10MB (Ethernet), capture size 262144 bytes
08:05:16.163828 IP (tos 0x0, ttl 52, id 19934, offset 0, flags [DF], proto UDP (17), length 50)
59.95.99.46.56015 > 103.133.214.224.10000: [udp sum ok] UDP, length 22
0x0000: 4500 0032 4dde 4000 3411 1bea 3b5f 632e E..2M.@.4...;_c.
0x0010: 6785 d6e0 dacf 2710 001e 1240 7965 732c g.....'....@yes,
0x0020: 2069 7420 6973 2061 6363 6573 7361 626c .it.is.accessabl
0x0030: 650a
but I cannot see any traffic on my jitsi server - port 10000 using the same tcpdump command, when I create a jitsi meeting and connect to it from my laptop+chrome+broadband, and a second client - android jitsi app running on a cellular phone/4G.
What could be the problem?
when you connect 2 clients by default jvb is not used as per default configuration (p2p : enabled in config.js) so port 10000 connectivity does no difference at all.
I see … hmmm.
So - is my understanding correct?
If one client is on a different mobile network and one is on a home network behind a router,
a. port 10000 on the jitsi server does not come into the picture.
b. STUN/TURN is not required - and even if it does come into the picture, it is not connected with port 10000 UDP
as I said by default jvb is not used for 2 clients so they will not connect to port 10000 of the video bridge hence your point a is correct.
as of your point b I don’t use p2p so I can’t comment reliably, from what I hear Stun is necessary for it to work.
a. P2P works differently. As gpatel-fr mentioned, by default JVB is not used in a P2P scenario - both peers negotiate a random port to cimmunicate over.
b. Because 1 of the clients is behind a router, there is no way for the mobile client to determine the home user’s public IP address without STUN (assuming the router is a NAT device). You don’t necessarily have to set up you own STUN server, there are several free ones available, like the google STUN servers. The Jitsi quick install also provides a STUN implementation.