From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=pass header.d=meshpointone.com header.i=@meshpointone.com header.a=rsa-sha256 header.s=key1 header.b=gBF3kvWN; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=meshpointone.com policy.dmarc=none Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) by mail.toke.dk (Postfix) with ESMTPS id 9801A136B439 for ; Mon, 20 Jul 2026 16:38:13 +0200 (CEST) X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meshpointone.com; s=key1; t=1784558292; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=4qGmFHEcotqQ9SPNI+LQKSmGrSEm4HYUGUYpvQsAbiA=; b=gBF3kvWNZSxlOH1UgVCZHSKCVEeYhGD72/y4Zz97fhEh6em2fIwwY91ZcqSy5TeNWcJSVS 2NsmebthZl2NkvmrLkkYYahsL/PGrakROM28+Vmm/FAXjETlrooY3IH0zbge5RM8OTvSrw ZCnCn4ZLwkypkeA9ykuIyYas24kim40NwDaTVEgQgS14OqTcn7y/E+sYs+KisFSioX8y3Q j/t2giw1EpMInsOpcH3E8U0I55SNaGFOFerNqhSaKxrP595GR8XR46X9Dh9IjXdCQBIbMu Pzvb8tCs9ZgIRRhZ5W5rjreb0Z3HMP/3GgxMELb6Y1TviBPLziCehlHIdZPsUQ== From: "Valent@MeshPoint" To: "Juliusz Chroboczek" Cc: "Curtis Villamizar" , galene@lists.galene.org Date: Mon, 20 Jul 2026 14:37:49 +0000 Message-Id: In-Reply-To: <87ik6age80.wl-jch@irif.fr> References: <87bjc6zpwk.wl-jch@irif.fr> <178450473448.1644.1354246601774709853@gauss> <87ik6age80.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB19338D98-498C-4D9C-A1E9-36E52C4CDBCA" X-Migadu-Flow: FLOW_OUT Message-ID-Hash: GGYRRWPH2GYWMWB7H45FLYQUZW2DPBKZ X-Message-ID-Hash: GGYRRWPH2GYWMWB7H45FLYQUZW2DPBKZ X-MailFrom: valent@meshpointone.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Reply-To: "Valent@MeshPoint" Subject: [Galene] Re: Gal?ne for bigger meeting (10-15 people) - problems and UX questions List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --------=_MB19338D98-498C-4D9C-A1E9-36E52C4CDBCA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Juliusz, Tim, all, thank you very much for the detailed answers, this helps me a lot. You are right, I dont know Gal=C3=A8ne good enough to say where is the=20 problem, and I don=E2=80=99t want to guess. So better I measure it properly = on=20 the next test and bring you real numbers. My feeling, maybe I am wrong, is this... with three or four people it=20 worked without any problem, so when ten broke everything it surprised=20 me. I would understand that fifty or hundred would cause issues... But=20 now I understand from you that with an sfu the server upload grows very=20 fast, ten cameras is already around ninety copies, not two or three=20 times more than four. So maybe ten is already a big jump. This is what I=20 want to measure, not assume. So for the next test I would really like your help what to measure and=20 where. I run the docker image, valentt/galene. Your faq says docker is not good=20 for the network. So what is the correct docker setup, is host networking=20 the right thing? Which udp port should I open with the new udp=20 multiplexing? And how do I make Gal=C3=A8ne show the real public ip and not= =20 the private one from the container? If I run relay test from a client and it fails, does this already mean=20 the problem is media and ice and not bandwidth? What should I look for=20 in the ice trace log? Tim says I need around hundred megabit uplink. For some cameras on the=20 default send limit, how much server upload I need, and does simulcast=20 keep it under control? I will measure it with iftop during the test. And=20 the stats page, what does it show me per client, can I read it during=20 the test? Your point about the client side being weaker. With ten or fifteen=20 cameras, how many people overload their own upload on the default?=20 Should I make the default lower for big meetings? Can one bad upload=20 spoil the room for everybody? And kicked out under load, could this be the file limit too low inside=20 the container? So my plan is, before the test I check host networking and the version=20 and the file limit. During, I run relay test, I turn on the ice log, I=20 read the stats page, I measure the server upload, and from each client I=20 collect the outgoing bitrate and the lost packets. Then I bring you the=20 numbers so we see together if it is docker network, server upload, one=20 bad client, or the browser. About Firefox and DJ Stern, I understand, I will tell people to use=20 Chrome (although I used Firefox with no problem), and the raise hand=20 button I will fix like I promised. I also like your idea of a test your microphone and camera button on the=20 login page. The camera can stay off by default, that is fine (I never=20 thought to turn it on by default, just to make sure it works before=20 joining in...), but people should be able to check right away that their=20 microphone and camera actually work, before they join. I think that=20 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=C4=87 CEO valent@meshpointone.com www.meshpointone.com On 2026-07-20T12:14:23+02:00, Juliusz Chroboczek 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=20 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=20 use the camera and microphone at login time, or whether we should do it at=20 the last possible moment as we do currently. The advantage of requesting=20 them early is that joining the discussion has lower friction; the advantage=20 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 --------=_MB19338D98-498C-4D9C-A1E9-36E52C4CDBCA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Juliusz, Tim, all,

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

You are right, I dont know Gal=C3=A8ne good enough to say where is the prob= lem, and I don=E2=80=99t 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 worke= d without any problem,=C2=A0 so when ten broke everything it surprised me.= I would understand that fifty or hundred would cause issues... But now I un= derstand from you that with an sfu the server upload grows very fast, ten c= ameras is already around ninety copies, not two or three times more than fo= ur. 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 wher= e.

I run the docker image, valentt/galene. Your faq says docker is not good fo= r 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? An= d how do I make Gal=C3=A8ne 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 i= ce trace log?

Tim says I need around hundred megabit uplink. For some cameras on the defa= ult send limit, how much server upload I need, and does simulcast keep it u= nder control? I will measure it with iftop during the test. And the stats p= age, 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 th= e default lower for big meetings? Can one bad upload spoil the room for eve= rybody?

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 th= e 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 th= e 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 lo= gin 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 c= amera actually work, before they join. I think that would really help the o= nes who click connect without reading the screen.

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

Valent


Best regards,

3D"MeshPoint
Valent Turkovi=C4=87
CEO


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

> T= he 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
3D"" --------=_MB19338D98-498C-4D9C-A1E9-36E52C4CDBCA--