[Galene] Re: Gal?ne for bigger meeting (10-15 people) - problems and UX questions

[Juliusz Chroboczek <jch@irif.fr>]

Hi Valent,

> My feeling, maybe I am wrong, is this... with three or four people it worked
> without any problem,  so when ten broke everything it surprised me. I would
> understand that fifty or hundred would cause issues... But now I understand
> from you that with an sfu the server upload grows very fast,

See below, the bit with the formulas.

> I run the docker image, valentt/galene. Your faq says docker is not good for
> the network. So what is the correct docker setup, is host networking the right
> thing? Which udp port should I open with the new udp multiplexing? And how do I
> make Galène show the real public ip and not the private one from the container?

This is not fully implemented yet:

1. udp-mux and udp-range only control direct UDP flows.  They do
   not control TURN flows, either UDP or TCP.

2. there is no provision for NAT: if the server is behind NAT, then it
   will announce its private addresses, not the public ones.

My plan is to work on that after 1.2 is out.  I'm hoping that you will
work out exactly what's needed in order to make it work well inside Docker.

> If I run relay test from a client and it fails, does this already mean the
> problem is media and ice and not bandwidth?

If the relay test fails, then the TURN server is not accessible.  Since
TURN is used as a last-resort fallback when everything else fails, this is
really bad.

Please check that you are setting the "-turn" flag correctly: it must
contain the server's *external* address.

> What should I look for in the ice trace log?

The ICE trace is not useful in my experience.  What is useful is the
browser's ICE internals page.

> Tim says I need around hundred megabit uplink. For some cameras on the default
> send limit, how much server upload I need, and does simulcast keep it under
> control?

Ideally, you need (use a fixed-pitch font):

      ∑   k × s_g × r_g
     g∈G

where G is the set of groups, s_g is the number of senders in group
g (people with their camera on), and r_g is the number of receivers, and
k is the throughput of each flow (varies between 100kbit/s and 700kbit/s).
So for one group with 10 people all with their cameras on, you ideally
need (k=700kbit/s) :

    700 kbit/s × 10² = 70 Mbit/s

For a group with 100 people but only one lecturer, you need :

    700 kbit/s × 100 = 70 Mbit/s.

> And the stats page, what does it show me per client, can I read it
> during the test?

Yes.  It gives you the actual throughput of each flow, the maximum
throughpout that the server has allocated for the flow, the RTT and
jitter, and the amount of packet loss.  You need to check :

  - that the allocation is reasonable;
  - that the throughput is obeying the allocation;
  - that the RTT and jitter are reasonable;
  - that the packet loss is below 1%.

> And kicked out under load, could this be the file limit too low inside the
> container?

This is a mystery.  I've seen this in groups with many instanced of
Safari.  I swear I didn't include any anti-Apple code inside Galene.

> About Firefox and DJ Stern, I understand, I will tell people to use Chrome
> (although I used Firefox with no problem), and the raise hand button I will fix
> like I promised.

Firefox should work fine if you use 151 or later.  I'm going to add some
code to display a warning if people use older Firefoxen.

> I also like your idea of a test your microphone and camera button on the login
> page. The camera can stay off by default, that is fine (I never thought to turn
> it on by default, just to make sure it works before joining in...), but people
> should be able to check right away that their microphone and camera actually
> work, before they join. I think that would really help the ones who click
> connect without reading the screen.

Cool.  I'll try to whip up an ugly prototype tonight, and let the people
with taste (like you) improve the appearance.

— Juliusz