Is there any sample code of working with Jitsi Videobridge (without lib-jitsi-meet) in existence?

Question

TL;DR: working on a WebRTC-based webinar platform, which should allow 1000 of people in a room, Jitsi Meet does the job but forces a connection (and a server thread) for each-oh-each, which is 1,000,000 threads on a server -> not going to work. Jitsi founders advised doing it without lib-jitsi-meet, invoking REST API directly, pointed at a doc

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-colibri.md

but it gives a lot more questions than answers.

Is there any complete, end-to-end, example of how to stream a webcam stream to Jitsi Videobridge, and then play it in another client, using JS in a browser (OK if it's only Chrome), with no use of lib-jitsi-meet? Some other form of connectivity between clients, like socket.io or anything else, is possible of course.

Food

any word on this Mikhail? Were you able to find any examples? Perhaps you could answer your own question by now? I've got the same question :) – Atonement

No there isn't. I already helped a few clients transition away from Jitsi :) – Food

Is there any update? I have the same problem. – Penult

There are none. Jitsi is abandonware, forget it. Use Wowza Media Server, it has excellent, perfectly working and documented WebRTC implementation, and support is willing to help instantly, and it's fairly cheap. – Food

Would you come to the same conclusion today, given how broadly jitsi seems to have been adopted? At the same time it's very difficult to find documentation on running your own jitsi videobridge without the need for their custom UI. – Solvency

Answer 1

It is possible. JVB has REST API and it only gives ports for audio/video. We should have our own signaling server that creates offer with given port in it. Then that offer has to be passed to client via websocket and creates RTCPeerConnection. I have signaling in place but I am struck with video quality issue.

Scorpaenid

You need to connect to the websocket URL (provided by the bridge in the same response as the offer) and set your receiver constraints, otherwise you will only receive the lowest simulcast layer. This websocket is used as a secondary signalling channel for rapid changes (e.g. signalling max res for receiving other endpoints based on the user resizing the browser window or changing their selected layout from stage to tile). – Fargone