While running the TCP tests of jitsi-meet-torture I found that it is
not working on the IETF jitsi meet installation.
There is a jigasi instance installed, and as jigasi doesn't support
rtcpMux and Bundle, they are disabled in Jitsi Meet. But those are
also required for the jitsi-videobridge TCP implementation. In order
to have a TCP support, a TURN server is configured. What I found is
that the Jitsi Meet instance there is not working when I have udp
disabled on local machine.
The problem was fixed when I disabled the TCP support in
jitsi-videobridge, seems there are some tcp candidates coming from jvb
even if TCP is not used (thanks Bobi for the hint).
The second problem I found is that when we are connected through TURN,
in the stats we can see that we are connected through the bridge
ipaddress and using udp, although it must be TCP and the TURN address.
This is not the case when connected through the bridge TCP
implementation, then the protocol is TCP and the ipaddress is the
address of the jvb instance, as expected.
When looked at the webrtc-internals there is no connection with TCP
transport, also I checked later the webrtc-internals dump, even the
relay candidates are udp, although I can see in wireshark that the
same ports are used through TCP.
Is this a chrome bug?