[jitsi-dev] Jitsi Meet &Jitsi Videobridge TCP & TURN


#1

Hi devs,

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?

Regards
damencho


#2

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?

You mean that googTransportType is udp? That's working as intended.
When using the TURN server via TURN/TCP the googTransportType describes the protocol used by the turn server to talk to the peer, not the protocol used by the client to talk to the TURN server.
Somewhat unexpected, eh? See https://code.google.com/p/webrtc/issues/detail?id=2985 for the full story.


#3

Right. But we'd still need to adjust what we show users in the GSM bars.

Emil

···

On Wed, Nov 19, 2014 at 5:26 PM, Philipp Hancke <fippo@goodadvice.pages.de> wrote:

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?

You mean that googTransportType is udp? That's working as intended.
When using the TURN server via TURN/TCP the googTransportType describes the
protocol used by the turn server to talk to the peer, not the protocol used
by the client to talk to the TURN server.
Somewhat unexpected, eh? See
https://code.google.com/p/webrtc/issues/detail?id=2985 for the full story.

--
https://jitsi.org


#4

FWIW, I installed a recent videobridge nightly and was unable to get it to
work with Jitsi (latest stable) without disabling TCP in videobridge as
well.

Also even the though jvb and all clients are on the same LAN segment, it
insisted on using TURN, and failed until I disabled that in Jitsi.

···

On Nov 19, 2014 10:36 AM, "Damian Minkov" <damencho@jitsi.org> wrote:

Hi devs,

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).

--
David Mansfield
Cobite inc.


#5

until getStats returns the url for the used candidate the googLocalAddress should match the relay address of the turn server. That's a somewhat icky workaround though, especially when you use turn/tls with a hostname.

···

Am 19.11.2014 um 08:55 schrieb Emil Ivov:

On Wed, Nov 19, 2014 at 5:26 PM, Philipp Hancke > <fippo@goodadvice.pages.de> wrote:

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?

You mean that googTransportType is udp? That's working as intended.
When using the TURN server via TURN/TCP the googTransportType describes the
protocol used by the turn server to talk to the peer, not the protocol used
by the client to talk to the TURN server.
Somewhat unexpected, eh? See
https://code.google.com/p/webrtc/issues/detail?id=2985 for the full story.

Right. But we'd still need to adjust what we show users in the GSM bars.