jech

You should be able to get much better value with a self-managed solution.

For instance, the server at <https://galene.org:8443> is running on a "Value" OVH VPS (<https://www.ovhcloud.com/en/vps/>) which is rented for under 6€/month. During lockdown, It was regularly used for lectures with 70 students or so, but that's an unfair comparison, since students tend to keep their camera off during the lecture.

Yes, and that's always been the case.

> there is still a fair amount of assemby required

I'm not sure what you mean. A from scratch installation of Galene is just

    git clone https://github.com/jech/galene/
    cd galene
    CGO_ENABLED=0 go build -ldflags='-s -w'
    mkdir groups
    echo '{"presenter":[{}]}' > groups/demo.json
    ./galene &

Do you think it could be made any simpler?

There's nothing particularly difficult on the server side — a quality SFU should be capable to handle on the order of 400 video flows per core, and there are quite a few high-quality free software SFUs available (Janus, Jitsi, ion-sfu, livekit, Galene). To give some perspective: we're using Galene for lectures, and our single-CPU server uses around 40% CPU usage in a room with 120 students (who keep their cameras switched off during the lecture, of course, and only occasionally switch them on to ask questions).

As the grandparent mentioned, the problem is the client side. Since there is no standard videoconferencing protocol, every free software project needs to develop their own clients. And it's difficult for a free software project to have the manpower and expertise to develop quality clients for the web, Android and iOS, so in effect what we currently have are mostly half-baked web clients.

