Jitsi meetings crash after +/- 30 seconds

Hello,

I’ve been trying to get the setup working for the past 3 hours or so and it’s really unclear what the issue is.
Whenever someone enters a room I created, the connection drops with “Something went wrong trying again in x seconds”.

The console log of the client shows the following errors:

Bridge Channel send: no opened channel.

Then after a few seconds:

CONFERENCE FAILED: conference.iceFailed
<RTCDataChannel.e.onerror>: Channel error: undefined

JVB shows the following error on startup:

Failed to parse STUN server address: [I used the public domain value here]
Exception in thread “Thread-5” java.lang.IllegalArgumentException
at java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1314)
at java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1202)
at java.util.concurrent.Executors.newFixedThreadPool(Executors.java:89)
at org.ice4j.ice.harvest.MappingCandidateHarvesters.createStunHarvesters(MappingCandidateHarvesters.java:328)
at org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize(MappingCandidateHarvesters.java:172)
at java.lang.Thread.run(Thread.java:748)

And after a few seconds it shows:

Jul 01, 2020 12:28:05 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Pair failed: 172.19.0.4:10000/udp/host -> 192.168.178.229:52814/udp/host (stream-d4efec86.RTP)

I’ve been searching for quite a while now and all I can find are the same answers to variations of this question but those are simply not working for me.

I tested if port 10000 is reachable from the public, which it is.
I changed nearly nothing in the .env file aside from the passwords/config dir(volume mount)/public url.

Why is it working for a solid 30 seconds and then crashing, what am I doing wrong?

Maybe the bridge is not advertising correctly the public address.

How can I debug that? Or better yet, how do I ensure it does use the correct address? :slight_smile:

chrome://webrtc-internals open it before opening two tabs. On the tab in internals where there are no stun servers check setremote description part and the ip addresses there.
Double check that udp port forwarding is working.

The top of the page shows something about stun:

{ iceServers: [stun:meet-jit-si-turnrelay.jitsi.net:443], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: “plan-b” }, {advanced: [{googHighStartBitrate: {exact: 0}}, {googPayloadPadding: {exact: true}}, {googScreencastMinBitrate: {exact: 100}}, {googCpuOveruseDetection: {exact: true}}, {googCpuOveruseEncodeUsage: {exact: true}}, {googCpuUnderuseThreshold: {exact: 55}}, {googCpuOveruseThreshold: {exact: 85}}]}

Below is the output of setRemoteDescription:

