Jvb publishes wrong public ip in docker/traefik setup

Dear all,

I am struggling to get jitsi meet running in a docker environment behind traefik. I already posted my docker-compose.yml in a similar thread.
I got the web part running and can do a conference among users on the same network segment (like my home wifi/lan for example). But I am having troubles getting jvb to work correctly.
The following errors appear in the log frequently:

org.ice4j.socket.MergingDatagramSocket.log() Cannot find socket to remove.
org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with abcdef0123456789 not ready yet.
org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can't send a message

When I look at the webrtc-internals in chromium/chrome I see three candidates with the three private ip addresses that the container get’s assigned (two ipv4 and on ipv6).
So my question is how do I convince jvb to ‘publish’ the public ip addresses?

Any help appreciated! I will share the configs once they are working :smile:

I guess this is the relevant portion of webrtc-internals (redacted):

type: offer, sdp: v=0
o=- 1923518516 2 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video data
m=audio 1 RTP/SAVPF 111 103 104 126
c=IN IP4 0.0.0.0
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:126 telephone-event/8000
a=fmtp:111 minptime=10; useinbandfec=1
a=rtcp:1 IN IP4 0.0.0.0
a=rtcp-fb:111 transport-cc
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=setup:actpass
a=mid:audio
a=sendrecv
a=ice-ufrag:6s5221e3p284bo
a=ice-pwd:1sk5aq03eusqgss60i33coo86f
a=fingerprint:sha-1 33:DD:A5:9B:98:68:21:CF:F3:1E:6E:97:74:AE:A2:6E:F2:E5:31:E4
a=candidate:1 1 udp 2130706431 10.10.0.XXX 10000 typ host generation 0
a=candidate:2 1 udp 2130706431 fd00:bee:bee:0:0:0:0:XX 10000 typ host generation 0
a=candidate:3 1 udp 2113932031 172.22.XXX.XXX 10000 typ host generation 0
a=candidate:4 1 udp 1677724415 89.106.XXX.XXX 10000 typ srflx raddr 10.10.0.XXX rport 10000 generation 0
a=ssrc:870459847 cname:mixed
a=ssrc:870459847 label:mixedlabelaudio0
a=ssrc:870459847 msid:mixedmslabel mixedlabelaudio0
a=ssrc:870459847 mslabel:mixedmslabel
a=rtcp-mux
m=video 1 RTP/SAVPF 100 107 101 96 99 97
c=IN IP4 0.0.0.0
a=rtpmap:100 VP8/90000
a=rtpmap:107 H264/90000
a=rtpmap:101 VP9/90000
a=rtpmap:96 rtx/90000
a=rtpmap:99 rtx/90000
a=rtpmap:97 rtx/90000
a=fmtp:100 x-google-start-bitrate=800
a=fmtp:107 x-google-start-bitrate=800; profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1;
a=fmtp:101 x-google-start-bitrate=800

While the public ip for candidate:4 is correct, it uses the wrong private ip! The one used is only good for container2container communication while the 172.22.XXX.XXX should be used for outside communication. How can I fix that? How can I even suppress candidate:[1-3]? They will never work anyways …

Cheers,
j.

Hi all,

ok, I try to be more precise. When the bridge container starts, it get’s a total of three (private) addresses assigned: one from the configured meet.jitsi network and two from the network it uses to communicate to the outside (one ipv4 and one ipv6). It then decides to use the one from the meet.jitsi network as its NAT_HARVESTER_LOCAL_ADDRESS and that of course does not work.
My question now is, how to force jvb to use the private ipv4 address from the network it uses to talk to the outside? Currently we configure that manually, but anytime we need to restart the containers (e.g. docker-compse up) the container ends up with a different address and we have to manually interfere. How does that work inside kubernetes?

Any help appreciated! Cheers,
j.

Here you can few some config options that you can add in jvb config prop file: https://github.com/jitsi/ice4j/blob/master/doc/configuration.md#orgice4jiceharvestallowed_interfaces

1 Like

I am experiencing the same issue as well. It works until a second participant enters then I get an error about a missing video bridge. The candidates offered all seem to have at least one incorrect ip address similar to @jogi examples except for candidate 7. 107.155.120.106 is the public ip address and 10.0.4.117 is the internal ip assigned by docker. See for reference below:

a=candidate:1 1 ssltcp 2130706431 172.18.0.5 4443 typ host generation 0
a=candidate:2 1 ssltcp 2130706431 10.0.4.117 4443 typ host generation 0
a=candidate:4 1 udp 2113932031 172.18.0.5 10000 typ host generation 0
a=candidate:5 1 udp 2113932031 10.0.4.117 10000 typ host generation 0
a=candidate:3 1 ssltcp 1677724415 107.155.120.106 4443 typ srflx raddr 172.18.0.5 rport 4443 generation 0
a=candidate:6 1 udp 1677724415 107.155.120.106 10000 typ srflx raddr 172.18.0.5 rport 10000 generation 0
a=candidate:7 1 udp 1677724415 107.155.120.106 10000 typ srflx raddr 10.0.4.117 rport 10000 generation 0

So I’m not sure why it’s not connecting on candidate 7. However, it’s possible, since it is using 10000/udp, Traefik is not properly routing it to the jvb container. I am using Traefik version 2.2rc3 which does support udp routing and I do have it setup along with TCP routing on port 4443. Although I am not sure if I have SSL setup properly on port 4443. I’m also questioning whether port 4443 shouldn’t be HTTP routing instead of TCP routing.

I think we’re close to getting this to work with Traefik but we need to find out how to get jvb to use the proper internal ip address. Probably a combination of that and not properly configuring Traefik.

In my case it would help a lot if I could block entire subnets from being used for the harvester.

I also disabled tcp fallback since it seemed to make things worse, especially when using firefox. Regarding the TLS option for port 4443 I am also uncertain how to deal with this. Basically with traefik we have three options: no tls, tls, tls passthrough. Not sure which one should be used.

But basically I agree, we are getting close® :smile:

I think the solution lies in this post: SOLVED: Docker Compose Setup for Local Development Using Websockets

I am currently implementing it. I’ll post back with more information.

2 Likes

Any news here?