Bridge Channel send: no opened channel

Hi,
I had a working setup with one jitsi meet server and multiple VBs, everything was working very well with no changes in any configuration.

Now I am getting this errors and now call more than 2 is working which means the bridges has some issues. Now I didn’t see this error before, Any ideas on how to fix that or even debugs.

thank you

This means that there is no data channel opened, you can check jvb logs, do you see any errors?

1 Like

@damencho @webhay I have the same issue. Can you help me?
my jvb logs looks ok:

2.09.2019 16:38:58JVB 2019-09-02 16:38:58.624 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 33ms. Sticky failure: false

2.09.2019 16:38:59JVB 2019-09-02 16:38:59.263 INFO: [17] org.jitsi.videobridge.VideobridgeExpireThread.log() Running expire()

2.09.2019 16:38:59JVB 2019-09-02 16:38:59.923 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@3cdc05ff

2.09.2019 16:39:04JVB 2019-09-02 16:39:04.925 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@3e312fae

2.09.2019 16:39:08JVB 2019-09-02 16:39:08.625 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=88e72e6a857326ed conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0

2.09.2019 16:39:08JVB 2019-09-02 16:39:08.643 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 18ms. Sticky failure: false

2.09.2019 16:39:09JVB 2019-09-02 16:39:09.926 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@4b18535a

2.09.2019 16:39:14JVB 2019-09-02 16:39:14.927 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@79311c31

2.09.2019 16:39:18JVB 2019-09-02 16:39:18.644 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=55049af32d306a67 conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0

2.09.2019 16:39:18JVB 2019-09-02 16:39:18.665 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 21ms. Sticky failure: false

2.09.2019 16:39:19JVB 2019-09-02 16:39:19.927 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@259e0d15

2.09.2019 16:39:24JVB 2019-09-02 16:39:24.928 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@12650a57

2.09.2019 16:39:28JVB 2019-09-02 16:39:28.666 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=107807e8ded2f41f conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0

2.09.2019 16:39:28JVB 2019-09-02 16:39:28.685 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 19ms. Sticky failure: false

2.09.2019 16:39:29JVB 2019-09-02 16:39:29.929 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@1b6e09c2

2.09.2019 16:39:34JVB 2019-09-02 16:39:34.929 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@6acf5e0a

2.09.2019 16:39:38JVB 2019-09-02 16:39:38.686 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=9034e211ab299e68 conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0

2.09.2019 16:39:38JVB 2019-09-02 16:39:38.701 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 15ms. Sticky failure: false

2.09.2019 16:39:39JVB 2019-09-02 16:39:39.930 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@3f6c10e3

2.09.2019 16:39:44JVB 2019-09-02 16:39:44.931 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@56182eb

2.09.2019 16:39:48JVB 2019-09-02 16:39:48.705 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=69f4f9859c56d96c conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0

2.09.2019 16:39:48JVB 2019-09-02 16:39:48.752 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 47ms. Sticky failure: false

2.09.2019 16:39:49JVB 2019-09-02 16:39:49.933 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@6eaaab9c

2.09.2019 16:39:54JVB 2019-09-02 16:39:54.936 INFO: [14] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.colibri.ColibriStatsExtension@7e05974d

2.09.2019 16:39:58JVB 2019-09-02 16:39:58.757 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=6d6f27633c4c2453 conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0

2.09.2019 16:39:58JVB 2019-09-02 16:39:58.776 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 19ms. Sticky failure: false

2.09.2019 16:39:59JVB 2019-09-02 16:39:59.264 INFO: [17] org.jitsi.videobridge.VideobridgeExpireThread.log() Running expire()

I don’t remember exactly what I have done. But some errors like that specially if the VB was working before. I spin another instance and make sure it is working. And then kill the faulty one. Assuming you have check all the connectivity between the VB and the res of the service are OK.

Please check if you are also connected thru VPN. Just turn it off.

Are there any event to handle this error? I’ve got this case too.

I have the same problem, please help me fix this, all my udp ports are opened and no errors on my log files, what can it be?

I have the same problem

Hey everyone! I can solve this problem, I just changed my option
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<Local_Adress>
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<Public_Adress>
at
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Local_Adress>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public_Adress>
on sip-communicator.properties
Hope it help somebody)

1 Like

Hi everyone i am having the same error as

[modules/RTC/BridgeChannel.js] <e.value>: Bridge Channel send: no opened channel.

I have added the above mentioned config also
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Local_Adress>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public_Adress>

Still no luck. Reinstalled everything but still having the same issue.

What about forwarding of the ports, is that done and working? And open them on the firewall if any.

Hi @damenchom, thanyou very much for response

these are allowed in firewall . checked using ufw status

To Action From


22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
10000:20000/udp ALLOW Anywhere
4443 ALLOW Anywhere
5347 ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
10000:20000/udp (v6) ALLOW Anywhere (v6)
4443 (v6) ALLOW Anywhere (v6)
5347 (v6) ALLOW Anywhere (v6)

i am able to connect udp port via nc -vu 44.233.214.207 10000

I miss the part defining the port forwarding. Can you please explain more on which ports are to be forwarded and destination?

