No video, only audio

Hi,

my setup used to work for month. Since a few days I only get audio but no video any more. What may cause this and how to start debugging this?

TIA
Matthias

Hard to say without any logs, maybe you could share with us logs from the client, jvb, jicofo? Did you make any changes to your setup recently? If not, are you maybe still on Plan-B with an origin trial key (that has expired)?

Thanks, how to get “client logs” and what is “Plan-B” and which “key”? My on premise setup didn’t change.

Hey, by client logs I mean the JavaScript logs that you can copy/paste from the JavaScript console in n the Chrome DevTools Console.

Plan-B is the old – and now deprecated – SDP format that was used to describe sessions Chrome. Now Chrome uses a new – the standard – format but has kept Plan B active for some users to help them transition to the new format. In order to stay on Plan B you had to apply for an origin trial key that you included in the HTML so Chrome knew that it had to use the old SDP format. If this is the problem, it will be visible in the JavaScript logs.

What version of Jitsi do you have installed on-premise?

If you setup has not been upgraded in a while, the issue that gpolitis mention will likely be (one of) the issue – Jitsi previously used Plan-B which is an SDP dialect used under the hood by Chrome’s WebRTC implementation. Support for Plan-B was recently dropped by Chrome in favour of Unified Plan. More recent versions of Jitsi now uses Unified Plan.

In short, your server setup has not changed, but client browsers have moved on and you might need to upgrade your Jitsi version to adapt to that change.

But if its planB thing, there will be no audio
… it sounds more like weird issue, or websocket problem … but why totally no video, no idea.

1 Like

The version problme was my first guess and I’ve updraded last friday to:

ii  jitsi-meet                        2.0.7001-1                         all          WebRTC JavaScript video conferences
ii  jitsi-meet-prosody                1.0.5913-1                         all          Prosody configuration for Jitsi Meet
ii  jitsi-meet-turnserver             1.0.5913-1                         all          Configures coturn to be used with     Jitsi Meet
ii  jitsi-meet-web                    1.0.5913-1                         all          WebRTC JavaScript video conferences
ii  jitsi-meet-web-config             1.0.5913-1                         all          Configuration for web serving ofJitsi Meet
ii  jitsi-videobridge2                2.1-634-gff8609ad-1                all          WebRTC compatible Selective Forwarding Unit (SFU)

Everything (audio, chat) works but video does not.

How and where can I start investigating?

Open the js console log in the browser (developer tools) and check for errors.

what do you mean by ‘no video’ ? is local video not displayed any more ? or is it just video of other people ? if it’s the latter, can you provide a screenshot (or an exact description of) the connection indicator for one of these bad connection (the connection indicator is the small colored rectangle to the top left of a tile in tile view, if you hover over it it display connection quality data). And the js console logs too.

Good question. Local video works but no one can seen any one else but himselfe.

In the JS console there are no errors after the room is opened by authentication. There are only very few warings.

I use a sepeerate TURN server listening on port 443. Both servers with a public IP, no NAT, no Nginx proxy. A few configs:

jvb.conf

videobridge {
    http-servers {
        public {
            port = 9090
        }
    }
    websockets {
        enabled = true
        domain = "xxx.im:443"
        tls = true
    }
}

sip-communicator.properties

org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=turnserver.xxx.im:443
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc,colibri
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=localhost
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.xxx.im
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=XXXXXXXX
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.xxx.im
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

turnserver.conf

listening-port=3478
tls-listening-port=443

listening-ip=1.2.3.4
relay-ip=1.2.3.4

min-port=32769
max-port=65535
verbose
log-file /var/log/turnserver/turnserver.log

fingerprint
use-auth-secret
static-auth-secret=8SYzA6SkwwxEyGp88
realm=xxx.im

cert=/etc/turnserver/fullchain.pem
pkey=/etc/turnserver/privkey.pem
cipher-list="ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
dh-file=/etc/turnserver/dhp.pem

keep-address-family
no-cli
no-tlsv1
no-tlsv1_1

no-loopback-peers
no-multicast-peers
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.168.0.0-192.168.255.255

My own connection indicator of the session I’m authenticated with:

Screenshot_20220412_084352

All others on all other sessions:

Screenshot_20220412_084448

This is nothing new, others always look like this for me.

