Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: "Valent@MeshPoint" <valent@meshpointone.com>
To: "Juliusz Chroboczek" <jch@irif.fr>
Cc: "Curtis Villamizar" <curtis@orleans.occnc.com>, galene@lists.galene.org
Subject: [Galene] Re: Gal?ne for bigger meeting (10-15 people) - problems and UX questions
Date: Mon, 20 Jul 2026 14:37:49 +0000	[thread overview]
Message-ID: <eme60e7d38-ff2b-4a7e-bde3-1cb6d9e7b8c9@meshpointone.com> (raw)
In-Reply-To: <87ik6age80.wl-jch@irif.fr>

[-- 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 --]

  reply	other threads:[~2026-07-20 14:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16 14:19 [Galene] Galène for bigger meeting (10-15 people) - problems and UX questions Valent Turković
2026-07-16 16:28 ` [Galene] " Tim Panton
2026-07-16 17:24 ` err404
2026-07-16 19:38 ` Juliusz Chroboczek
2026-07-19 19:45   ` [Galene] Re: Gal?ne " Curtis Villamizar
     [not found]   ` <178450473448.1644.1354246601774709853@gauss>
2026-07-20 10:14     ` Juliusz Chroboczek
2026-07-20 14:37       ` Valent@MeshPoint [this message]
2026-07-20 16:03         ` Juliusz Chroboczek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eme60e7d38-ff2b-4a7e-bde3-1cb6d9e7b8c9@meshpointone.com \
    --to=valent@meshpointone.com \
    --cc=curtis@orleans.occnc.com \
    --cc=galene@lists.galene.org \
    --cc=jch@irif.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox