Videoconference keep saying "unfortunately something went wrong"


#9

Conference Failed: conference.focusDisconnected. Now check your jicofo log file, why jicofo is not connected or disconnected.


#10

I`m online, let me check quickly


#11

Hi Damian

What I read from the log below is that the connection is refused. It calls on Jetty, but I`m using Nginx.

Jicofo 2019-01-11 00:15:09.917 INFO: [11] impl.netaddr.NetworkAddressManagerServiceImpl.start().92 Network Address Manager …[ STARTED ]
Jicofo 2019-01-11 00:15:09.917 INFO: [11] impl.netaddr.NetworkAddressManagerServiceImpl.start().98 Network Address Manager Service …[REGISTERED]
Jicofo 2019-01-11 00:15:09.921 INFO: [11] org.jitsi.version.AbstractVersionActivator.start().119 JiCoFo Version: JiCoFo 1.0.1.0-440
Jicofo 2019-01-11 00:15:10.088 INFO: [11] org.jitsi.jicofo.JitsiMeetGlobalConfig.init().170 Automatically grant ‘owner’ role: true
Jicofo 2019-01-11 00:15:10.088 INFO: [11] org.jitsi.jicofo.JitsiMeetGlobalConfig.init().183 Jibri requests in PENDING state will be timed out after: 90 seconds
Jicofo 2019-01-11 00:15:10.088 INFO: [11] org.jitsi.jicofo.JitsiMeetGlobalConfig.init().197 Lonely participants will be “terminated” after 20000 milliseconds
Jicofo 2019-01-11 00:15:10.109 INFO: [11] org.jitsi.jicofo.BridgeSelector.createBridgeSelectionStrategy().176 Using SingleBridgeSelectionStrategy
Jicofo 2019-01-11 00:15:10.110 INFO: [11] org.jitsi.jicofo.BridgeSelector.().146 Using org.jitsi.jicofo.BridgeSelector$SingleBridgeSelectionStrategy
Jicofo 2019-01-11 00:15:10.110 INFO: [11] org.jitsi.jicofo.BridgeSelector.init().610 Bridge failure reset threshold: 300000
Jicofo 2019-01-11 00:15:10.173 INFO: [11] org.eclipse.jetty.server.Server.doStart() jetty-8.1.16.v20140903
Jicofo 2019-01-11 00:15:10.205 SEVERE: [26] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.doConnect().319 Failed to connect/login: The following addresses failed: ‘localhost:5222’ failed because: localhost/127.0.0.1 exception: java.net.ConnectException: Connection refused (Connection refused), localhost/0:0:0:0:0:0:0:1 exception: java.net.ConnectException: Connection refused (Connection refused)
org.jivesoftware.smack.SmackException$ConnectionException: The following addresses failed: ‘localhost:5222’ failed because: localhost/127.0.0.1 exception: java.net.ConnectException: Connection refused (Connection refused), localhost/0:0:0:0:0:0:0:1 exception: java.net.ConnectException: Connection refused (Connection refused)
at org.jivesoftware.smack.SmackException$ConnectionException.from(SmackException.java:278)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectUsingConfiguration(XMPPTCPConnection.java:619)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection.java:902)
at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.java:380)
at org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.doConnect(XmppProtocolProvider.java:275)
at org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.access$000(XmppProtocolProvider.java:62)
at org.jitsi.impl.protocol.xmpp.XmppProtocolProvider$1.call(XmppProtocolProvider.java:256)
at org.jitsi.impl.protocol.xmpp.XmppProtocolProvider$1.call(XmppProtocolProvider.java:251)
at org.jitsi.retry.RetryStrategy$TaskRunner.run(RetryStrategy.java:193)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
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)
Jicofo 2019-01-11 00:15:10.212 INFO: [11] org.eclipse.jetty.server.AbstractConnector.doStart() Started SelectChannelConnector@0.0.0.0:8888
Jicofo 2019-01-11 00:15:10.216 INFO: [1] java.util.prefs.run() Created user preferences directory.
Jicofo 2019-01-11 00:15:10.217 INFO: [1] org.jitsi.xmpp.component.ComponentBase.loadConfig().202 Component org.jitsi.jicofo. config:
Jicofo 2019-01-11 00:15:10.217 INFO: [1] org.jitsi.xmpp.component.ComponentBase.loadConfig().203 ping interval: 10000 ms
Jicofo 2019-01-11 00:15:10.217 INFO: [1] org.jitsi.xmpp.component.ComponentBase.loadConfig().204 ping timeout: 5000 ms
Jicofo 2019-01-11 00:15:10.218 INFO: [1] org.jitsi.xmpp.component.ComponentBase.loadConfig().205 ping threshold: 3
Jicofo 2019-01-11 00:15:10.221 SEVERE: [31] org.jitsi.meet.ComponentMain.call().323 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5347


