Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <jch@irif.fr>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: galene@lists.galene.org
Subject: [Galene] Re: Logging
Date: Fri, 08 Jan 2021 16:34:05 +0100	[thread overview]
Message-ID: <87mtxj789e.wl-jch@irif.fr> (raw)
In-Reply-To: <87turrh6y2.fsf@toke.dk>

>> The direct connection was successful, so the TURN server was never
>> contacted.

> Right, I see. What are the conditions where a direct connection fails?
> Is it just when the client is behind a NAT?

If only one side is behind NAT, you should get a direct connection with no
outside help.

If both sides are behind NAT, they will attempt to establish a paired set
of NAT mappings by synchronising through a STUN server, and then establish
a direct connection (TURN is a superset of STUN, no need to set up
a dedicated STUN server if you've got TURN).  This is usually successful,
but might occasionally fail due to packet loss.

If there is a firewall in the way that drops UDP traffic, or traffic to
high-numbered ports, then the peers will fall back to TURN.  TURN supports
both UDP and TCP proxying, since some networks allow outgoing UDP only to
some ports (typically 1194 for OpenVPN and 10000 for the Cisco VPN client).

ICE-TCP adds an additional step by allowing direct connections over TCP.
It is not designed for peer-to-peer communication, only for client-server
communication, so it should be a perfect fit for Galène.

Once a functioning pair is found, ICE will stick to it.  In Galène, we
restart ICE whenever the connection fails, and also when the user types
"/renegotiate".  (I'd like to detect client-side network changes and restart
ICE automatically, but current browsers don't give me a suitable event
handler.)

All of this happens in parallel, with arbitrary timeouts, so the actual
behaviour tends to be non-deterministic and next to impossible to debug.
See for example

  https://github.com/pion/ice/issues/305

> As for just logging, Galene does propagate JSON parsing errors from the
> Go JSON parser, but because the files are not read on startup you can
> start up the daemon and everything looks fine until someone tries to
> connect...

Hmm... I'm actually using the current behaviour, by using undefined fields
in my JSON files ("contact" and "comment").

But I think you're right.  This will happen in background, so you'll only
get warnings in the log.  After 0.2 is out, though, since Galène is frozen
right now.

-- Juliusz

  parent reply	other threads:[~2021-01-08 15:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-07 21:38 [Galene] Logging Juliusz Chroboczek
2021-01-07 22:45 ` [Galene] Logging Michael Ströder
2021-01-08  0:35 ` Antonin Décimo
2021-01-08 12:40 ` Toke Høiland-Jørgensen
2021-01-08 13:28   ` Juliusz Chroboczek
2021-01-08 13:52     ` Toke Høiland-Jørgensen
2021-01-08 14:33       ` Michael Ströder
2021-01-08 15:13         ` Juliusz Chroboczek
2021-01-08 17:34           ` Michael Ströder
2021-01-08 18:00             ` Juliusz Chroboczek
2021-01-08 15:34       ` Juliusz Chroboczek [this message]
2021-01-08 19:34         ` Toke Høiland-Jørgensen
2021-01-08 19:56           ` Juliusz Chroboczek
2021-01-09  0:18             ` Toke Høiland-Jørgensen
2021-01-09 13:34               ` Juliusz Chroboczek
2021-01-10 13:47                 ` Toke Høiland-Jørgensen
2021-01-10 15:14                   ` [Galene] Congestion control and WebRTC [was: Logging] Juliusz Chroboczek
2021-01-10 15:23                     ` [Galene] " Juliusz Chroboczek
2021-01-10 22:23                     ` Toke Høiland-Jørgensen
2021-01-10 22:44                       ` Dave Taht
2021-01-11  0:07                       ` Juliusz Chroboczek
2021-01-11  0:20                         ` Toke Høiland-Jørgensen
2021-01-11  0:28                           ` Juliusz Chroboczek
2021-01-11  0:30                       ` Dave Taht
2021-01-11  6:23                         ` Dave Taht
2021-01-11 12:55                           ` [Galene] Multichannel audio [was: Congestion control...] Juliusz Chroboczek
2021-01-11 17:25                             ` [Galene] " Dave Taht
2021-01-11 13:38                       ` [Galene] Re: Congestion control and WebRTC [was: Logging] Juliusz Chroboczek
2021-01-11 15:17                         ` Toke Høiland-Jørgensen
2021-01-11 17:20                           ` Dave Taht
2021-01-12  1:38                         ` Juliusz Chroboczek
2021-01-10 15:17                   ` [Galene] Re: Logging 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=87mtxj789e.wl-jch@irif.fr \
    --to=jch@irif.fr \
    --cc=galene@lists.galene.org \
    --cc=toke@toke.dk \
    --subject='[Galene] Re: Logging' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox