Can't establish audio or video

[ChicagoJay]

Hello, once again.

I have created a video room on a Windows PC, with Chrome. I am able to join the room with an iPad, running Safari. However, no audio or video are transmitted. The slashed mic and video icons are present in the self screen, even though I have selected to allow video and audio. BEFORE the connection was established, audio and video were working.

Also, eventually, the iPad puts up a red message, saying "Unable to access camera. Please check if another application is using this device, select another device from the settings menu or try to reload the application." Options are to Dismiss or Contact support. The latter option brings up a new tab, to about:blank

2020.11.17 15:50:39 INFO [IceUdpTransportManager connect thread]: org.jitsi.impl.neomedia.MediaStreamImpl - audio remote IP/port: 10.72.16.68/64230
2020.11.17 15:50:39 INFO [IceUdpTransportManager connect thread]: org.jitsi.videobridge.Channel - CAT=stat transport_connected,conf_id=2d64f4b0fd2f9d06,content=video,ch_id=930b725c69ad09dd,endp_id=7b116a5d,stream=845704130
2020.11.17 15:50:39 INFO [IceUdpTransportManager connect thread]: org.jitsi.impl.neomedia.MediaStreamImpl - video codec/freq: null/null Hz
2020.11.17 15:50:39 INFO [IceUdpTransportManager connect thread]: org.jitsi.impl.neomedia.MediaStreamImpl - video remote IP/port: 10.72.16.68/64230
2020.11.17 15:50:39 INFO [IceUdpTransportManager connect thread]: org.jitsi.videobridge.Channel - CAT=stat transport_connected,conf_id=2d64f4b0fd2f9d06,content=data,ch_id=889bcd963ac873e1,endp_id=7b116a5d
2020.11.17 15:50:39 ERROR [org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.connectThread]: org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer - Failed to accept a connection from a DTLS client!
java.io.IOException: org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl is closed!
at org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl.assertNotClosed(DatagramTransportImpl.java:124) ~[libjitsi-1.0-20190724.114721-390.jar:?]
at org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl.send(DatagramTransportImpl.java:477) ~[libjitsi-1.0-20190724.114721-390.jar:?]
at org.bouncycastle.crypto.tls.DTLSRecordLayer.sendRecord(Unknown Source) ~[bcprov-jdk15on-1.64.jar:1.64.0]
at org.bouncycastle.crypto.tls.DTLSRecordLayer.send(Unknown Source) ~[bcprov-jdk15on-1.64.jar:1.64.0]
at org.bouncycastle.crypto.tls.DTLSReliableHandshake$RecordLayerBuffer.sendToRecordLayer(Unknown Source) ~[bcprov-jdk15on-1.64.jar:1.64.0]
at org.bouncycastle.crypto.tls.DTLSReliableHandshake.writeHandshakeFragment(Unknown Source) ~[bcprov-jdk15on-1.64.jar:1.64.0]
at org.bouncycastle.crypto.tls.DTLSReliableHandshake.writeMessage(Unknown Source) ~[bcprov-jdk15on-1.64.jar:1.64.0]
at org.bouncycastle.crypto.tls.DTLSReliableHandshake.resendOutboundFlight(Unknown Source) ~[bcprov-jdk15on-1.64.jar:1.64.0]
at org.bouncycastle.crypto.tls.DTLSReliableHandshake.receiveMessage(Unknown Source) ~[bcprov-jdk15on-1.64.jar:1.64.0]
at org.bouncycastle.crypto.tls.DTLSServerProtocol.serverHandshake(Unknown Source) ~[bcprov-jdk15on-1.64.jar:1.64.0]
at org.bouncycastle.crypto.tls.DTLSServerProtocol.accept(Unknown Source) ~[bcprov-jdk15on-1.64.jar:1.64.0]
at org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.runInConnectThread(DtlsPacketTransformer.java:1043) [libjitsi-1.0-20190724.114721-390.jar:?]
at org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.access$000(DtlsPacketTransformer.java:40) [libjitsi-1.0-20190724.114721-390.jar:?]
at org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer$1.run(DtlsPacketTransformer.java:1272) [libjitsi-1.0-20190724.114721-390.jar:?]
2020.11.17 15:50:39 INFO [org.jitsi.impl.neomedia.rtp.translator.OutputDataStreamImpl]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=1169163249 remainingRetries=9
2020.11.17 15:50:39 INFO [org.jitsi.impl.neomedia.RTPConnectorInputStream.receiveThread]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=2500364118 remainingRetries=9
2020.11.17 15:50:39 WARN [org.jitsi.impl.neomedia.RTPConnectorInputStream.receiveThread]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Not sending an FIR because the stream RTP manager is null.
2020.11.17 15:50:39 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=2500364118 remainingRetries=8
2020.11.17 15:50:39 WARN [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Not sending an FIR because the stream RTP manager is null.
2020.11.17 15:50:40 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=2500364118 remainingRetries=7
2020.11.17 15:50:40 WARN [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Not sending an FIR because the stream RTP manager is null.
2020.11.17 15:50:40 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=2500364118 remainingRetries=6
2020.11.17 15:50:40 WARN [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Not sending an FIR because the stream RTP manager is null.
2020.11.17 15:50:40 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=2500364118 remainingRetries=5
2020.11.17 15:50:40 WARN [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Not sending an FIR because the stream RTP manager is null.
2020.11.17 15:50:40 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=2500364118 remainingRetries=4
2020.11.17 15:50:40 WARN [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Not sending an FIR because the stream RTP manager is null.
2020.11.17 15:50:41 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=2500364118 remainingRetries=3
2020.11.17 15:50:41 WARN [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Not sending an FIR because the stream RTP manager is null.
2020.11.17 15:50:41 INFO [ice4j.Agent-timer-pool-13-thread-2]: org.ice4j.ice.Agent - ICE state changed from Completed to Terminated. Local ufrag c5iv41enc30bng
2020.11.17 15:50:41 INFO [ice4j.Agent-timer-pool-13-thread-2]: org.jitsi.videobridge.IceUdpTransportManager - CAT=stat ice_state_change,conf_id=2d64f4b0fd2f9d06,content=data,ch_id=5594655c41a63790,endp_id=e9728ee9 old_state=Completed,new_state=Terminated
2020.11.17 15:50:41 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=2500364118 remainingRetries=2
2020.11.17 15:50:41 WARN [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Not sending an FIR because the stream RTP manager is null.
2020.11.17 15:50:41 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=2500364118 remainingRetries=1
2020.11.17 15:50:41 WARN [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Not sending an FIR because the stream RTP manager is null.
2020.11.17 15:50:42 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Sending a FIR to ssrc=2500364118 remainingRetries=0
2020.11.17 15:50:42 WARN [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-RTCPFeedbackMessageSender]: org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender - Not sending an FIR because the stream RTP manager is null.
2020.11.17 15:50:42 INFO [ice4j.Agent-timer-pool-13-thread-2]: org.ice4j.ice.Agent - ICE state changed from Completed to Terminated. Local ufrag 5v8c11enc30bnm
2020.11.17 15:50:42 INFO [ice4j.Agent-timer-pool-13-thread-2]: org.jitsi.videobridge.IceUdpTransportManager - CAT=stat ice_state_change,conf_id=2d64f4b0fd2f9d06,content=data,ch_id=889bcd963ac873e1,endp_id=7b116a5d old_state=Completed,new_state=Terminated
2020.11.17 15:50:42 WARN [EndpointConnectionStatusMonitoring]: org.jitsi.videobridge.EndpointMessageTransport - SCTP connection with 7b116a5d not ready yet.
2020.11.17 15:50:42 WARN [EndpointConnectionStatusMonitoring]: org.jitsi.videobridge.EndpointMessageTransport - No available transport channel, can't send a message
2020.11.17 15:50:47 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-org.jitsi.videobridge.health.Health]: org.jitsi.videobridge.Videobridge - CAT=stat create_conf,conf_id=a36471d3cf647ba7 conf_name=null,logging=false,conf_count=4,ch_count=6,v_streams=4
2020.11.17 15:50:47 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-org.jitsi.videobridge.health.Health]: org.jitsi.videobridge.health.Health - Performed a successful health check in 9ms. Sticky failure: false

Thanks again for all your help!

[deleolajide]

FYI: I also asked for hints at https://community.jitsi.org/t/ice-harvester-of-jvb2-dont-recognize-public-address-of-clients/86256

In my case, it was not working because I assumed the new applications.conf overrides the old sip-communicator.properties file. It turns out that only new properties are picked from applications.conf. I still had to generate a sip-communicator.properties files from values entered into the admin networking web page.

I also implemented a websocket proxy because my Linux docker has only a single available TCP port for openfire 7443. I now proxy /colibri-ws from 7443 to 8080 and don't need a certificate for JVB2 websockets

[gjaekel]

I also implemented a websocket proxy because my Linux docker has only a single available TCP port for openfire 7443

You implement the websocket proxy inside the jetty? That's what I need, too. Because Jetty is running at 7443 (becaus it's running not as root, of course) and this is also translated to 443 by ip-tables. This is, what is visible on outside at the public IP

root@apprfire0 ~ # iptables-save 
# Generated by iptables-save v1.6.1 on Tue Nov 24 17:00:08 2020
*filter
:INPUT ACCEPT [170518118:73206841696]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [163318618:89514223924]
COMMIT
# Completed on Tue Nov 24 17:00:08 2020
# Generated by iptables-save v1.6.1 on Tue Nov 24 17:00:08 2020
*nat
:PREROUTING ACCEPT [216257534:13907088542]
:INPUT ACCEPT [25878380:3243377525]
:OUTPUT ACCEPT [4051937:243637533]
:POSTROUTING ACCEPT [4051937:243637533]
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 7443
COMMIT
# Completed on Tue Nov 24 17:00:08 2020

Is the proxy included inside the plugin JARs?

[deleolajide]

You implement it inside the jetty?

Yes. I am using haproxy to route 443 to 7743 as well. The extra TCP port for JVB2 was a pain for Docker

[gjaekel]

I am using haproxy

That's a big ship to just redirect one port :)

[gjaekel]

I just discover the sentence

If you are running this on the Internet or a WAN or behind a firewall, open TCP ports 8080/8443 for JVB websockets that has replaced WebRTC data channels

But with the current used Version (not the lastest you released this day), the JVM with the JVB2 just bound a listener to localhost:8080 not to 0.0.0.0:8080 and there's nothing that looks like a https listener at all.

But the announced websocket proxy functionality will resolve this ...

[dieghostz]

hi

I finally got it working on Linux and also working with Jitsi Mobile app

Hi I have tried the latest version released (today) on my server with: -Centos 7.9 -Openfire 4.6.0 -without NAT

I got it working with 3 users o more , but when join a third participant the screen sharing quality is bad. The camera also lowers its quality when a third participant joins. with two participants this does not happen.

I have opened the new ports in use 7443 and 8080

Tested with Google Chrome version 87.0.4280.66 (64 Bits)

Thanks for support

[gjaekel]

@deleolajide This is looking bad, isn't it?

20201124-185239.376 WARN  [pool-6-thread-1] [o.e.j.w.WebAppContext] Failed startup of context o.e.j.w.WebAppContext@5f058aff{/colibri-ws,file:///opt/openfire.4_6_1_20201020-171600/plugins/ofmeet/classes/jitsi-meet/,UNAVAILABLE}{/opt/openfire.4_6_1_20201020-171600/plugins/ofmeet/classes/jitsi-meet}
org.eclipse.jetty.util.MultiException: Multiple exceptions

[gjaekel]

First start using the latest JARs with fingers crossed: εὕρηκα! Note: This is still Chrome86.

Opened just tcp/443 and udp/10000 at the server.

[gjaekel]

Got inside the JS-console of the Chrome client:

lib-jitsi-meet.min.js:15686 WebSocket connection to 'wss://eval.xmpp.dnb.de:7443/colibri-ws/default-id/cda07e73d04d9061/e1fdadea?pwd=****************' failed: WebSocket opening handshake timed out

I seems that the ws proxy isn't up. I'm using '/' as context path of OFMeet. Might this be the reason that let the proxy servlet fail to start?

[deleolajide]

I seems that the ws proxy isn't up. I'm using '/' as context path of OFMeet. Might this be the reason that let the proxy servlet fail to start?

I just reset my server to root / and It worked for me. Remember to refresh the ofmeet plugin in admin web page to restart jvb and jifco

2020.11.24 21:54:22 ProxyWebSocket - : onMessage : Received :
{"colibriClass":"EndpointMessage","msgPayload":{"type":"e2e-ping-request","id":3},"to":"667fbe52"}
2020.11.24 21:54:22 ProxyConnection - ProxyConnection - deliver
{"colibriClass":"EndpointMessage","msgPayload":{"type":"e2e-ping-request","id":3},"to":"667fbe52"}

[gjaekel]

I just reset my server to root / and It worked for me. Remember to refresh the ofmeet plugin in admin web page to restart jvb and jifco

I'm a server guy; I don't use the GUI ;) And I'm well trained to run Java-Apps and servers. I simply stop the JVM, replace the sym-links to the JARs, archive the directories with exploded versions for later diffs and the next start will enroll the new versions.

[gjaekel]

Will install the V1.1.1 tomorrow. And I also have to compare and align the current log4j-config with my version and to provide a better log config for the spawned JVMs. Also, I want to work on my request to have a user-defined option string for the JVMs commandline to have control on GC parameters, number of used cores etc.

But first aim will be to shift the new stuff to the approval stage and with good luck to production before end of month.