Currently checked forwarding via sudo iptables -t nat -vnL I get following response

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

The device with IP 44.233.214.207 if it is different than the machine JVB is running, that device need to forward port 443 tcp and 10000 udp to the internal ip address of jvb.

It’s running on the same machine.
conference@conference : ~ $ sudo /etc/init.d/jitsi-videobridge status

[sudo] password for conference:

jitsi-videobridge.service - Jitsi Videobridge

Loaded: loaded (/lib/systemd/system/jitsi-videobridge.service; enabled; vendor preset: enabled)

Active: active (running) since Sat 2020-02-29 12:18:22 UTC; 2 days ago

Main PID: 20167 (java)

Tasks: 74 (limit: 65000)

CGroup: /system.slice/jitsi-videobridge.service

└─20167 java -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDum…AA

Feb 29 12:18:22 conference.shadecube.com systemd[1]: jitsi-videobridge.servic…/a

Feb 29 12:18:22 conference.shadecube.com systemd[1]: jitsi-videobridge.servic…’.

Feb 29 12:18:22 conference.shadecube.com systemd[1]: Stopped Jitsi Videobridge.

Feb 29 12:18:22 conference.shadecube.com systemd[1]: Starting Jitsi Videobrid……

Feb 29 12:18:22 conference.shadecube.com systemd[1]: Started Jitsi Videobridge.

Hint: Some lines were ellipsized, use -l to show in full.

What else can i check?

You say jvb is running on this machine:

?

Delete /var/log/jitsi/jvb.log, restart jvb and upload the log.

Here the fresh logs

root@conference:/var/log/jitsi# tail -f jvb.log

JVB 2020-03-04 06:58:47.851 FINE: [131] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId x96lJ-175371):

JVB 2020-03-04 06:58:47.853 FINE: [131] org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving component ‘JitsiVideobridge’) Processing IQ request (packetId x96lJ-175371).

JVB 2020-03-04 06:58:47.860 FINE: [131] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Responding to IQ (packetId x96lJ-175371) with:

JVB 2020-03-04 06:58:48.043 WARNING: [15] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with a5378e98 not ready yet.

JVB 2020-03-04 06:58:48.043 WARNING: [15] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message

JVB 2020-03-04 06:58:48.043 WARNING: [15] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with 9c207ccc not ready yet.

JVB 2020-03-04 06:58:48.043 WARNING: [15] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message

JVB 2020-03-04 06:58:53.997 FINE: [133] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId vT88v-34):

JVB 2020-03-04 06:58:54.160 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=a3e5e4e8b6f45f6b conf_name=null,logging=false,conf_count=2,ch_count=6,v_streams=4

JVB 2020-03-04 06:58:54.222 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 62ms. Sticky failure: false

JVB 2020-03-04 06:58:57.852 FINE: [153] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId x96lJ-175375):

JVB 2020-03-04 06:58:57.852 FINE: [153] org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving component ‘JitsiVideobridge’) Processing IQ request (packetId x96lJ-175375).

JVB 2020-03-04 06:58:57.857 FINE: [153] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Responding to IQ (packetId x96lJ-175375) with:

JVB 2020-03-04 06:59:03.995 FINE: [60] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId vT88v-38):

JVB 2020-03-04 06:59:04.223 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=e79d38d904e22160 conf_name=null,logging=false,conf_count=2,ch_count=6,v_streams=4

JVB 2020-03-04 06:59:04.268 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 46ms. Sticky failure: false

JVB 2020-03-04 06:59:07.852 FINE: [62] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId x96lJ-175379):

JVB 2020-03-04 06:59:07.852 FINE: [62] org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving component ‘JitsiVideobridge’) Processing IQ request (packetId x96lJ-175379).

JVB 2020-03-04 06:59:07.854 FINE: [62] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Responding to IQ (packetId x96lJ-175379) with:

JVB 2020-03-04 06:59:13.990 FINE: [64] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId vT88v-42):

JVB 2020-03-04 06:59:14.269 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=739d10920ded8afe conf_name=null,logging=false,conf_count=2,ch_count=6,v_streams=4

JVB 2020-03-04 06:59:14.306 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 37ms. Sticky failure: false

JVB 2020-03-04 06:59:17.818 FINE: [70] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId x96lJ-175391):

JVB 2020-03-04 06:59:17.819 FINE: [70] org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving component ‘JitsiVideobridge’) Processing IQ request (packetId x96lJ-175391).

JVB 2020-03-04 06:59:17.819 FINE: [70] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Responding to IQ (packetId x96lJ-175391) with:

JVB 2020-03-04 06:59:17.852 FINE: [75] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId x96lJ-175393):

JVB 2020-03-04 06:59:17.852 FINE: [75] org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving component ‘JitsiVideobridge’) Processing IQ request (packetId x96lJ-175393).

JVB 2020-03-04 06:59:17.854 FINE: [75] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Responding to IQ (packetId x96lJ-175393) with:

JVB 2020-03-04 06:59:22.106 INFO: [17] org.jitsi.videobridge.VideobridgeExpireThread.log() Running expire()

