Can't enter a room - ubuntu install

Hi, I am a newbie to jitsi, but very enthousiastic about that since it matches exactly my requirements.

I used the nightlies ubuntu repository and installed the necessary packages using this command:
sudo apt-get -y install jitsi-meet

Everything went OK, I was even able to set up let’sencrypt certs correctly. I’m running Apache2 on a public IP address.

I can see the main page in the browser but I can’t enter any room, it says “Unfortunately, something went wrong.” and it is trying to reconnect.

There are some errors in the logs:

/var/log/jitsi/jicofo.log:

Jicofo 2020-03-14 18:48:06.524 WARNING: [75] org.jitsi.jicofo.xmpp.FocusComponent.processIQ() (serving component ‘Jitsi Meet Focus’) Unexpected exception while processing IQ stanza:
net.java.sip.communicator.service.protocol.OperationFailedException: Failed to join the room
at org.jitsi.impl.protocol.xmpp.ChatRoomImpl.joinAs(ChatRoomImpl.java:298)
at org.jitsi.impl.protocol.xmpp.ChatRoomImpl.join(ChatRoomImpl.java:209)
at org.jitsi.jicofo.JitsiMeetConferenceImpl.joinTheRoom(JitsiMeetConferenceImpl.java:561)
at org.jitsi.jicofo.JitsiMeetConferenceImpl.start(JitsiMeetConferenceImpl.java:387)
at org.jitsi.jicofo.FocusManager.conferenceRequest(FocusManager.java:413)
at org.jitsi.jicofo.FocusManager.conferenceRequest(FocusManager.java:362)
at org.jitsi.jicofo.FocusManager.conferenceRequest(FocusManager.java:337)
at org.jitsi.jicofo.xmpp.FocusComponent.handleConferenceIq(FocusComponent.java:421)
at org.jitsi.jicofo.xmpp.FocusComponent.handleIQSetImpl(FocusComponent.java:259)
at org.jitsi.xmpp.component.ComponentBase.handleIQSet(ComponentBase.java:362)
at org.xmpp.component.AbstractComponent.processIQRequest(AbstractComponent.java:515)
at org.xmpp.component.AbstractComponent.processIQ(AbstractComponent.java:289)
at org.xmpp.component.AbstractComponent.processQueuedPacket(AbstractComponent.java:239)
at org.xmpp.component.AbstractComponent.access$100(AbstractComponent.java:81)
at org.xmpp.component.AbstractComponent$PacketProcessor.run(AbstractComponent.java:1051)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.jivesoftware.smack.XMPPException$XMPPErrorException: XMPP error reply received from conference.mydomain: XMPPError: remote-server-not-found - cancel
at org.jivesoftware.smack.XMPPException$XMPPErrorException.ifHasErrorThenThrow(XMPPException.java:132)
at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:263)
at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:214)
at org.jivesoftware.smackx.disco.ServiceDiscoveryManager.discoverInfo(ServiceDiscoveryManager.java:540)
at org.jivesoftware.smackx.disco.ServiceDiscoveryManager.discoverInfo(ServiceDiscoveryManager.java:506)
at org.jivesoftware.smackx.disco.ServiceDiscoveryManager.supportsFeatures(ServiceDiscoveryManager.java:748)
at org.jivesoftware.smackx.disco.ServiceDiscoveryManager.supportsFeatures(ServiceDiscoveryManager.java:744)
at org.jivesoftware.smackx.disco.ServiceDiscoveryManager.supportsFeature(ServiceDiscoveryManager.java:740)
at org.jivesoftware.smackx.muc.MultiUserChatManager.providesMucService(MultiUserChatManager.java:361)
at org.jivesoftware.smackx.muc.MultiUserChat.enter(MultiUserChat.java:311)
at org.jivesoftware.smackx.muc.MultiUserChat.createOrJoin(MultiUserChat.java:498)
at org.jivesoftware.smackx.muc.MultiUserChat.createOrJoin(MultiUserChat.java:444)
at org.jitsi.impl.protocol.xmpp.ChatRoomImpl.joinAs(ChatRoomImpl.java:240)

and in /var/log/jitsi/jvb.log

JVB 2020-03-14 18:51:19.322 WARNING: [16] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with 68feab5f0e859cd4 not ready yet.
JVB 2020-03-14 18:51:19.323 WARNING: [16] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message
JVB 2020-03-14 18:51:19.323 WARNING: [16] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with 82cee6f1e8243a81 not ready yet.
JVB 2020-03-14 18:51:19.323 WARNING: [16] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message