bitrate 13kbps ? no wonder you get only audio. Now why is this bitrate so badly off, that’s the question. Now the usual question: are jvb websockets working ? if looking at the network tab in chrome console, do you see regular queries (every few seconds) and are these request succeeding ? to see something, you may need to open the chrome tools before starting a meeting.

Nothing there “every few seconds”. Attached the complet log.

js.log (81.6 KB)

3 clients.

strange you don’t see anything, websockets seem to be working according to the js logs. Could you post your config.js file ?

As requested …

config.txt (50.3 KB)

startAudioOnly: true,

are you sure that this is what you want ?

Does not change any thing …

Can you try to set EnableSaveLogs to true, start a meeting, then use the connection indicator to get the connection log and upload the json file here ?

As requested …

meetlog-mh001-A.txt (509.2 KB)

Here are the messages that your endpoint exchanged with the bridge (from the JS logs that you have shared)

% grep BridgeChannel Downloads/js.log     
Logger.js:154 2022-04-12T07:13:16.214Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onopen>:  websocket channel opened
Logger.js:154 2022-04-12T07:13:16.216Z [modules/RTC/BridgeChannel.js] <Co.sendNewReceiverVideoConstraintsMessage>:  Sending ReceiverVideoConstraints with {"constraints":{"240d4e2f":{"maxHeight":2160}},"defaultConstraints":{"maxHeight":0},"lastN":0,"onStageEndpoints":["240d4e2f"],"selectedEndpoints":[]}
Logger.js:154 2022-04-12T07:13:16.226Z [modules/RTC/BridgeChannel.js] <Co.sendNewReceiverVideoConstraintsMessage>:  Sending ReceiverVideoConstraints with {"constraints":{"240d4e2f":{"maxHeight":2160}},"defaultConstraints":{"maxHeight":0},"lastN":0,"onStageEndpoints":["240d4e2f"],"selectedEndpoints":[]}
Logger.js:154 2022-04-12T07:13:16.238Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onmessage>:  Received ServerHello, version=undefined.
Logger.js:154 2022-04-12T07:13:16.240Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onmessage>:  SenderVideoConstraints: {"idealHeight":2160}
Logger.js:154 2022-04-12T07:13:16.695Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onmessage>:  SenderVideoConstraints: {"idealHeight":0}
Logger.js:154 2022-04-12T07:13:45.087Z [modules/RTC/BridgeChannel.js] <Co.sendNewReceiverVideoConstraintsMessage>:  Sending ReceiverVideoConstraints with {"constraints":{"240d4e2f":{"maxHeight":360}},"defaultConstraints":{"maxHeight":0},"lastN":0,"onStageEndpoints":[],"selectedEndpoints":[]}
Logger.js:154 2022-04-12T07:13:45.272Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onmessage>:  SenderVideoConstraints: {"idealHeight":180}
Logger.js:154 2022-04-12T07:13:45.405Z [modules/RTC/BridgeChannel.js] <Co.sendNewReceiverVideoConstraintsMessage>:  Sending ReceiverVideoConstraints with {"constraints":{"240d4e2f":{"maxHeight":360},"da8ea739":{"maxHeight":360}},"defaultConstraints":{"maxHeight":0},"lastN":0,"onStageEndpoints":[],"selectedEndpoints":[]}
Logger.js:154 2022-04-12T07:13:46.114Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onmessage>:  SenderVideoConstraints: {"idealHeight":0}

The bridge has told your endpoint to not upload video (to save bandwidth), presumably because nobody’s watching you? This is done with the SenderVideoConstraints message.

Your endpoint has told the bridge to send 360p from two endpoints, presumably because you are in tile-view mode? This is done with the ReceiverVideoConstraints. The two endpoints that your endpoint is requesting in 360p are 240d4e2f and da8ea739 but I don’t see them in the screenshots that you shared with us. Are the logs and the screenshots from the same session?

I would expect the bridge to send back to your endpoint a LastNChanged message (after it has run its bandwidth distribution algorithm) that I don’t see in the JS logs. It would be good to have the jvb and jicofo logs as well – all from the same session – to be able to correlate the information and determine why the bridge isn’t sending the LastNChanged message to your endpoint.

All from one session:

jvb.txt (77.5 KB)
jicofo.txt (37.4 KB)
meetlog-mh001.txt (414.5 KB)

Again 3 clients.