JVB 2020-03-04 06:59:23.990 FINE: [77] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId vT88v-46):

JVB 2020-03-04 06:59:24.307 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=ee59b5476af71702 conf_name=null,logging=false,conf_count=2,ch_count=6,v_streams=4

JVB 2020-03-04 06:59:24.374 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 67ms. Sticky failure: false

JVB 2020-03-04 06:59:27.852 FINE: [74] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId x96lJ-175398):

JVB 2020-03-04 06:59:27.852 FINE: [74] org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving component ‘JitsiVideobridge’) Processing IQ request (packetId x96lJ-175398).

JVB 2020-03-04 06:59:27.854 FINE: [74] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Responding to IQ (packetId x96lJ-175398) with:

JVB 2020-03-04 06:59:33.991 FINE: [79] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId vT88v-50):

JVB 2020-03-04 06:59:34.375 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=6e37b79cd26a9e28 conf_name=null,logging=false,conf_count=2,ch_count=6,v_streams=4

JVB 2020-03-04 06:59:34.409 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 34ms. Sticky failure: false

JVB 2020-03-04 06:59:37.852 FINE: [103] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId x96lJ-175402):

JVB 2020-03-04 06:59:37.852 FINE: [103] org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving component ‘JitsiVideobridge’) Processing IQ request (packetId x96lJ-175402).

JVB 2020-03-04 06:59:37.853 FINE: [103] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Responding to IQ (packetId x96lJ-175402) with:

JVB 2020-03-04 06:59:43.990 FINE: [100] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component ‘JitsiVideobridge’) Processing IQ (packetId vT88v-54):

JVB 2020-03-04 06:59:44.410 INFO: [18] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=d4b761cc5ae27b5f conf_name=null,logging=false,conf_count=2,ch_count=6,v_streams=4

JVB 2020-03-04 06:59:44.441 INFO: [18] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 31ms. Sticky failure: false

in console error
2020-03-04T06:58:28.621Z [modules/xmpp/ChatRoom.js] No meeting ID from backend

Logger.js:154 2020-03-04T07:00:41.264Z [JitsiConference.js] <e.sendMessage>: Failed to send E2E ping request or response.
2020-03-04T07:00:33.019Z [modules/RTC/BridgeChannel.js] <e.value>: Bridge Channel send: no opened channel.

I know this an old thread but I have recently had the same issue and this is how I resolved it in clear steps for anyone that comes across the same problem:

Regardless if your Jitsi Meet server is behind NAT or not I found editing this file with your local and public IP address is a must along with making sure the correct ports are internet facing for your server.

My Jitsi-Meet server is installed on an Ubuntu 18.04 LTS box so i needed to edit the following file as root:

nano /etc/jitsi/videobridge/sip-communicator.properties

A default installation only has 1 line in there so you will need to add the following 2 lines with your correct IP addresses i.e.

org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=127.0.0.1
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=11.22.33.44

Please note that the 127.0.0.1 ip address refers to your local IP address and the 11.22.33.44 should be changed to your public IP address (the one you get when you resolve your servers DNS name, I used nslookup to confirm it)

Then you save and close the file and restart the videobridge * probably not needed but i did it anyway.

sudo service jitsi-videobridge restart

Next you need to ensure these ports on your server are open to the internet and any devices between the server and internet provider are also open and point the ports back to your server:

80 - so people visiting can be redirected to your https site
443 - access to your https site
10000-20000 - For the audio, video and media etc…

That’s it your done you should no longer get the “Bridge Channel send: no opened channel” error.
If you still get it then its likely that your internet source for your client device is restricting port use so try another internet provider. As an example my work uses a TLS proxy and its very strict so audio and video will not work even though I can connect to the server web page fine.

Hope this helps someone out in the future! :wink:

1 Like

Hey, thanks for the detailed explanation @Jitsi-Problem-Solver !
I’m running the service in a docker container and editing the file was a pain in the butt, didn’t solve my problem…
My solution was to disable all firewall rules, I’m now going to check exactly what is needed to be enabled…
I’ve tried:
TCP: 80, 443, 4443, 8443, 10000,
UDP: 20000-65535 (this is probably the problem)
And all outgoing TCP and UDP

Hope it helps!

So, about ports, according to [jitsi-dev] Understanding STUN for jitsi-meet is seems to be:

  • TCP: 80, 443, 4443 (optionnal) (by default, for installation through packages)
  • UDP: 10000 (only that one, not a range)

For me this works even behind a reverse nginx proxy that handles the TLS stuff. I still didn’t manage to work unencrypted between jitsi-meet and the reverse proxy.

About ICE config, the one here 2 posts before did not work. But after a few hours debugging I stumbled on the documentation (!) and theses lines worked. Very similar but makes the difference for me.

Direct § link: https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md#advanced-configuration

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<Local.IP.Address>
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address>

With all this, it works well on a VM behind a NAT, and with a reverse (nginx) proxy. Also, good to know, but to debug this in Firefox, you can find a lot of informations in about:webrtc, where I saw again and again that the local (NATed) address were used.