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

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

[Valent Turković]

[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]

Hello everyone,

I am testing Galène on my own server with the Docker image. The install works fine, technically Galène works without problem.

I tested it quite wide - with my two phones, laptop on Linux and desktop on Windows, also iPhone and iPad. Browsers: Firefox on Linux, Brave on Windows. So really many different platforms and browsers.

First I tested with some colleagues who are more technical, and it went ok. Maybe one person had audio problem, but that was some strange Android in a bus, so maybe it was the internet.

But yesterday I had one big fail for a meeting of around 10-15 people. I gave them the link to my test server. First thing, when they came to the login window, they were confused because there is username AND password field, even it is a test room that does not need password. This confused them right away. So I commented out the password field in the UI, to have only login field, and this helped.

But still many of them had technical problems - for some the audio did not work, some had glitches. Here is some direct feedback from the people (it is honest, maybe sometimes it hurts, but it is the truth):
- Mirek: "We needed a 'raise hand' button and didn't find one, otherwise everything worked afaik"
- DJ Stern: "I didn't hear or see anyone" and "it was visually glitching out between the text chat and attendees view"
- Patrik: "oyea when dj joined chat window was popping up and closing kinda"
- Daya: "I tried all three options numerous times as kept getting kicked out but it seemed to randomly work on all three at times"

In the end the people gave up on Galène and we switched to Google Meet - even it was me who is pushing that we use Galène, so for me this is not nice.

My feeling is there is quite a lot of UI/UX problems here. For example, by default it asks "what you want - microphone, or microphone + camera". My guess is that many people who had problems did not understand what this means, and they left it on default "none", and that is why their audio did not work.

Because of this I would even suggest that by default this question is not asked - hide it under some "advanced" button, or put it somewhere after login. I don't really understand why someone would log in to a room as chat only. Let the camera and microphone be off by default, but the browser must have the permissions, because otherwise for a big number of people Galène is useless - it will make problems and they simply will not use it.

So my question: who used Galène in such situation, with 10-15 people, and what problems did you have? Because clearly there are still some bugs that are not solved.

Thanks,
Valent

--
Valent