There is some hope, though. The IETF have been working on standard protocols for ingress (https://datatracker.ietf.org/wg/wish/), and if their protocols get deployed, you'll be able to use the same streaming software (think OBS) or IP camera with multiple distinct videoconferencing servers. An interoperable interactive videoconferencing protocol is nowhere near, but as more people understand videoconferencing technology, there is some hope that people will get together and start working on multi-protocol clients (remember Pidgin?).

Full disclosure: I'm the author of Galene (https://galene.org), and I've been actively participating in the Pion community (https://github.com/pion/webrtc) and collaborating with the authors of ion-sfu (https://github.com/pion/ion-sfu) and LiveKit (https://github.com/livekit).

It looks like we're now understanding each other.

> It won't scale to a large number of streams.

Galene was designed for lectures and conferences, where a small number (1-5) of streams are sent to hundreds or thousands of receivers (and the budget is virtually nonexistent, because teaching and public research are eternally underfnded). It works beautifully for that particular application. It also happens to work well for medium-size meetings (25 senders, 50 receivers), which is a nice bonus, but not what the software was designed for.

> I'd be interested to hear how many you can have running at the same time before you notice problems.

We've been doing staff meetings with 25 senders and 50 receivers (50 people attending, half of which have their camera switched off). However, our main goal is supporting large lectures (2 flows distributed to hundreds of students, with students only switching their camera on in order to ask a question or show their cat): the commercial offerings work reasonably well for meetings, but are completely inadapted to lecturing.

> You can't easily prioritize one stream over the others if you want an "active speaker" view.

Oh, that. We simply forcibly switch the background streams to the lowest spatial layer. It works very well, but relies on the senders implementing either simulcast or SVC. Which is something we may safely assume (all desktop browsers implement at least simulcast, and lecturing is done with laptops).

Ah, I see where your confusion stems from.

Galène doesn't bundle multiple streams in a single PeerConnection: it puts each stream (audio+video) in its own PeerConnection. Thus, if we can assume that the audio traffic does not significantly contribute to congestion, then performing congestion control per-track or per-connection is exactly equivalent.

(It's a tradeoff. Bundling reduces the amount of ICE traffic and makes for faster connection establishment, but it ends up putting multiple unrelated streas into a single transport-layer flow, which confuses traffic shapers and AQMs. I'm betting that things like fq-codel are being deployed as we speak; if my bet is wrong, then bundling will turn out to be the better choice.)

Pyrite inherits most of Galene's features, which are listed at https://galene.org. (Galene's server has some extra features that are not used by Galene's native client yet, but were designed for third-party frontends, but I don't think Pyrite is using any of those yet.)

> A monolith doesn't seem superior except for the very smallest deployments

True. Galene is designed to encourage small deployments: it's a single binary that is simple enough and cheap enough so that every high school can have their own instance and not rely on an external IT team.

For large deployments, where accidental complexity is not as much of an issue, you'd most probably want to use some more complex and more flexible software.

Thanks for the review, pthatcherg.

> For example, it uses REMB feedback messages from the client to calculate allowable bitrates rather than calculating the bitrates itself (as Jitsi and Signal's SFU do).

I'm not sure what you are saying. Galene listens to REMB messages and computes its own bitrate, then combines the two informations. https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5...

> I could be wrong, but it looks like the bitrate allocation code only allocates the bitrate for one of the video streams, not all of them

The code you point at is not the bitrate allocation code, it's the code that chooses which scalable layer to assign to a given client. The code you're looking for is here: https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5...

> In short, I think Galene has a ways to go before it works as well as Jitsi (Videobridge) [...] the SFU we use for Signal group calls is also open source

Jitsi VideoBridge is a great piece of software, no doubt about it. I'm sure that Signal's SFU is competently done too.

Yes, Galene 0.4 and later uses SVC by default when the following conditions are satisfied:

  * the sender is using a Chromium-like browser (the receiver may be Chromium, Firefox or Safari);
  * the codec is either VP8 or VP9;
  * there are at least three users in the group.

You can see a demo at https://galene.org:8443/group/public and https://galene.org:8443/group/public-vp9 (any username, empty password).

Duplicating a packet in the network is called multicast, and it isn't implemented in the real Internet.

Most large-scale broadcasts use technologies such as HTTP Live Streaming (HLS) or MPEG-DASH, which carve a video into 3-second intervals that are then distributed using ordinary HTTP over a CDN. The problem with these technologies is that they have a latency of a few seconds, which means that you cannot have a meaningful conversation over them.

By default, we bind to ":8443", which is Go's notation for port 8443 on all IP addresses, IPv4 and IPv6. Galène's WebSocket is located at /ws, and I believe that nginx requires that you configure this specially. See https://www.nginx.com/blog/websocket-nginx/.

An alternative to reverse proxying is to use HTTP redirects: you can define a group as

{"redirect":"https://otherserver.example.com:8443/group/groupname"}

and Galène will send an HTTP redirect whenever somebody attempts to join this group.

I'll be glad to continue this conversation on the mailing list (https://lists.galene.org/postorius/lists/galene.lists.galene...).

Not really. In a p2p scenario with n participants, every participant needs to send (n - 1) copies of the packet. In a centralised scenario, each participant sends just one copy of the packet, and the server duplicates it (n - 1) times. Whether this is wasteful depends on where the server is located. If the server is close to the receivers, it is a net gain. If the server is in the US while all of the participants are in Europe, it's a terrible waste, since all of the packets need to cross the Atlantic. Server federation solves the issue: you put one server in the US, one in Europe, and each packet crosses the Atlantic exactly once.

Sean is the benevolent dictator of the Pion WebRTC library (https://github.com/pion/webrtc/), which is at the core of Galène. He was aware I'd be posting on HN, but we didn't arrange anything in advance, if that's what you're implying.

That's already implemented. Connect as an administrator and type /help in the chat window. (Your weapons are /warn, /mute, /kick, and /lock, in increasing order of severity.)

Galène is not peer-to-peer: it's a traditional centralised server, where all media traffic goes through Galène. TURN is only used if the user's network blocks the UDP traffic between the client and Galène (TURN can use TCP, and can run on an unblocked port such as 443 or 1194).

Before Galène, I experimented with a pure peer-to-peer system, with end-to-end encryption. I found it to be too unreliable for group communication: with just 5 people in a group, you need to establish 10 peer-to-peer WebRTC flows, and the likelihood that all of them work well is essentially zero.

I haven't thought about it seriously, but I was thinking about simply using a shared key (PBKDF2, since that is implemented in the browser), with a symmetric cipher and HMAC.

To tell the truth, I haven't seen much demand for end-to-end: this is a web application, so an attacker who controls the server can simply serve Javascript with a backdoor.

That's okay — teaching is over until January, and at any rate students are a forgiving user base :-)

Jitsi is a great piece of software, as are the other alternatives listed on the web page. The opposition is not with other self-hosted videoconferencing solutions, but with cloud-based systems that impose restrictive usage conditions.

How do we convince people to switch to self-hosted solutions? I think that part of the solution lies in making them easier to deploy: ideally every high school, every community college should be able to have their own videoconferencing server, which can be used for lectures, for practicals, for student-teacher meetings ("office hours"), and hopefully for student socialisation (although in my experience students tend to prefer Discord, notwithstanding their outrageous usage conditions).

Galène is designed to be as easy and cheap to deploy as reasonable. It also has a number of features that make it useful for practicals (sharing multiple windows simultaneously, automatic creation of subgroups), which we found very difficult to organise online during the first French lockdown.

> I'd add an anonymous option to the login

Good idea. I'll check with Alain (the UI guy).

> if it's non-encrypted or encrypted

It's always encrypted (WebRTC doesn't support plaintext communcation). If we ever add an option for end-to-end encryption, we'll add an indicator.

> You can put different rooms on different servers. They don't have to aware of each other.

Yes. You could then use a reverse HTTPS proxy to route each client to the right instance of Galène.

For very large groups, that need to be split between multiple servers, you'll need to wait until we implement server federation (distributing a group over multiple, geographically distant servers). I know for a fact that Jitsi implements federation, not sure about Ion-SFU.

Janus is a great piece of software. It's extremely flexible due to its plugin system, and implements all of the fun bits of the WebRTC protocol suite that make it so challenging to build a performant SFU.

The unnamed SFU has different goals. It's aimed at doing just one thing — lectures and talks —, but to scale to thousands of users on a $10 VPS, and to be trivial to deploy (just copy a single binary and a few HTML files to your server).

In a sense, Janus pays the price of its flexibility: there are just too many options that the user has to choose among. The Unnamed SFU tries to eschew options, and therefore be simple enough for your mother to install on her VPS (or even on her laptop — why not?).

Hi,

I'm the author of the software. The plan is to distribute it under a free license, most probably the MIT license, when I'm confident it's stable enough to be widely used.

Sorry for the hassle, but I have some experience with distributions packaging early versions of my software and then failing to update them in a timely manner.