and in prosody.log:

Mar 14 18:56:05 conference.mydomain:muc_domain_mapper warn Session filters applied
Mar 14 18:56:05 s2sout1837f00 info Sending error replies for 1 queued stanzas because of failed outgoing connection to conference.mydomain
Mar 14 18:56:05 mod_s2s warn Connection to conference.mydomain failed already, destroying session…

Any suggestions? Thanks.

Can you paste your prosody and jicofo configurations?

Jicofo config:

Jitsi Conference Focus settings

sets the host name of the XMPP server

JICOFO_HOST=localhost

sets the XMPP domain (default: none)

JICOFO_HOSTNAME=mydomain

sets the secret used to authenticate as an XMPP component

JICOFO_SECRET=#c0C7nfZ

sets the port to use for the XMPP component connection

JICOFO_PORT=5347

sets the XMPP domain name to use for XMPP user logins

JICOFO_AUTH_DOMAIN=auth.mydomain

sets the username to use for XMPP user logins

JICOFO_AUTH_USER=focus

sets the password to use for XMPP user logins

JICOFO_AUTH_PASSWORD=MOoWwZSd

extra options to pass to the jicofo daemon

JICOFO_OPTS=""

adds java system props that are passed to jicofo (default are for home and logging config file)

JAVA_SYS_PROPS="-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=jicofo -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi -Djava.util.logging.config.file=/etc/jitsi/jicofo/logging.properties"

Prosody
mydomain.cfg.lua:
plugin_paths = { “/usr/share/jitsi-meet/prosody-plugins/” }

– domain mapper options, must at least have domain base set to use the mapper
muc_mapper_domain_base = “mydomain”;

turncredentials_secret = “ynhROgQA”;

turncredentials = {
{ type = “stun”, host = “mydomain”, port = “443” },
{ type = “turn”, host = “mydomain”, port = “443”, transport = “udp” },
{ type = “turns”, host = “mydomain”, port = “443”, transport = “tcp” }
};

cross_domain_bosh = false;
consider_bosh_secure = true;

VirtualHost “mydomain”
– enabled = false – Remove this line to enable this host
authentication = “anonymous”
– Properties below are modified by jitsi-meet-tokens package config
– and authentication above is switched to “token”
–app_id=“example_app_id”
–app_secret=“example_app_secret”
– Assign this host a certificate for TLS, otherwise it would use the one
– set in the global section (if any).
– Note that old-style SSL on port 5223 only supports one certificate, and will always
– use the global one.
ssl = {
key = “/etc/prosody/certs/mydomain.key”;
certificate = “/etc/prosody/certs/mydomain.crt”;
}
speakerstats_component = “speakerstats.mydomain”
conference_duration_component = “conferenceduration.mydomain”
– we need bosh
modules_enabled = {
“bosh”;
“pubsub”;
“ping”; – Enable mod_ping
“speakerstats”;
“turncredentials”;
“conference_duration”;
}
c2s_require_encryption = false

Component “conference.mydomain” “muc”
storage = “null”
modules_enabled = {
“muc_meeting_id”;
“muc_domain_mapper”;
– “token_verification”;
}
admins = { “focus@auth.mydomain” }

– internal muc component
Component “internal.auth.mydomain” “muc”
storage = “null”
modules_enabled = {
“ping”;
}
admins = { “focus@auth.mydomain”, “jvb@auth.mydomain” }

VirtualHost “auth.mydomain”
ssl = {
key = “/etc/prosody/certs/auth.mydomain.key”;
certificate = “/etc/prosody/certs/auth.mydomain.crt”;
}
authentication = “internal_plain”

Component “focus.mydomain”
component_secret = “#c0C7nfZ

Component “speakerstats.mydomain” “speakerstats_component”
muc_component = “conference.mydomain”

Component “conferenceduration.mydomain” “conference_duration_component”
muc_component = “conference.mydomain”

I was able to solve one part of the problem.

In /etc/jitsi/meet/mydomain-config.js
I found this strange string (it was probably created during installation)

muc: ‘conference.!–# echo var=“subdomain” default="" --mydomain’

I’m not running on any subdomain, so I simply changed it into:

muc: ‘conference.mydomain’

and the following error disappeared from jicofo.log:

Caused by: org.jivesoftware.smack.XMPPException$XMPPErrorException: XMPP error reply received from conference.mydomain: XMPPError: remote-server-not-found - cancel

