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

[scooke]

@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.

[yusf]

How resource-intensive was the session? Was the beefy spec justified?

[imc67]

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.

[yusf]

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.

[stantropics]

@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.

[imc67]

@yusf of some I know their devices/browsers:

1. account: MacOS+Safari = all fine (could see/hear 2.)
2. guest: MacOS+Safari = all fine (could see/hear account, BTW on same network as account)
3. guest: MacOS+Safari and iPad+Safari = connected, could see himself, but no audio/video to/from others
4. guest: iPad+Safari = connected, could see himself, but no audio/video to/from others
5. guest: Samsung tablet with Chrome = connected, could see himself, but no audio/video to/from others
6. 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).

[necrevistonnezr]

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.

[fbartels]

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.

[luckow]

Charming participants at the first (virtual) Cloudron meetup

[oj]

@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."

https://github.com/Kopano-dev/kwmbridge

[fbartels]

@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.