type: answer, sdp: v=0
o=- 1593674565548 2 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 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:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
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=extmap:2 www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=setup:passive
a=mid:audio
a=sendrecv
a=ice-ufrag:lOGK
a=ice-pwd:91UERQiJ8ROZ2eeUUZyBgMUi
a=fingerprint:sha-256 93:4B:35:15:E7:4B:FA:91:4F:6B:F4:A7:2D:B8:5D:AB:8F:46:51:18:19:12:34:65:10:17:E7:FC:67:29:87:C0
a=ssrc:2040799006 cname:rxoZmY3V14cP5ILm-2
a=ssrc:2040799006 msid:f7b7841a-665e-44b5-83c3-cb695ffe5bdd-2 5efc3b73-e417-4716-906f-34cd167e5b66-2
a=ssrc:2040799006 mslabel:f7b7841a-665e-44b5-83c3-cb695ffe5bdd-2
a=ssrc:2040799006 label:5efc3b73-e417-4716-906f-34cd167e5b66-2
a=rtcp-mux
m=video 1 RTP/SAVPF 102 96 97 98 99 100 101 120 127 119 125 107 108 109 124 118 123
c=IN IP4 0.0.0.0
a=rtpmap:102 H264/90000
a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=rtpmap:98 VP9/90000
a=rtpmap:99 rtx/90000
a=rtpmap:100 VP9/90000
a=rtpmap:101 rtx/90000
a=rtpmap:120 rtx/90000
a=rtpmap:127 H264/90000
a=rtpmap:119 rtx/90000
a=rtpmap:125 H264/90000
a=rtpmap:107 rtx/90000
a=rtpmap:108 H264/90000
a=rtpmap:109 rtx/90000
a=rtpmap:124 red/90000
a=rtpmap:118 rtx/90000
a=rtpmap:123 ulpfec/90000
a=fmtp:102 level-asymmetry-allowed=1; packetization-mode=1; profile-level-id=42001f
a=fmtp:97 apt=96
a=fmtp:98 profile-id=0
a=fmtp:99 apt=98
a=fmtp:100 profile-id=2
a=fmtp:101 apt=100
a=fmtp:120 apt=102
a=fmtp:127 level-asymmetry-allowed=1; packetization-mode=0; profile-level-id=42001f
a=fmtp:119 apt=127
a=fmtp:125 level-asymmetry-allowed=1; packetization-mode=1; profile-level-id=42e01f
a=fmtp:107 apt=125
a=fmtp:108 level-asymmetry-allowed=1; packetization-mode=0; profile-level-id=42e01f
a=fmtp:109 apt=108
a=fmtp:118 apt=124
a=rtcp:1 IN IP4 0.0.0.0
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9webrtc.org/experiments/rtp-hdrext/color-space
a=setup:passive
a=mid:video
a=sendrecv
a=ice-ufrag:lOGK
a=ice-pwd:91UERQiJ8ROZ2eeUUZyBgMUi
a=fingerprint:sha-256 93:4B:35:15:E7:4B:FA:91:4F:6B:F4:A7:2D:B8:5D:AB:8F:46:51:18:19:12:34:65:10:17:E7:FC:67:29:87:C0
a=ssrc:1311762970 cname:rxoZmY3V14cP5ILm-2
a=ssrc:1311762970 msid:deda1d3d-2ad8-42f2-a0b6-71dc56cedd64-2 35ec63d7-884e-4465-8823-9fe20d2b50b4-2
a=ssrc:1311762970 mslabel:deda1d3d-2ad8-42f2-a0b6-71dc56cedd64-2
a=ssrc:1311762970 label:35ec63d7-884e-4465-8823-9fe20d2b50b4-2
a=ssrc:1514369554 cname:rxoZmY3V14cP5ILm-2
a=ssrc:1514369554 msid:deda1d3d-2ad8-42f2-a0b6-71dc56cedd64-2 35ec63d7-884e-4465-8823-9fe20d2b50b4-2
a=ssrc:1514369554 mslabel:deda1d3d-2ad8-42f2-a0b6-71dc56cedd64-2
a=ssrc:1514369554 label:35ec63d7-884e-4465-8823-9fe20d2b50b4-2
a=ssrc-group:FID 1311762970 1514369554
a=rtcp-mux

Can’t even find an address/IP in there, but maybe I’m overlooking it?

This is the p2p peer connection, you need the other one, the peer connection to the bridge.

Have you solved this problem? I also encountered this problem with docker installation. When the second person joins the room, the room will crash in 15 seconds. Moreover, it is not under the same LAN. The video interface of two people is black, and the console error is the same as you. Thank you very much.

It is normal for me to install dcoker on a public network server, but it happens to you when I install docker on an intranet server. Thank you.

Sorry no, got my priorities a bit shifted.
I didn’t resolve it yet, I tried to gather the information @damencho asked but it fail to copy the details in time. When the connections cuts out, chrome://internals also removes the entries.

I only have about 30 seconds to copy the data, but it isn’t visible at start, a lot of log records show up around 20 seconds into the call, so that leaves me 10 seconds to find the correct log record.

Is there a way to stop the browser from refreshing the window after the call failed?

No, but you can click on preserve logs option:
image
And it will preserve the logs between reloads.

Well yes, this is true for the console log.
But that doesn’t work for the chrome://webrtc-internals page.

When a jitsi meet reloads, it removes the tab of the (no longer)active session.

EDIT: It seems that I can only find peer-to-peer sessions in the brief time that I have, is there something I can identify wether it’s a peer-to-peer or peer-to-bridge connection?

@Grixy,

You can use the url param config.p2p.enabled=false in your meeting URL.

Thank you for your response. It’s still crashing.
Assuming that it now only shows peer-to-bridge connections, this is the log of setRemoteDescription:

