From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: galene@lists.galene.org
Subject: [Galene] Re: Heads-up: built-in TURN server
Date: Mon, 18 Jan 2021 23:27:08 +0100 [thread overview]
Message-ID: <87o8hlridf.fsf@toke.dk> (raw)
In-Reply-To: <87mtx5yk96.wl-jch@irif.fr>
Juliusz Chroboczek <jch@irif.fr> writes:
>>>> Is there any benefit to switching to the built-in one if I already have
>>>> a working setup with an external TURN server?
>
>>> None at all, and you'd lose IPv6 support.
>
>> In that case, would it not be better to only start up the built-in TURN
>> server if no explicit turn server config is present, instead of
>> requiring a command-line option to turn it off?
>
> If the built-in server is enabled, it will be injected at the end of the
> ICE configuration, your external server will be used first, with fallback
> to the built-in server if connectivity cannot be established through the
> external server.
>
> If the built-in server is enabled and uses the same port as your external
> server, then the bind() call will fail (EADDRINUSE), you'll get a friendly
> log message, and the built-in server will be disabled.
>
> The only troublesome case is if the ports are the same, and Galène is
> started before the external TURN server, in which case the external TURN
> server won't be able to bind its ports.
>
> I find the current behaviour simpler to explain than what you suggest, and
> I'm trying to optimise for simplicity. I'm open to different opinions,
> though, especially if you find any catastrophic failure modes with the
> current defaults.
What about when the external TURN server is on a different IP, so Galene
has no problem starting up the internal one, but it's firewalled off to
clients can't connect to it? In that case presumably it'll just be
another TURN candidate offered to clients which will fail? Isn't that
bad for latency (I think Firefox emits a warning recommending a max of
two candidates)?
-Toke
next prev parent reply other threads:[~2021-01-18 22:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-18 21:26 [Galene] " Juliusz Chroboczek
2021-01-18 21:38 ` [Galene] " Toke Høiland-Jørgensen
2021-01-18 21:44 ` Juliusz Chroboczek
2021-01-18 21:54 ` Toke Høiland-Jørgensen
2021-01-18 22:03 ` Michael Ströder
2021-01-18 22:04 ` Juliusz Chroboczek
2021-01-18 22:27 ` Toke Høiland-Jørgensen [this message]
2021-01-18 22:37 ` Juliusz Chroboczek
2021-01-18 23:05 ` Toke Høiland-Jørgensen
2021-01-18 23:39 ` Michael Ströder
2021-01-19 0:22 ` Juliusz Chroboczek
2021-01-19 11:47 ` Toke Høiland-Jørgensen
2021-01-19 11:52 ` Juliusz Chroboczek
2021-01-19 12:12 ` Toke Høiland-Jørgensen
2021-01-19 12:37 ` Michael Ströder
2021-01-19 12:48 ` Juliusz Chroboczek
2021-01-19 13:07 ` Toke Høiland-Jørgensen
2021-01-19 8:33 ` Rémi Nollet
2021-01-19 11:00 ` Gabriel Kerneis
2021-01-19 11:21 ` 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=87o8hlridf.fsf@toke.dk \
--to=toke@toke.dk \
--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