Video chat and conferencing options
-
Anyone got any experience of:
- mediasoup based conferencing app, such as multiparty-meeting (test here). It was reported on Jitsi forum that it uses VP9 and as a result as got a better quality and is more reliable on Firefox
- Medooze
And how they might compare to Jitsi / BBB / Kopano?
Thanks
-
-
Just wanted to share some update on this. We've published an updated Nextcloud app package which now pre-configures Nextcloud Talk (which is btw based on spreed)
The app update will be available only for Cloudrons already on 5.1
@nebulon I just tested this with the new updated Nextcloud talk in Cloudron 5.1 and it worked great (I started a call on my laptop on wifi and then joined as a non-logged in guest on my mobile over 4g)
Next to actually test with a real call with multiple users...
-
@nebulon I just tested this with the new updated Nextcloud talk in Cloudron 5.1 and it worked great (I started a call on my laptop on wifi and then joined as a non-logged in guest on my mobile over 4g)
Next to actually test with a real call with multiple users...
I've just tested Nextcloud Talk on Cloudron 5.1 with myself logged into Nextcloud plus 3 non-Cloudron user guests and it mostly* worked great!
*(one person couldn't see/ hear another, but the rest of us could all see/ hear everyone else
). -
@nebulon I just tried it and can't get the video of the other person.
chrome says
Uncaught (in promise) DOMException: Failed to execute 'addIceCandidate' on 'RTCPeerConnection': Error processing ICE candidatefirefox
InvalidStateError: Cannot add ICE candidate when there is no remote SDP@jdaviescoates did you just install a fresh nextcloud and it worked out of the box? I tried connecting from 2 laptops on the same lan and afterwards with browser and mobile (different net), neither are connecting properly. At some point it was working after a few minutes, and only once. Any ideas what's going on there?
-
@nebulon I just tried it and can't get the video of the other person.
chrome says
Uncaught (in promise) DOMException: Failed to execute 'addIceCandidate' on 'RTCPeerConnection': Error processing ICE candidatefirefox
InvalidStateError: Cannot add ICE candidate when there is no remote SDP@jdaviescoates did you just install a fresh nextcloud and it worked out of the box? I tried connecting from 2 laptops on the same lan and afterwards with browser and mobile (different net), neither are connecting properly. At some point it was working after a few minutes, and only once. Any ideas what's going on there?
@msbt are you on Cloudron 5.1?
-
of course now it worked on the second attempt. but restarted both, turn and nextcloud, and now the errors appear again and no immediate connection is possible:
nextcloud log is empty, turn shows the following errors:
Apr 06 15:28:52 105: IPv4. tcp or tls connected to: mobileip:18426 Apr 06 15:28:52 105: session 001000000000000040: realm <desktopip> user <>: incoming packet message processed, error 401: Unauthorizedand this from connection attempt:
https://paste.cloudron.io/oqiqocayez.rb -
Hi all,
after @girish and @nebulon did a extremely well job to add TURN in a short time, I'm curious who is using what for video conferencing via Cloudron (or third party)?
It seems the COVID-19 "lockdowns" or "other ways of living and working" seems to take many more months, so a solid, safe and easy videoconferencing app is very welcome.
Options/roadmaps:
- Kopano-Meet doesn't work (for us)
- Jitsi isn't here yet
- BBB isn't here yet
- Nextcloud Talk is IMHO not really one-click-easy (has anyone experience with 6+ meetings?)
- other current apps on Cloudron?
- other third-party video conference solutions?
I'm curious for your experiences and opinions.
Kind regards,
Marcel
-
- I added the webrtc plugin to my Etherpad and, possibly because the video window is rather small, it has been a very handy video chat option due to its clarity (and the audio was fine too), especially since the discussion involved what was written on the Etherpad. All within Cloudron.
-
@imc67 Let me explain the situation a bit from the technical side. Here's a very simplified explanation (I am not a video conf expert
)WebRTC provides a peer to peer (p2p) mechanism for 2 browser to connect. In most cases, these 2 browsers can't just directly connect since they are behind firewalls and in internal networks. The TURN protocol helps these two connect.
The above applies only for video calls with 2 people. What if many people join? One has to establish p2p connections between each peer! So, if you have like 5 people, there are p2p connections going from each browser to another. This mesh architecture can fail in many ways which are hard to pin point and debug: the browser has to support taking in 4 streams and mixing them properly in your laptop, think of the latencies being different for each stream, each browser has to be on a network that has enough bandwidth to accept 4 stream continuously etc. This is the current situation with kopano meet, nextcloud talk for multi-party conferences. IMO, this won't ever be reliable in general.
The solution for multi-party conferences is to create a video bridge. The video bridge is a central party to which all the browsers stream to. The video bridge will mix everything and give out a single stream to the browser. There are various approaches to implementing this - SFU, MCU, a mix of both etc. Currently, we don't have a videobridge on Cloudron (jitsi-videobridge is one such project that provides it) and until we have that multi-party conferences won't be reliable. Note that TURN is a per-requisite for SFU/MCU setups as well (it can help establish connection from browser to SFU/MCU).
One thing to remember is that this videobridge will either be network heavy or CPU heavy and this will cost $ based on where the VPS is hosted. There is no way around this for self-hosted setups.
-
@imc67 Let me explain the situation a bit from the technical side. Here's a very simplified explanation (I am not a video conf expert
)WebRTC provides a peer to peer (p2p) mechanism for 2 browser to connect. In most cases, these 2 browsers can't just directly connect since they are behind firewalls and in internal networks. The TURN protocol helps these two connect.
The above applies only for video calls with 2 people. What if many people join? One has to establish p2p connections between each peer! So, if you have like 5 people, there are p2p connections going from each browser to another. This mesh architecture can fail in many ways which are hard to pin point and debug: the browser has to support taking in 4 streams and mixing them properly in your laptop, think of the latencies being different for each stream, each browser has to be on a network that has enough bandwidth to accept 4 stream continuously etc. This is the current situation with kopano meet, nextcloud talk for multi-party conferences. IMO, this won't ever be reliable in general.
The solution for multi-party conferences is to create a video bridge. The video bridge is a central party to which all the browsers stream to. The video bridge will mix everything and give out a single stream to the browser. There are various approaches to implementing this - SFU, MCU, a mix of both etc. Currently, we don't have a videobridge on Cloudron (jitsi-videobridge is one such project that provides it) and until we have that multi-party conferences won't be reliable. Note that TURN is a per-requisite for SFU/MCU setups as well (it can help establish connection from browser to SFU/MCU).
One thing to remember is that this videobridge will either be network heavy or CPU heavy and this will cost $ based on where the VPS is hosted. There is no way around this for self-hosted setups.
@girish Great explanation.
-
@imc67 Let me explain the situation a bit from the technical side. Here's a very simplified explanation (I am not a video conf expert
)WebRTC provides a peer to peer (p2p) mechanism for 2 browser to connect. In most cases, these 2 browsers can't just directly connect since they are behind firewalls and in internal networks. The TURN protocol helps these two connect.
The above applies only for video calls with 2 people. What if many people join? One has to establish p2p connections between each peer! So, if you have like 5 people, there are p2p connections going from each browser to another. This mesh architecture can fail in many ways which are hard to pin point and debug: the browser has to support taking in 4 streams and mixing them properly in your laptop, think of the latencies being different for each stream, each browser has to be on a network that has enough bandwidth to accept 4 stream continuously etc. This is the current situation with kopano meet, nextcloud talk for multi-party conferences. IMO, this won't ever be reliable in general.
The solution for multi-party conferences is to create a video bridge. The video bridge is a central party to which all the browsers stream to. The video bridge will mix everything and give out a single stream to the browser. There are various approaches to implementing this - SFU, MCU, a mix of both etc. Currently, we don't have a videobridge on Cloudron (jitsi-videobridge is one such project that provides it) and until we have that multi-party conferences won't be reliable. Note that TURN is a per-requisite for SFU/MCU setups as well (it can help establish connection from browser to SFU/MCU).
One thing to remember is that this videobridge will either be network heavy or CPU heavy and this will cost $ based on where the VPS is hosted. There is no way around this for self-hosted setups.
@girish said in Video chat and conferencing options:
One thing to remember is that this videobridge will either be network heavy or CPU heavy and this will cost $ based on where the VPS is hosted.
This is partly why, like some others, I think we'll soon need some sort of multi-host support so that it's possible to have a single Cloudron running over multiple servers (eg with one run vps just for a jitsi or BigBlueButton video bridge)
-
@girish said in Video chat and conferencing options:
One thing to remember is that this videobridge will either be network heavy or CPU heavy and this will cost $ based on where the VPS is hosted.
This is partly why, like some others, I think we'll soon need some sort of multi-host support so that it's possible to have a single Cloudron running over multiple servers (eg with one run vps just for a jitsi or BigBlueButton video bridge)
@jdaviescoates said in Video chat and conferencing options:
This is partly why, like some others, I think we'll soon need some sort of multi-host support so that it's possible to have a single Cloudron running over multiple servers (eg with one run vps just for a jitsi or BigBlueButton video bridge)
I haven't looked into BBB but Jitsi's videbridge has the capability to be run standalone and can even connect to completely separate jitsi installations. This way, it is just like a CI system "worker" node (or the only office or collabora app for nextcloud). So, we could also look at making jitsi available without the video bridge as cloudron app and then connecting an external video bridge into it.
(I guess I am just trying to find a possible solution for not having to solve the cloudron multi-host problem which is quite a big project).
-
@imc67 Let me explain the situation a bit from the technical side. Here's a very simplified explanation (I am not a video conf expert
)WebRTC provides a peer to peer (p2p) mechanism for 2 browser to connect. In most cases, these 2 browsers can't just directly connect since they are behind firewalls and in internal networks. The TURN protocol helps these two connect.
The above applies only for video calls with 2 people. What if many people join? One has to establish p2p connections between each peer! So, if you have like 5 people, there are p2p connections going from each browser to another. This mesh architecture can fail in many ways which are hard to pin point and debug: the browser has to support taking in 4 streams and mixing them properly in your laptop, think of the latencies being different for each stream, each browser has to be on a network that has enough bandwidth to accept 4 stream continuously etc. This is the current situation with kopano meet, nextcloud talk for multi-party conferences. IMO, this won't ever be reliable in general.
The solution for multi-party conferences is to create a video bridge. The video bridge is a central party to which all the browsers stream to. The video bridge will mix everything and give out a single stream to the browser. There are various approaches to implementing this - SFU, MCU, a mix of both etc. Currently, we don't have a videobridge on Cloudron (jitsi-videobridge is one such project that provides it) and until we have that multi-party conferences won't be reliable. Note that TURN is a per-requisite for SFU/MCU setups as well (it can help establish connection from browser to SFU/MCU).
One thing to remember is that this videobridge will either be network heavy or CPU heavy and this will cost $ based on where the VPS is hosted. There is no way around this for self-hosted setups.
@girish Do take a look at "Run your own Skype-like service in less than one hour" by the founder of the Kamailo SIP server open source project where Kamailo works together with Jitsi to enable many to collaborate meaningfully - via audio/video/ screen-sharing in one room - on not "too-big" a server.
Off course, it could be a "premium" Cloudron offering!