#12

Damian

Here are the last lines of the jicofo log file.

It repeats all the time, but comes down to this:

Jicofo 2019-01-11 12:59:45.210 SEVERE: [13] org.jitsi.impl.osgi.framework.launch.FrameworkImpl.startLevelChanged() Error changing start level
org.osgi.framework.BundleException: BundleActivator.start
at org.jitsi.impl.osgi.framework.BundleImpl.start(BundleImpl.java:327)
at org.jitsi.impl.osgi.framework.launch.FrameworkImpl.startLevelChanged(FrameworkImpl.java:472)
at org.jitsi.impl.osgi.framework.startlevel.FrameworkStartLevelImpl$Command.run(FrameworkStartLevelImpl.java:137)
at org.jitsi.impl.osgi.framework.AsyncExecutor.runInThread(AsyncExecutor.java:122)
at org.jitsi.impl.osgi.framework.AsyncExecutor.access$000(AsyncExecutor.java:28)
at org.jitsi.impl.osgi.framework.AsyncExecutor$1.run(AsyncExecutor.java:231)
Caused by: java.lang.ClassNotFoundException: org.jitsi.jicofo.JvbDoctor
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
at org.jitsi.impl.osgi.framework.BundleImpl.loadClass(BundleImpl.java:237)
at org.jitsi.impl.osgi.framework.BundleImpl.start(BundleImpl.java:305)
… 5 more
Jicofo 2019-01-11 12:59:45.210 SEVERE: [13] org.jitsi.impl.osgi.framework.BundleImpl.start() Error starting bundle: null
java.lang.ClassNotFoundException: org.jitsi.jicofo.VersionBroadcaster
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
at org.jitsi.impl.osgi.framework.BundleImpl.loadClass(BundleImpl.java:237)
at org.jitsi.impl.osgi.framework.BundleImpl.start(BundleImpl.java:305)
at org.jitsi.impl.osgi.framework.launch.FrameworkImpl.startLevelChanged(FrameworkImpl.java:472)
at org.jitsi.impl.osgi.framework.startlevel.FrameworkStartLevelImpl$Command.run(FrameworkStartLevelImpl.java:137)
at org.jitsi.impl.osgi.framework.AsyncExecutor.runInThread(AsyncExecutor.java:122)
at org.jitsi.impl.osgi.framework.AsyncExecutor.access$000(AsyncExecutor.java:28)
at org.jitsi.impl.osgi.framework.AsyncExecutor$1.run(AsyncExecutor.java:231)
Jicofo 2019-01-11 12:59:45.210 SEVERE: [13] org.jitsi.impl.osgi.framework.launch.FrameworkImpl.startLevelChanged() Error changing start level
org.osgi.framework.BundleException: BundleActivator.start
at org.jitsi.impl.osgi.framework.BundleImpl.start(BundleImpl.java:327)
at org.jitsi.impl.osgi.framework.launch.FrameworkImpl.startLevelChanged(FrameworkImpl.java:472)
at org.jitsi.impl.osgi.framework.startlevel.FrameworkStartLevelImpl$Command.run(FrameworkStartLevelImpl.java:137)
at org.jitsi.impl.osgi.framework.AsyncExecutor.runInThread(AsyncExecutor.java:122)
at org.jitsi.impl.osgi.framework.AsyncExecutor.access$000(AsyncExecutor.java:28)
at org.jitsi.impl.osgi.framework.AsyncExecutor$1.run(AsyncExecutor.java:231)
Caused by: java.lang.ClassNotFoundException: org.jitsi.jicofo.VersionBroadcaster
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
at org.jitsi.impl.osgi.framework.BundleImpl.loadClass(BundleImpl.java:237)
at org.jitsi.impl.osgi.framework.BundleImpl.start(BundleImpl.java:305)
… 5 more


#13

What is the java version that you use?


#14

Hi Damian

java -version

openjdk version “10.0.2” 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed mode)


#15

Can you install java8 and make it default and restart services and try again?


#16

Hi Damian

Java 8 is/was installed. Headless…

