Meet Kopano (unstable version) - a few questions & problems :)

[yusf]

@fbartels Latest stable, 13.3.1.

[fbartels]

@yusf the latest is actually 13.4.1

[jdaviescoates]

@fbartels said in Meet Kopano (unstable version) - a few questions & problems :

What is the exact behaviour you experience?

I've done a few tests.

First of all I tried having a call with myself using my laptop on wifi (Lenovo T510 running Ubuntu 18.04 and Firefox 75.0) and my phone on 4g (Wileyfox Swift 2 Plus running Android 8.1.0 and Firefox 68.7.0) but it didn't work at all. No video nor audio.

Not only that but after a while on my laptop Firefox seemed to suddenly be unable to connect to my camera and mic and then would fail to reconnect (this doesn't happen when testing Nextcloud Talk). And then when I clicked the screenshare button (just to see what it was) my whole laptop froze and I had to power off.

Although saying all that, I just replicated the same test and this time it appeared to work quite well. I even got my wife to join in on her phone too and it kinda sorta worked (she lost connection at one point and mostly her video was frozen).

Another time I did a test with my laptop, my phone, and my Mum on her laptop (in a different city). I can't remember exactly what happened, but I think I could see and her my Mum on my phone, but not on my laptop. But she could see me on my laptop but not on my phone, or something like that.

So all in all, in the all tests I've done to date, mostly not really working (although the test I just did now went OK until there were 3 of us on the call)

I've had much better experience using Nextcloud Talk so far, although I have to say I much prefer that way Kopano Meet gets guests to set their name and get their camera and mic working before joining the call. On Nextcloud Talk it's common to have multiple people join and for them to all be called Guest, which can get a bit confusing. I think I'll add an issue to Nextcloud Talk suggesting they make Guests add their name before joining too...

[fbartels]

Hi @jdaviescoates,

that all in all sounds strange. Especially freezing when trying to screenshare is nothing I have seen here so far.

[nebulon]

I remember @fbartels mentioning some browser session debugging tool to collect relevant information in such a case, maybe that can help sort our some of those cases. Overall we had generally a good experience so far with the app, but given all the various browsers and their various states of webrtc it seems to be a hard issue to tackle.

[oj]

Hi @fbartels,

Just had my first few one-on-one video calls with registered users and guests... Iridium browser at my end and Chrome at the other end. Worked flawlessly...even with 4G at my end. Excellent user experience at both ends. Thanks for bringing Kopano Meet to Cloudron!

[NCKNE]

Hello @fbartels,

I just installed Kopano Meet to give it a try and encountered the following error after installation on cloudron v5.1.4 with Kopano Meet version 2.1.0 (Package v1.2.1):

Apr 15 17:16:33 2020/04/15 15:16:33 Waiting for https://meet.xxx.xx/.well-known/openid-configuration: unexpected HTTP status code: 404.
Apr 15 17:16:33 2020/04/15 15:16:33 Failed to wait: timed out: https://meet.xxx.xx/.well-known/openid-configuration.
Apr 15 17:16:33 time="2020-04-15T15:16:33Z" level=info msg="serve start"
Apr 15 17:16:33 time="2020-04-15T15:16:33Z" level=info msg="using external TURN service: https://turnauth.kopano.com/turnserverauth/"
Apr 15 17:16:33 time="2020-04-15T15:16:33Z" level=info msg="serve started"
Apr 15 17:16:43 time="2020-04-15T15:16:43Z" level=warning msg="failed to initialize OIDC provider" error="Timeout (:0x105)" iss="https://meet.xxx.xx"
Apr 15 17:16:43 time="2020-04-15T15:16:43Z" level=warning msg="admin: using random admin tokens singing key - API endpoint admin disabled"
Apr 15 17:16:43 time="2020-04-15T15:16:43Z" level=info msg="pattern ^group/public/.* public guest rooms enabled" manager=guest
Apr 15 17:16:43 time="2020-04-15T15:16:43Z" level=info msg="guest: API endpoint enabled"
Apr 15 17:16:43 time="2020-04-15T15:16:43Z" level=info msg="rtm: API endpoint enabled"
Apr 15 17:16:43 time="2020-04-15T15:16:43Z" level=info msg="starting http listener" listenAddr="127.0.0.1:8778"
Apr 15 17:16:43 time="2020-04-15T15:16:43Z" level=info msg="ready to handle requests"

The app starts, but no login is possible (the login button on the Kopano Meet page does not do anything upon clicking).

On the client side, the following error comes up:

oidc-client.min.js:718 GET https://meet.xxx.xx/.well-known/openid-configuration 404
(anonymous) @ oidc-client.min.js:718
(anonymous) @ oidc-client.min.js:693
(anonymous) @ oidc-client.min.js:289
value @ usermanager.js:317
(anonymous) @ actions.js:667
w @ runtime.js:62
(anonymous) @ runtime.js:288
(anonymous) @ runtime.js:114
w @ runtime.js:62
e @ runtime.js:152
(anonymous) @ runtime.js:187
o @ runtime.js:186
(anonymous) @ runtime.js:209
(anonymous) @ runtime.js:114
(anonymous) @ runtime.js:233
(anonymous) @ actions.js:658
Promise.then (async)
(anonymous) @ actions.js:656
(anonymous) @ index.js:8
dispatch @ applyMiddleware.js:46
(anonymous) @ actions.js:318
w @ runtime.js:62
(anonymous) @ runtime.js:288
(anonymous) @ runtime.js:114
w @ runtime.js:62
e @ runtime.js:152
(anonymous) @ runtime.js:187
o @ runtime.js:186
(anonymous) @ runtime.js:209
(anonymous) @ runtime.js:114
(anonymous) @ runtime.js:233
(anonymous) @ actions.js:309
(anonymous) @ index.js:8
dispatch @ applyMiddleware.js:46
(anonymous) @ actions.js:356
w @ runtime.js:62
(anonymous) @ runtime.js:288
(anonymous) @ runtime.js:114
w @ runtime.js:62
e @ runtime.js:152
(anonymous) @ runtime.js:162
Promise.then (async)
e @ runtime.js:161
(anonymous) @ runtime.js:187
o @ runtime.js:186
(anonymous) @ runtime.js:209
(anonymous) @ runtime.js:114
(anonymous) @ runtime.js:233
(anonymous) @ actions.js:316
(anonymous) @ index.js:8
dispatch @ applyMiddleware.js:46
n @ actions.js:216
(anonymous) @ actions.js:232
w @ runtime.js:62
(anonymous) @ runtime.js:288
(anonymous) @ runtime.js:114
w @ runtime.js:62
e @ runtime.js:152
(anonymous) @ runtime.js:187
o @ runtime.js:186
(anonymous) @ runtime.js:209
(anonymous) @ runtime.js:114
(anonymous) @ runtime.js:233
(anonymous) @ actions.js:224
(anonymous) @ AuthenticatedRoute.js:22
Promise.then (async)
render @ AuthenticatedRoute.js:20
(anonymous) @ react-router.js:444
Li @ react-dom.production.min.js:4074
qa @ react-dom.production.min.js:5514
Ka @ react-dom.production.min.js:5536
Ds @ react-dom.production.min.js:5958
Ms @ react-dom.production.min.js:5925
Es @ react-dom.production.min.js:5860
es @ react-dom.production.min.js:5787
enqueueSetState @ react-dom.production.min.js:2790
(anonymous) @ react.production.min.js:72
(anonymous) @ Main.js:56
u @ runtime.js:45
(anonymous) @ runtime.js:264
(anonymous) @ runtime.js:98
r @ asyncToGenerator.js:3
s @ asyncToGenerator.js:25
Promise.then (async)
r @ asyncToGenerator.js:13
s @ asyncToGenerator.js:25
(anonymous) @ asyncToGenerator.js:32
(anonymous) @ asyncToGenerator.js:21
Promise.then (async)
value @ Main.js:53
Ba @ react-dom.production.min.js:4980
Ga @ react-dom.production.min.js:5123
(anonymous) @ react-dom.production.min.js:5975
(anonymous) @ scheduler.production.min.js:274
Ls @ react-dom.production.min.js:5974
Ds @ react-dom.production.min.js:5958
Ms @ react-dom.production.min.js:5925
Es @ react-dom.production.min.js:5860
es @ react-dom.production.min.js:5787
enqueueSetState @ react-dom.production.min.js:2790
(anonymous) @ react.production.min.js:72
t @ index.js:240
(anonymous) @ index.js:250
Promise.then (async)
(anonymous) @ index.js:249
(anonymous) @ index.js:197
lo @ react-dom.production.min.js:2854
Ri @ react-dom.production.min.js:3759
Li @ react-dom.production.min.js:3960
qa @ react-dom.production.min.js:5514
Ka @ react-dom.production.min.js:5536
Ds @ react-dom.production.min.js:5958
Ms @ react-dom.production.min.js:5925
Es @ react-dom.production.min.js:5860
es @ react-dom.production.min.js:5787
enqueueSetState @ react-dom.production.min.js:2790
(anonymous) @ react.production.min.js:72
(anonymous) @ IntlContainer.js:281
Promise.then (async)
value @ IntlContainer.js:280
Ba @ react-dom.production.min.js:4978
Ga @ react-dom.production.min.js:5123
(anonymous) @ react-dom.production.min.js:5975
(anonymous) @ scheduler.production.min.js:274
Ls @ react-dom.production.min.js:5974
Ds @ react-dom.production.min.js:5958
Ms @ react-dom.production.min.js:5925
Es @ react-dom.production.min.js:5860
es @ react-dom.production.min.js:5787
Us @ react-dom.production.min.js:6077
Ys @ react-dom.production.min.js:6085
(anonymous) @ react-dom.production.min.js:6276
(anonymous) @ react-dom.production.min.js:6360
Is @ react-dom.production.min.js:6007
Vs @ react-dom.production.min.js:6359
render @ react-dom.production.min.js:6390
831 @ app.js:51
i @ bootstrap:89
Promise.then (async)
(anonymous) @ index.js:18
Promise.then (async)
184 @ index.js:14
i @ bootstrap:89
107 @ main.758e3f7e.chunk.js?__WB_REVISION__=ebc8e0d9096114f5d646:1
i @ bootstrap:89
r @ bootstrap:45
t @ bootstrap:32
(anonymous) @ main.758e3f7e.chunk.js?__WB_REVISION__=ebc8e0d9096114f5d646:1
actions.js:251 failed to continue config initialization Error:  (404)
    at XMLHttpRequest.<anonymous> (oidc-client.min.js:715)

Any idea what could be the problem?

[fbartels]

Hi @NCKNE,

thanks for your feedback. The immediate cause for your error is the 404 when getting the discovery document from the .well-known directory. Can you check if Konnect is running (the program that provides the document)? You can do so when opening a terminal inside of the app and then running supervisorctl status kopano-konnectd.

What I find especially weird is that you got a 404 (file not found), in case Konnect isn't running this should normally be a 503 (service unavailable). Which version of Cloudron are you on? Where is that machine running (behind dynamic dns)? How do you manage dns (could it be that meet.xxx.xx still points somewhere else)?

Edit: ah, this seems to be some general breakage with the latest version of Cloudron. https://forum.cloudron.io/post/7396 reports something similar and @girish said a new version is already rolling out.

[girish]

@fbartels Sorry, yes, my bad. In 5.1.4 I broke apps that serve up .well-known docs of their own

On a side note, we use Kopano meet for our weeklies and we haven't had any issues.

[NCKNE]

Thanks for the update @girish! The 5.1.5 update of cloudron fixes the error and Kopano Meet is working now.

[luckow]

Let us find out how many participants are possible with a Kopano Meet app on Cloudron (v5.15).

Invitation
When: Monday 20. April 21:00 (Europe/Berlin)
Where: https://meet.luckow.org/meet/r/join/group/public/cloudron-meetup

Please: use chromium/chrome & Headset

Specs: netcup vm, 6 CPU, 32 RAM, HDD

[fbartels]

@luckow thats a nice idea. I have created a reminder for myself.

We once had a call with around 30 participants, but that was not really stable and just a quick test.

We are currently working on a sfu for some customers, if there is interest we could do a comparing test afterwards with that kind of a setup.

[scooke]

@luckow I'll join in, thanks.

[stantropics]

@jdaviescoates Have you investigated further? I have also tried to a few meetings with 3 to 5 people with several problems. Sometimes people cannot connect at all, sometimes they are not getting any sound or their sound is not transmitted to other participants. Very hard to analyze ...

[jdaviescoates]

@stantropics no not had a chance (nor really sure how to), although I think I read somewhere that with full p2p WebRTC apps like Kopano Meet all users need to have enough bandwidth for all streams or something, is that right @fbartels?

Either way it seems most people have so far had a better experience than us... So I'm keen to try more. Will attempt to join the group call..

[girish]

@luckow I will join if my home internet starts working again.

[fbartels]

@jdaviescoates said in Meet Kopano (unstable version) - a few questions & problems :

all users need to have enough bandwidth for all streams or something

Yes, with a peer to peer connection all users need to connect to each other participant. Connections in Meet are limited to max 1 Mbit per participant, if a user does not have sufficient bandwidth for that the browser will automatically reduce quality down to a level where video would be deactivated completely.

Some more usage questions are answered in https://kopano.com/blog/top-10-things-to-ask-about-kopano-meet/

[avatar1024]

@jdaviescoates said in Meet Kopano (unstable version) - a few questions & problems :

with full p2p WebRTC apps like Kopano Meet all users need to have enough bandwidth for all streams or something

is a nice explanation of the pros and cons of the three main typologies used for video conference: p2p / MCU / SFU

[avatar1024]

Also might be of interest:

An article which test a methodology to compare SFUs, and then test a few of them. Results probably do not reflect real case scenario though.

[scooke]

Sorry for not participating, had some connectivity issues here. How did the call go?