Solved Meet Kopano (unstable version) - a few questions & problems :)
-
Hi @jdaviescoates,
that all in all sounds strange. Especially freezing when trying to screenshare is nothing I have seen here so far.
-
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.
-
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!
-
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?
-
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.
-
@fbartels Sorry, yes, my bad. In 5.1.4 I broke apps that serve up
.well-knowndocs of their own
On a side note, we use Kopano meet for our weeklies and we haven't had any issues.
-
Thanks for the update @girish! The 5.1.5 update of cloudron fixes the error and Kopano Meet is working now.
-
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-meetupPlease: use chromium/chrome & Headset
Specs: netcup vm, 6 CPU, 32 RAM, HDD
Pronouns: he/him | Primary language: German
-
@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.
-
@luckow I'll join in, thanks.
-
@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 ...
-
@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..
-
@luckow I will join if my home internet starts working again.
-
@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/
-
@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
Here is a nice explanation of the pros and cons of the three main typologies used for video conference: p2p / MCU / SFU
-
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.
-
Sorry for not participating, had some connectivity issues here. How did the call go?
-
you didn't miss it, it's this evening
-
@msbt Ah, I had the already-converted time in my head, "9", and then misremembered it as 'am'. Phew.
-
That went pretty well! Thanks for joining and @luckow for organizing.
-
-
@jdaviescoates Seven. One left their video off. We had three reconnections but those were momentary and the reconnection initially resulted in clearer video images each time.
-
How resource-intensive was the session? Was the beefy spec justified?
-
Hi all, today I introduced Kopane Meet for the first time in our (volunteers) organization for a video meeting with 1 account and 5 guests.
It was a disaster! After half an hour trying and frustration we stopped and 4 of them started a WhatsApp groupvideo (Whatsapp has a max of 4?!).
What went right?
The first 2 persons (account and 1 guest) succeeded in having audio and video.What went wrong?
All other guests could join (we could see their names) but they didn't see any video or heared audio and the first two didn't see/hear them. They could see themselves in their browser.Time to uninstall the app and hopefully Jitsi Meet will be here soon.
-
Sounds like my experience with Kopano. Maybe you can describe device types, browsers and network topology used? I suspect some of the problems derives from part network restrictions but also weak devices and faulty browsers.
-
@imc67 It also sounds exactly like my experience with Kopano meet. I'm trying to analyze whether the problem is somewhere on my side - however, it appears to be a real challenge.
-
@yusf of some I know their devices/browsers:
- account: MacOS+Safari = all fine (could see/hear 2.)
- guest: MacOS+Safari = all fine (could see/hear account, BTW on same network as account)
- guest: MacOS+Safari and iPad+Safari = connected, could see himself, but no audio/video to/from others
- guest: iPad+Safari = connected, could see himself, but no audio/video to/from others
- guest: Samsung tablet with Chrome = connected, could see himself, but no audio/video to/from others
- guest: ? = connected, could see himself, but no audio/video to/from others
The WhatsApp groupvideo after half an hour strugling with four (2./3./4./5.) went perfect, so it's not a matter of bandwith I guess.
Cloudron server load or bandwith usage during the "call" was normal, so no increase in CPU resources or network (I use ZABBIX agent on the Cloudron server so can see all stats live and all history is stored).
-
off-topic: I think one lesson to learn here is that to do video conferencing properly is quite hard. You can hate on Zoom and Teams all you want but if you actually have your work depend on it (e.g. meeting with a client, like I do on a daily basis), it's quite a different story than just having fun with friends.
-
Hi @imc67,
browser versions are equally as important as the browser itself. and sadly Safari isn't the best when it comes to supporting modern standard such as PWAs and WebRTC. The general recommendation would be to use Chrome or Chromium based browsers.
@imc67 said in Meet Kopano (unstable version) - a few questions & problems
:Cloudron server load or bandwith usage during the "call" was normal
Yes, that is to be expected when using WebRTC, the majority of traffic is between individual callers. There are still some connections to the server, like for example a websocket connection to kwmserver for notifications and then of course the connection to the turn server.
-
Charming participants at the first (virtual) Cloudron meetup
-
@luckow We should do this again when @fbartels packages "Kopano Meet Boost" on Cloudron!
"Kopano Meet Boost is a server that we offer to our enterprise customers to meet this challenge. It is a Selective Forwarding Unit (SFU) that receives only one data stream from the sender and forwards it to all other participants. This drastically reduces the required computing power at the client and saves bandwidth. Thus, video meetings are also possible with 50 and more participants."
-
@oj said in Meet Kopano (unstable version) - a few questions & problems
:packages "Kopano Meet Boost" on Cloudron
thats unfortunately a bit impractical to do. kwmbridge requires a large range of udp ports so running it in a container with forwarded ports is quite inefficient (because there is also quite a memory overhead in Docker in this case).
But it should be easy to make the app configurable enough to have kwmbridge running on a dedicated host and simply hook up to kwmserver inside of the app. having (multiple) external kwmbridge endpoints is kind of the setup we are expecting anyways.
