Videobridge Error because of SSL inspection

Hello,

we currently have the problem that in very restrictive firewalls, the connection to the videobridge fails because of an SSL error.

Does anyone know if it’s possible to setup videobridge with a valid SSL certficate.
When using a Turn server with a valid certificate it is possible to establish the connection but this is only possible 1on1

Thanks!

Turn server can relay media to the bridge. If you have turn already configured, just enable https://github.com/jitsi/jitsi-meet/blob/1e3e15fc72eb3dde5bea0f6947628c35e5826785/config.js#L258

Hi,

thanks for your answer!

We have configured useSturnTurn: true and we are also getting credentials back. However, we also see a direct connection to the video bridge. Once this fails, the conference fails and reloads. Do we have to load another module or disable the TCP harvester at the bridge?
Do we have to configure the turn server in addition to setting a shared secret and enabling shared auth? Is there any flowchart of the different connection types (p2p, turn, jvb via turn, jvb direct)?

Our current config: We have TCP harvester enabled, let jvb collect its IP via STUN and have useStunTurn enabled in config.js. Also we have p2p disabled. (incl. STUN_MAPPING_HARVESTER_ADDRESSES configured)

We are not sure why the client doesn’t connect to the turn server at all.

Thanks

Have you setup turn with correct shared password and correct prosody config:

And if turn is in place used for turns than you should disable the tcp harvester in the bridge and let turn handle the tcp.

So the connections can be
p2p:
client1 <-> client2
client1 <- turn -> client2
jvb:
client1 <- jvb -> client2
client1 <- turn -><- jvb -> client2

"We set up everything like this and could verify the sucessfull authentication in Wireshark. However if the TCP harvester is disabled we only get local IPs as candidates (as expected) which for us results in the No opened bridge channel error message on the clients which leads to reloading of conferences.

This is miss configuration of the bridge, https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart#advanced-configuration
You need

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

or org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
in your config.

I think we have exactly the second one as configuration.
Do we need an additional thing to check?

Try the first one maybe … Bridge not advertising its public address is a problem, even though I don’t see how that relates to tcp harvester

Thanks, we checked it again including the jitsi source code and saw that we missed the turn"s" in the configuration. Now the client successfully connects to the turnserver but at the same time it also connects to the videobridge which fails. But there should only be the connection to the turn server.
Any ideas why it still connects to the videobridge?

One additional thing what we found out that meet.jit.si is using websockets as datachannel to prevent connecting to the videobridge - is this correct? Is there also a way not using websockets (i.e. XHR)?

We now enabled WebSockets for the bridge data channel. However, after a few seconds the WebSocket closes and following retries give a 403 from here: https://github.com/jitsi/jitsi-videobridge/blob/master/jvb/src/main/java/org/jitsi/videobridge/websocket/ColibriWebSocketServlet.java#L152 (see also Enabled the jvb to use websocket. log report nonexistent endpoint).

Sorry for the different messages, we want to shortly summarize what our current status is:

  • We have the turncredentials module working (using useStunTurn: true) and we manually checked that the credentials arrive at the browser and that they work with our TURN server
  • We have set openBridgeChannel: ‘websocket’ and we can see packets inside the websocket
  • The WebSocket fails after a few seconds and reconnections get a HTTP 403 status
  • We cannot see traffic between the video bridge an the TURN server
  • We only get candidates with an internal IP (as expected)
  • The TCP harvester is enabled from our environment variables
  • Our jvb config is as follows (we set the nat harvester IPs to 127.0.0.1 to prevent it from using it as candidates):

org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT={{ .Env.JVB_PORT }}
org.jitsi.videobridge.DISABLE_TCP_HARVESTER={{ .Env.JVB_TCP_HARVESTER_DISABLED }}
org.jitsi.videobridge.TCP_HARVESTER_PORT={{ .Env.JVB_TCP_PORT }}
{{ if .Env.JVB_STUN_SERVERS }}
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES={{ .Env.JVB_STUN_SERVERS }}
{{ end }}

org.jitsi.videobridge.xmpp.user.shard.HOSTNAME={{ .Env.XMPP_SERVER }}
org.jitsi.videobridge.xmpp.user.shard.DOMAIN={{ .Env.XMPP_AUTH_DOMAIN }}
org.jitsi.videobridge.xmpp.user.shard.USERNAME={{ .Env.JVB_AUTH_USER }}
org.jitsi.videobridge.xmpp.user.shard.PASSWORD={{ .Env.JVB_AUTH_PASSWORD }}
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS={{ .Env.JVB_BREWERY_MUC }}@{{ .Env.XMPP_INTERNAL_MUC_DOMAIN }}
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME={{ .Env.HOSTNAME }}
org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc,colibri
org.jitsi.videobridge.STATISTICS_INTERVAL=5000

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=127.0.0.1
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=127.0.0.1

org.jitsi.videobridge.rest.jetty.port=8888
org.jitsi.videobridge.rest.COLIBRI_WS_TLS=true
org.jitsi.videobridge.rest.COLIBRI_WS_DOMAIN=
org.jitsi.videobridge.rest.COLIBRI_WS_SERVER_ID=jitsitest2

  • Our prosody config is:

consider_bosh_secure = true;
cross_domain_websocket = true;
consider_websocket_secure = true;

turncredentials_secret = “north”

turncredentials = {
{ type = “turns”, host = “callingtest.”, port = “30890” },
{ type = “turns”, host = “callingtest.”, port = “30890”, transport=“tcp” }
}

Do we understand it correctly, that in this setup the browser and the video bridge communicate over the data channel websocket and then send their video data over the TURN-server? Do you know what could cause the issue with the WebSocket?

Thanks for the help, we solved the problem.

There error was a wrong SSL certificate at the turn server. Unfortunately the browsers havent shown an error here for the turn server.

1 Like

@damencho Thanks a lot for your help. Currently we are having the problem that Firefox is not working correctly with turn server becuase it choses the wrong candidate. Only after a few video on/off cycles somehow the right candidate gets validated. I’m not sure if it is a bug or a misconfiguration of our side (because meet.jit.si is working.

Maybe you can help. Thanks.