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 not finished and still not working very well. It is supposed to be a proof-of-concept and not (yet) stable enough to be used in production environments!
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ā¦
Thanks, but donāt get too excited yet, itās just an attempt but I have no idea if it wil ever work out as expected.
Well, the most difficult thing is the correct interpretation of the API as I can only guess what it should mean and what the HPB is probably respondingā¦
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. spreed/README.md at main Ā· nextcloud/spreed Ā· GitHub
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.
As for the backend itself, Iām a Typescript/Javascript programmer so I prefer NodeJS over PHP but I guess thatās just a matter of opinion/taste. Since everything will be packed up in a Docker container it will not matter to the average user anyway.
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ā¦