Now I’m allowed to enter a room and my camera and microphone are activated.

Unfortunately, when I try to enter the same room with another user, the session crashes on both sides and the error “Unfortunately, something went wrong.” appears and loops.

The error in /var/log/jitsi/jvb.log persists:

JVB 2020-03-14 18:51:19.322 WARNING: [16] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with 68feab5f0e859cd4 not ready yet.
JVB 2020-03-14 18:51:19.323 WARNING: [16] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message
JVB 2020-03-14 18:51:19.323 WARNING: [16] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with 82cee6f1e8243a81 not ready yet.
JVB 2020-03-14 18:51:19.323 WARNING: [16] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message

Any suggestions what to do?

What do the prosody logs say?

After some minor changes I was able to get rid of the “crashing error” (I moved jitsi to a subdomain now) and clients can enter rooms and stay there, it doesn’t crash)

However, it seems like media data don’t pass.

The mobile app cannot even enter any room and the above mentioned last error persists (SCTP connection not ready yet and "no available transport channel, can’t send a message)

The clients in the web browser can see their own video, but not the other clients’ video (the camera and microphone are allowed for each client). The sound doesn’t work either.

No obvious errors in prosody log:

Mar 18 12:32:22 boshffbf5c85-5fe9-4652-9260-852b806e329d info BOSH client disconnected: session close
Mar 18 12:32:37 speakerstats.subdomain.mydomain.cz:speakerstats_component warn A module has been configured that triggers external events.
Mar 18 12:32:37 speakerstats.subdomain.mydomain.cz:speakerstats_component warn Implement this lib to trigger external events.
Mar 18 12:32:37 boshc6e3f1b7-41a2-4265-accc-f65ef409fbcd info BOSH client disconnected: session close
Mar 18 12:33:09 conference.subdomain.mydomain.cz:muc_domain_mapper warn Session filters applied
Mar 18 12:33:09 mod_bosh info New BOSH session, assigned it sid ‘e226c93d-c61d-4f99-bf31-d2521cc83b14’
Mar 18 12:33:09 boshe226c93d-c61d-4f99-bf31-d2521cc83b14 info Authenticated as qsd0r7yqh2taptew@guest.subdomain.mydomain.cz
Mar 18 12:33:31 conference.subdomain.mydomain.cz:muc_domain_mapper warn Session filters applied
Mar 18 12:33:31 mod_bosh info New BOSH session, assigned it sid ‘931f6d1c-b061-4ce6-a431-afb6a1be1faf’
Mar 18 12:33:31 bosh931f6d1c-b061-4ce6-a431-afb6a1be1faf info Authenticated as -amsd6ue_ca-nklm@guest.subdomain.mydomain.cz

Now I’m running jitsi on a subdomain:
subdomain.domain
and there is a website running on Apache on the domain.

Can the problem be hidden somewhere there? (Port 443?)

Please follow this link might be help you https://raj-yadav-webrtc.blogspot.com/

Thank you. I’m not going to follow all the steps from the really beginning since jitsi is already running.

However the settings in /etc/jitsi/videobridge/sip-communicator.properties differ from mine:

org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=localhost
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.subdomain.mydomain.cz
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=CKxtx1iT
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.subdomain.mydomain.cz
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=273b29b6-3c95-414c-9fa5-12887ec0ed3d

TCP_HARVESTER is disabled, do I really need it? The server is running on a public IP.

After many hours digging into the settings I still can’t find any solution to this never-ending problem:

/var/log/jitsi/jvb.log

JVB 2020-03-19 12:06:47.645 WARNING: [84] org.ice4j.ice.Agent.log() Agent contains no IceMediaStream with name stream!
JVB 2020-03-19 12:06:55.794 WARNING: [615] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with d00be449 not ready yet.
JVB 2020-03-19 12:06:55.794 WARNING: [615] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message
JVB 2020-03-19 12:06:56.799 WARNING: [616] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with d00be449 not ready yet.
JVB 2020-03-19 12:06:56.799 WARNING: [616] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message
JVB 2020-03-19 12:06:57.652 INFO: [19] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=bc6ef1c39f3439ad conf_name=null,logging=false,conf_count=2,ch_count=6,v_streams=4
JVB 2020-03-19 12:06:57.684 WARNING: [16] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with 6ffb64f1137b25dd not ready yet.
JVB 2020-03-19 12:06:57.685 WARNING: [16] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message
JVB 2020-03-19 12:06:57.786 INFO: [19] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 134ms. Sticky failure: false
JVB 2020-03-19 12:07:05.795 WARNING: [667] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with d00be449 not ready yet.
JVB 2020-03-19 12:07:05.795 WARNING: [667] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message
JVB 2020-03-19 12:07:06.796 WARNING: [668] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with d00be449 not ready yet.
JVB 2020-03-19 12:07:06.796 WARNING: [668] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message

I tried everything: putting domain name and address into /etc/hosts as suggested on some forums, changing various variables in config files, no success.

No audio and video of the other party. I’m desperate.

I found this thread: New Setup - EndpointMessageTransport.log() SCTP

@saghul says the the error is “harmless”, so looked into my JS console.

When the other party connects I have these errors in the console:
Logger.js:154 2020-03-19T16:47:41.301Z [modules/RTC/BridgeChannel.js] <e.value>: Bridge Channel send: no opened channel.
2020-03-19T16:47:51.303Z [JitsiConference.js] <e.sendMessage>: Failed to send E2E ping request or response.

So, there is really something wrong with the Bridge Channel.

How to fix it?

Is anybody here to help?

Any firewall running? Stopped temporary to test.

I’m using iptables as firewall. I switched it off, no change.

I can see the port 10000 is open and used:
netstat -l | grep 10000:

udp6 0 0 subdomain.mydomain.cz:10000 [::]:*
udp6 0 0 192.168.2.1:10000 [::]:* - local network
udp6 0 0 fd34:4922:8a7:0:1:10000 [::]:*

netstat -vaun
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State

udp6 0 0 my_public_ip_address:10000 :::*
udp6 0 0 192.168.2.1:10000 :::* my internal IP address

I restarted all the services (prosody, jicofo, jitsi-videobridge) and suddenly it started working.

I will test it and hope it will work. Thanks for your advice so far.

I have the same problem. Ubuntu 18.04LTS installed the packages of jitsi (I mean not from source). Can not enter the room. Could it be that this same server has a Matrix/Riot service? The logs say

prosody.err

Mar 20 14:36:27 portmanager error Failed to open server port 5347 on 127.0.0.1, this port is in use by another application
Mar 20 14:36:27 portmanager error Failed to open server port 5347 on ::1, this port is in use by another application
Mar 20 14:36:27 portmanager error Failed to open server port 5269 on ::, check that Prosody or another XMPP server is not already running and using this port

prosody.log

Mar 20 17:50:04 general info Prosody is using the select backend for connection handling
Mar 20 17:50:04 socket warn server.lua, [127.0.0.1]:5347: address already in use
Mar 20 17:50:04 portmanager error Failed to open server port 5347 on 127.0.0.1, this port is in use by another application
Mar 20 17:50:04 socket warn server.lua, [::1]:5347: address already in use
Mar 20 17:50:04 portmanager error Failed to open server port 5347 on ::1, this port is in use by another application
Mar 20 17:50:04 portmanager info Activated service ‘component’ on no ports
Mar 20 17:50:04 socket warn server.lua, [::]:5269: address already in use
Mar 20 17:50:04 portmanager error Failed to open server port 5269 on ::, check that Prosody or another XMPP server is not already running and using this port

jvb.log

VB 2020-03-20 15:01:56.880 SEVERE: [36] org.jitsi.meet.ComponentMain.log() not-authorized, host:localhost, port:5347
org.xmpp.component.ComponentException: not-authorized

jicofo.log

Jicofo 2020-03-20 15:02:05.165 SEVERE: [58] org.jitsi.meet.ComponentMain.log() not-authorized, host:localhost, port:5347
org.xmpp.component.ComponentException: not-authorized

Any idea what might be wrong or how to debug? (unless there is conflict with Matrix).

Are those domain names substitutions when you published the logs, or the real names? It is important that the domain name you enter during installation actually be the real name that can be resolved by all components as well as by all users.

Right I forgot to clarify this. The above is copy-paste from the logs. The server has a real static IP (it is a University server). In DNS there are three names for its IP. Its real name, a matrix name and a “meet” name for the jitsi service. In the installation instructions I found for jitsi there is no point saying that I have to replace the 127.0.0.1 with its real IP.

Problem solved but for me it was unexpected: During my first installation I messed up the certificates. So I purged all jitsi related packages and began a clean install. But for some reason the removal of the packages did not stop the prosody binary. After the 2nd install there were two prosody binaries executing in memory, and thus it did not work. Unfortunately I could not reboot because this is a production server. Today I noticed the second binary and fixed the issue after kill and restart.