Since Nextcloud Talk was not even usable with 3 participants in my case, I decided to try and implement a backend based on NodeJS which should be compatible to Nextcloud Talk. As the SFU I currently focus on Janus (since I believe Nextcloud is using it too) but it should be possible to write connectors to others as well.
I seem to be on a good track and the first prototype mostly works, but it is still work in progress as it is difficult to guess the right responses from the backend. You can find the source and track the progress here:
This is great! Many institutions really need an alternative to the costly High Performance Backend! Would it be possible for you to put out a bounty or parcel the work that still needs to be done in such a way that people can jump aboard to speed it up? I don’t want to be misunderstood: I applaud an appreciate the volunteer spirit behind many key components of open source, incl Nextcloud - but that does not mean that people should not get paid. Getting a reliable open source alternative to the HPB is something that many would be ready to support financially, especially if bounties speed up development and help to establish clear timelines and capabilities…
Also - this thread should be called New Nextcloud Talk Backend to aid discoverability…
It is still in very early stages of development, the code has to be refactored probably a lot more in the future. I just wanted to publish it so that maybe someone else can also have a look at it and point out things. I thought it is better to do it now, than never…
I guess in terms of the signaling server it’s really not magic regarding the technology, just a websocket connection sending some messages around. The harder part would be the handling of the streams…
@powerpaul It’s great that the founder of nextcloud (and owncloud) @frank Karlitschek is offering help! Here is hoping you ll take him up on the offer. Given the current situation, it would be great to see Nextcloud suport both this effort as well as Big Blue Button Integration (important, because more usefull than “just” Nextcloud talk for schools and universities because of online classroom features). See details about BBB Nxtclud talk, where this Talk Backend Alternative is alos referenced here
you can say but to get past the "noob"status and also quoting from what you quoted yourself:
Asking as people are turning to video conferencing due to Covid 19 shuttering homes, etc. How easy is it for a home admin to setup a 10+ person video conference? I do not see people discussing Talk… just Jitsi, Zoom, Skype, Mumble, Hangouts… thoughts and setup suggestions appreciated! I’ve noticed there is not yet much documentation regarding this, so perhaps we can change that!
At some point we will need some guides and how toos… the sooner the better…
While I agree that documentation is important there is just no use for it now, because there is no point in installing it and (possibly) running into a lot of other errors/issues which will then be reported back to me while I’m trying to figure them out anyway at the moment… so please, be patient, there will be installation/usage documentation and a proper docker file when it’s ready…
Would be a huge win as everybody rushes to use video conferencing.
I posted my results here and they sound similar, which is that Talk doesn’t work for 3+ users, regardless of setting up coTurn.
If you can get something to where it is even manageable at ~5 users I would say this is a huge success. Should have no impact on the business of selling RTC signaling services at all, since basically no customers who only need <10 slots can afford it anyway.
Very interested in this. I’ve been looking at alternatives and Jitsi seems the best but I have no interest in deploying JAVA apps. Can anyone elaborate just where the bottleneck is with Spreed/Talk? If it’s the SFU (Janus) then reusing that will bump into the same brick wall. If a MCU is needed to scale up to 9+ users then that requires large/huge backend processing and I guess that’s how Zoom can support up to 25 users in the free version. If it’s the PHP code that is a problem and moving to Nodejs can help then I’d rather put effort to a ReactPHP/Rachet server side backend that can run anywhere PHP7 is installed rather than require Node.
As the README of the Spreed/Talk app quite clearly states, the issue scaling beyond a few users without SFU is the bandwidth of the individual user since it needs to send about 1Mbit/s per other participant upstream and receive the same amount:
Talk works peer to peer, that is, each participant sends an end-to-end encrypted stream to each other participant and receives one stream per other participant. This grows bandwidth usage with the number of participants. […]
This means that in a call with 5 participants, each has to send and receive about 4 mbit/sec. Given the asymetric nature of most typical broadband connections, it is sending video that quickly becomes the bottleneck. https://github.com/nextcloud/spreed/blob/master/README.md
No offense, but I’m not sure how useful a “I would do X/Y because I like that technology” is - the fact is that @powerpaul started this great effort to provide something to the community. They chose a certain technology and we should keep this thread for offering help and discussion the technicalities. There are plenty of other threads out there which at length discuss the pros and cons of different WebRTC solutions.
The bottleneck without a separate backend is on one hand the polling aspect of PHP through a HTTP server, which means all the signaling is always delayed a bit. On the other hand, if I understood correctly, each peer connects to all of the other peers directly (P2P) which puts a lot of stress on the single client in terms of CPU/bandwidth. That’s where the SFU/MCU (whatever you like) comes in.
There is nothing wrong with Janus, it’s just the SFU Nextcloud/Spreed uses for their “HPB”.
I had a quick look at Jitsi but I always feel uncomfortble around Java programs… Janus is written in C and seems to be set up and working quickly.
Many scaling problems should be solved by 8.0.9, released last week - it adjusts quality based on the nr of participants, among other things. A typical network and hardware setup should handle 5-10 people.
The signalling back-end is now also open source, so you can give that a try.
Wow, that are great news, I was struggling the last weeks with compatibility for the android app (which does strange things, in my opinion…) but now I can have a look at the “real” implementation to see what’s wrong…