It is along with one of the mudoles, I have a hunch it came along with Jibri, that a newer version of java installed.

How do I make Java 8 the default?


#17

Hi Damian,

We`re really good progress. I google these two scripts and rebooted the machine.

sudo update-java-alternatives --list

sudo update-java-alternatives --set java-1.8.0-openjdk-amd64

Video conference is now working, but only the standard features, like chat, is working.

Screenshare, Live Stream and Record does not work.


#18

leaqueb@gmail.com


#19

Hi @Leaque,

For live streaming, can you post the jibri logs when error occurs? Screen sharing only works on Firefox out-of-th-box. For Chrome you need the Jidesha extension.

Abhijit


#20

Hi Abhijit

Screen sharing was working. Jidesha is installed.

I`ll post the log in a seperate reply. Need to do that from the server.

I have a bit of java experience, so I understand:

Recording {

}

For example: It is evident the Java 1.11 cause jitsi to give problems. The minute I set default 1.8, that was installed all the time, at least I could get the basic conference to work.

I`m starting to wonder, because this is now my 5th attempt at installing Jitsi with all the features, but I keep running into issues with Jibri. Should I not rather install Ubuntu 16.04? Currently running 18.04 TLS.


#21

Guys I`ve now installed Ubuntu 16.04 Xenial on a new VM. It means a brand new installation. My previous 5 or 6 installation attempts were all on Ubuntu 18.04 LTS.

The same situation is repeating. I can successfully install Jitsi Meet, screen sharing works, etc.

The minute I install Jibri, my server breaks.

domain: meet.bassphone.co.za

I`m running nginx as web server

Java verson 8 JRE headless

Two things that might have an impact that I need your advice on:

I have not set compulsary user sign-on to use conference. Anybody can use the conference. Is this the reason why Jibri fails?

Jibri is installed on the same VM. I see you recommend it run on a seperate VM. It this compulsary?

Will the above make or break the server.


#22

So first how does your server breaks? What is the js console error in the browser? Then depending on what is the error you will need to check prosody, jicofo or jvb logs.


#23

Hi Damian

It seems that everywhere prosody is involved I end up with a broken conference server.

This time i tried to setup user acess to the conference, instead of being open.

Seems that I know too little about prosody.

I`ve cleanly installed Jitsi Meet for about 8 times now. Let me leave the current entry level version working on meet.bassphone.co.za

I will then install another server instance on a test server environment and allow that to break, if need be.

Let us close this ticket for now.

I will open another with very particular detail as I build the test server.

Regards,

Leaque


#24

Hi Damian,i have done so.

A minimal version of jitsi is running on meet.bassphone.co.za. I willinstall features onto this one,once Imcomfortable its working.

I have installed a test server on 197.242.159.135
I have tried to configure user authentication on here and I`m at the point where the conference keeps disconnecting and attempting to rejoin continuously.

Here is the Google Developer tool log on the right.
What is your advice on this?


#25

If you open https://197.242.159.135/http-bind, what do you see?
Probably the 404 page where it is written host-unknown, this means that prosody does not have a configured virtual host named ‘197.242.159.135’.
Post your prosody config.


#26

Hi Damian

Yes I get that 404 page. Screendump attached.

Posting the prosody config in a seperate e-mail.


#27

– Plugins path gets uncommented during jitsi-meet-tokens package install - that’s where token plugin is located
–plugin_paths = { “/usr/share/jitsi-meet/prosody-plugins/” }

VirtualHost “197.242.159.135”

    authentication = "internal_plain"
    -- 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.

VirtualHost “guest.197.242.159.135”

authentication = "anonymous"
    c2s_require_encryption = false

    ssl = {
            key = "/etc/prosody/certs/197.242.159.135.key";
            certificate = "/etc/prosody/certs/197.242.159.135.crt";
    }
    -- we need bosh
    modules_enabled = {
        "bosh";
        "pubsub";
        "ping"; -- Enable mod_ping
    }

    c2s_require_encryption = false

Component “conference.197.242.159.135” “muc”
storage = “null”
–modules_enabled = { “token_verification” }
admins = { “focus@auth.197.242.159.135” }

Component “jitsi-videobridge.197.242.159.135”
component_secret = “ksqKnJ9d”

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

Component “focus.197.242.159.135”
component_secret = “BpNuxE8h”


#28

Your config is wrong, your main virtualhost 197… is missing the default settings of the certificates and the modules enabled … which include and bosh…