(New) Nextcloud Talk Backend Alternative

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:


Any help is very appreciated!

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!


Wow, great work! This will certainly be of interest to others on this forum! What kind of help do you need?

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…

1 Like

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…

1 Like

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… :wink:

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…


Wow. I want to say, as speaker for Nextcloud, that this is super cool. Let me know what help you need.


@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


I am very interested… is there any documentation on how to install and implement (for noobs like me) with and without docker?

…a proof-of-concept and not (yet) stable enough to be used in production environments!

@pieter see the first post to read about progress on Gitlab. Best for noobs to leave them alone.

1 Like

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.

1 Like

@powerpaul Maybe @nickvergessen can help you if you need something specific for your signalling server implementation?

1 Like

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.

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… :wink: 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.

Maybe this post on Github by @nickvergessen helps a bit:

Thank you, I already read that before I decided to take on this project. :wink:

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… :wink:

1 Like