[-- Attachment #2: Type: text/html, Size: 4225 bytes --]

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

[Tim Panton]

[-- Attachment #1: Type: text/plain, Size: 3753 bytes --]

With 10 or 15 people you are going to need pretty good connectivity to the server for it to work. A minimum of 100Mbit/s uplink. 

Did you have that ?

I use the bare metal install for a 6-8 person group on a self hosted old server with a 100mbit uplink and it works ok, but I have also decreased the default video quality to low.
(Which is enough for a big group unless you are screen sharing).

Our experience in the past is that Galène does not really like being on an asymmetric connection with more downlink than uplink bitrate, somehow the bandwidth estimation gets confused. 

Tim.

> On 16 Jul 2026, at 15:19, Valent Turković <valent@meshpointone.com> wrote:
> 
> Hello everyone,
> 
> I am testing Galène on my own server with the Docker image. The install works fine, technically Galène works without problem.
> 
> I tested it quite wide - with my two phones, laptop on Linux and desktop on Windows, also iPhone and iPad. Browsers: Firefox on Linux, Brave on Windows. So really many different platforms and browsers.
> 
> First I tested with some colleagues who are more technical, and it went ok. Maybe one person had audio problem, but that was some strange Android in a bus, so maybe it was the internet.
> 
> But yesterday I had one big fail for a meeting of around 10-15 people. I gave them the link to my test server. First thing, when they came to the login window, they were confused because there is username AND password field, even it is a test room that does not need password. This confused them right away. So I commented out the password field in the UI, to have only login field, and this helped.
> 
> But still many of them had technical problems - for some the audio did not work, some had glitches. Here is some direct feedback from the people (it is honest, maybe sometimes it hurts, but it is the truth):
> - Mirek: "We needed a 'raise hand' button and didn't find one, otherwise everything worked afaik"
> - DJ Stern: "I didn't hear or see anyone" and "it was visually glitching out between the text chat and attendees view"
> - Patrik: "oyea when dj joined chat window was popping up and closing kinda"
> - Daya: "I tried all three options numerous times as kept getting kicked out but it seemed to randomly work on all three at times"
> 
> In the end the people gave up on Galène and we switched to Google Meet - even it was me who is pushing that we use Galène, so for me this is not nice.
> 
> My feeling is there is quite a lot of UI/UX problems here. For example, by default it asks "what you want - microphone, or microphone + camera". My guess is that many people who had problems did not understand what this means, and they left it on default "none", and that is why their audio did not work.
> 
> Because of this I would even suggest that by default this question is not asked - hide it under some "advanced" button, or put it somewhere after login. I don't really understand why someone would log in to a room as chat only. Let the camera and microphone be off by default, but the browser must have the permissions, because otherwise for a big number of people Galène is useless - it will make problems and they simply will not use it.
> 
> So my question: who used Galène in such situation, with 10-15 people, and what problems did you have? Because clearly there are still some bugs that are not solved.
> 
> Thanks,
> Valent
> 
> Best regards,
> 
> 
> Valent Turković
> CEO
> valent@meshpointone.com <mailto:valent@meshpointone.com>
> www.meshpointone.com <http://www.meshpointone.com/>_______________________________________________
> Galene mailing list -- galene@lists.galene.org
> To unsubscribe send an email to galene-leave@lists.galene.org


[-- Attachment #2: Type: text/html, Size: 5517 bytes --]

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

[err404]

I am not expert, so take my message with no waranties.

the audio or video issues can append when using ipv4 and filtered ports.
you can connect, but you will not hear or see anything, or you can hear and see people but they can't see or hear you...
a solution for that is using a TURN relay server,

another solution is using ipv6 only, so by default you will have no ports filtered.

see you

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

[Juliusz Chroboczek]

Hi Valent,

> I am testing Galène on my own server with the Docker image. The install works
> fine, technically Galène works without problem.

Are you running Galene on bare hardware, or inside a Docker container?
Since you still haven't described how you worked around the limitations of
Docker's networking setup, there's not much we can help with if it's the
latter.

> But still many of them had technical problems - for some the audio did not
> work, some had glitches.

Did you have enough throughput on the server to handle all of the traffic?
Since Galene was optimised for lectures with many students, Galene is pretty
good at dealing with congestion in the server->client direction, but deals
poorly with congestion in the client->server direction: we expect the
lecturer to have a good connection, or, if they do not, to limit
throughput using the « Send » side menu.

> - Mirek: "We needed a 'raise hand' button and didn't find one, otherwise
> everything worked afaik"

Yep, the Raise Hand button is hidden in the menu.  I remember that you
volunteered to fix that.

> - DJ Stern: "I didn't hear or see anyone"

That looks like Firefox bug 2033783:
https://bugzilla.mozilla.org/show_bug.cgi?id=2033783.  Please ask them to
upgrade their browser.

(I'm starting to be seriously p*ssed off with the bugs in Firefox's
implementation of WebRTC, I'm really tempted to add a warning that Firefox
is not supported.)

> "it was visually glitching out between the text chat and attendees view"

> My feeling is there is quite a lot of UI/UX problems here. For example, by
> default it asks "what you want - microphone, or microphone + camera". My guess
> is that many people who had problems did not understand what this means, and
> they left it on default "none", and that is why their audio did not work.

That's a deliberate design choice.  It is my opinion that a normal human
being do not want to walk into a meeting with their camera switched on:
they want to lurk for a while before they switch their camera on.  At
least, that's my experience with students.

After a lot of discussions, I have agreed to add the login menu for those
people who really want to show their face straight away, but the expected
UX is that you come in, lurk for a while, then hit « Present ».

> I don't really understand why someone would log in to a room as chat only.

Because you want to listen to the discussion for a while before you
participate?  Or perhaps because it's a lecture and you're a student who
will only turn on their camera when they have a question to ask?

> Let the camera and microphone be off by default, but the browser must
> have the permissions, because otherwise for a big number of people
> Galène is useless - it will make problems and they simply will not use it.

I'm not sure.  Should we be asking for permissions even for those users
who only intend to listen to the lecture?

> So my question: who used Galène in such situation, with 10-15 people, and what
> problems did you have?

For 10 people, the server is receiving 10 flows, and sending 90 flows (9
flows to 10 people).  At 700kbit/s for each flow, that's over 7Mbit/s down
and 60Mbit/s up from the point of view of the server.  Is your
connectivity in that ballpark?

-- Juliusz

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

[Curtis Villamizar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1787 bytes --]

In message <87bjc6zpwk.wl-jch@irif.fr>
Juliusz Chroboczek writes:
> 
> > My feeling is there is quite a lot of UI/UX problems here. For example, by
> > default it asks "what you want - microphone, or microphone + camera". My guess
> > is that many people who had problems did not understand what this means, and
> > they left it on default "none", and that is why their audio did not work.
>  
> That's a deliberate design choice.  It is my opinion that a normal human
> being do not want to walk into a meeting with their camera switched on:
> they want to lurk for a while before they switch their camera on.  At
> least, that's my experience with students.
>  
> After a lot of discussions, I have agreed to add the login menu for those
> people who really want to show their face straight away, but the expected
> UX is that you come in, lurk for a while, then hit « Present ».
>  
> > I don't really understand why someone would log in to a room as chat only.
>  
> Because you want to listen to the discussion for a while before you
> participate?  Or perhaps because it's a lecture and you're a student who
> will only turn on their camera when they have a question to ask?
>  
> > Let the camera and microphone be off by default, but the browser must
> > have the permissions, because otherwise for a big number of people
> > Galène is useless - it will make problems and they simply will not use it.
>  
> I'm not sure.  Should we be asking for permissions even for those users
> who only intend to listen to the lecture?


The default could be set in the group definition.  chat-only for
lecture, camera+microphone for chat or meeting.  This way the person
setting up the group can make the decision based on how the group is
used.

Curtis

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

[Juliusz Chroboczek]

> The default could be set in the group definition.  chat-only for
> lecture, camera+microphone for chat or meeting.  This way the person
> setting up the group can make the decision based on how the group is
> used.

There are two different issues here.

First, there's whether the camera and microphone should be switched on
when entering a group.  On this subject: I feel very strongly that Galene
should *never* switch on the user's camera or microphone without an
explicit action from the user.  I also think that a user who enters
a group should be forced to lurk in silence for a few seconds before they
are allowed to turn their camera on, so that they can check they are in
the right meeting.

For these reasons, switching on the camera automatically upon entering
a group is not something I'll implement in Galene.

The other issue is whether we should request the browser permission to use
the camera and microphone at login time, or whether we should do it at the
last possible moment as we do currently.  The advantage of requesting them
early is that joining the discussion has lower friction; the advantage of
asking them later is that we don't worry the user uselessly.

I think the right solution is to have a button "test your microphone and
camera" on the login page that leads to a simple echo page.

-- Juliusz

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

[Valent@MeshPoint]

[-- Attachment #1: Type: text/plain, Size: 4602 bytes --]

Hi Juliusz, Tim, all,

thank you very much for the detailed answers, this helps me a lot.

You are right, I dont know Galène good enough to say where is the 
problem, and I don’t want to guess. So better I measure it properly on 
the next test and bring you real numbers.

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, ten cameras is already around ninety copies, not two or three 
times more than four. So maybe ten is already a big jump. This is what I 
want to measure, not assume.

So for the next test I would really like your help what to measure and 
where.

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?

If I run relay test from a client and it fails, does this already mean 
the problem is media and ice and not bandwidth? What should I look for 
in the ice trace log?

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? I will measure it with iftop during the test. And 
the stats page, what does it show me per client, can I read it during 
the test?

Your point about the client side being weaker. With ten or fifteen 
cameras, how many people overload their own upload on the default? 
Should I make the default lower for big meetings? Can one bad upload 
spoil the room for everybody?

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

So my plan is, before the test I check host networking and the version 
and the file limit. During, I run relay test, I turn on the ice log, I 
read the stats page, I measure the server upload, and from each client I 
collect the outgoing bitrate and the lost packets. Then I bring you the 
numbers so we see together if it is docker network, server upload, one 
bad client, or the browser.

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.

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.

Thank you, I really want to make this work good.

Valent


Best regards,

MeshPoint Logo

Valent Turković
CEO
valent@meshpointone.com
www.meshpointone.com


On 2026-07-20T12:14:23+02:00, Juliusz Chroboczek <jch@irif.fr> wrote:

 > The default could be set in the group definition. chat-only for
 > lecture, camera+microphone for chat or meeting. This way the person
 > setting up the group can make the decision based on how the group is
 > used.

There are two different issues here.

First, there's whether the camera and microphone should be switched on
when entering a group. On this subject: I feel very strongly that Galene
should *never* switch on the user's camera or microphone without an
explicit action from the user. I also think that a user who enters
a group should be forced to lurk in silence for a few seconds before 
they
are allowed to turn their camera on, so that they can check they are in
the right meeting.

For these reasons, switching on the camera automatically upon entering
a group is not something I'll implement in Galene.

The other issue is whether we should request the browser permission to 
use
the camera and microphone at login time, or whether we should do it at 
the
last possible moment as we do currently. The advantage of requesting 
them
early is that joining the discussion has lower friction; the advantage 
of
asking them later is that we don't worry the user uselessly.

I think the right solution is to have a button "test your microphone and
camera" on the login page that leads to a simple echo page.

-- Juliusz

[-- Attachment #2: Type: text/html, Size: 6438 bytes --]

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

[Juliusz Chroboczek]

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