type: offer, sdp: v=0
o=- 1594374230882 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS mixedmslabel
a=group:BUNDLE audio video data
m=audio 10000 RTP/SAVPF 111 103 104 126
c=IN IP4 172.19.0.5
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:9 IN IP4 0.0.0.0
a=rtcp-fb:111 transport-cc
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:5 ietf .org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=setup:actpass
a=mid:audio
a=sendrecv
a=ice-ufrag:9dc461ecs1o4lf
a=ice-pwd:4kid27vk9bshg20lakr2p1tj98
a=fingerprint:sha-256 CB:EB:21:1B:EC:14:B7:88:A7:81:99:9B:FA:B4:1C:BF:71:77:1B:1A:3B:F8:52:1A:50:3E:96:8D:59:B8:43:BB
a=candidate:1 1 udp 2130706431 172.19.0.5 10000 typ host generation 0
a=ssrc:1877394699 cname:mixed
a=ssrc:1877394699 msid:mixedmslabel mixedlabelaudio0
a=ssrc:1877394699 mslabel:mixedmslabel
a=ssrc:1877394699 label:mixedlabelaudio0
a=rtcp-mux
m=video 10000 RTP/SAVPF 100 107 101 96 97 99
c=IN IP4 172.19.0.5
a=rtpmap:100 VP8/90000
a=rtpmap:107 H264/90000
a=rtpmap:101 VP9/90000
a=rtpmap:96 rtx/90000
a=rtpmap:97 rtx/90000
a=rtpmap:99 rtx/90000
a=fmtp:100 x-google-start-bitrate=800
a=fmtp:107 ;level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f;x-google-start-bitrate=800
a=fmtp:101 x-google-start-bitrate=800
a=fmtp:96 apt=100
a=fmtp:97 apt=101
a=fmtp:99 apt=107
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 transport-cc
a=rtcp-fb:107 ccm fir
a=rtcp-fb:107 nack
a=rtcp-fb:107 nack pli
a=rtcp-fb:107 transport-cc
a=rtcp-fb:101 ccm fir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=extmap:3 webrtc .org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 ietf .org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=setup:actpass
a=mid:video
a=sendrecv
a=ice-ufrag:9dc461ecs1o4lf
a=ice-pwd:4kid27vk9bshg20lakr2p1tj98
a=fingerprint:sha-256 CB:EB:21:1B:EC:14:B7:88:A7:81:99:9B:FA:B4:1C:BF:71:77:1B:1A:3B:F8:52:1A:50:3E:96:8D:59:B8:43:BB
a=candidate:1 1 udp 2130706431 172.19.0.5 10000 typ host generation 0
a=ssrc:3372644687 cname:mixed
a=ssrc:3372644687 msid:mixedmslabel mixedlabelvideo0
a=ssrc:3372644687 mslabel:mixedmslabel
a=ssrc:3372644687 label:mixedlabelvideo0
a=rtcp-mux
a=x-google-flag:conference
m=application 10000 DTLS/SCTP 5000
c=IN IP4 172.19.0.5
a=setup:actpass
a=mid:data
a=ice-ufrag:9dc461ecs1o4lf
a=ice-pwd:4kid27vk9bshg20lakr2p1tj98
a=fingerprint:sha-256 CB:EB:21:1B:EC:14:B7:88:A7:81:99:9B:FA:B4:1C:BF:71:77:1B:1A:3B:F8:52:1A:50:3E:96:8D:59:B8:43:BB
a=candidate:1 1 udp 2130706431 172.19.0.5 10000 typ host generation 0
a=sctpmap:5000 webrtc-datachannel 1024

Post your video bridge (jvb.log) file here as an attachment.

The room may also crash if the video bridge is not running or not properly registered with Jicofo. (I have found that adding bridges by component versus muc is more sensitive to the startup timing & order.)

Using docker, the log directory in /var/log/jitsi/ is empty.
Other than the docker container logs, is there a place I can grab/grep the logs?

Sadly, still not resolved.

In the meanwhile I tried several things but it just wont budge.
There’s too little documentation on this to figure out what’s happening on my own, and the lack of logging doesn’t help either.

Anything I can do to debug this further?

When you have reload screen first thing to do is check js console logs. Open empty tab with some page, set preserve logs in the console as described above and open the meeting once you see reload check the logs what is going on.