Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <>
To: Juliusz Chroboczek <>
Subject: [Galene] Re: Logging
Date: Sun, 10 Jan 2021 14:47:37 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Juliusz Chroboczek <> writes:

>> So in this case, how is using a TURN server different than just having
>> Galene itself listen on a bunch of UDP ports and offer each of those?
> Short answer: Galène needs hundreds or even thousands of ports.  TURN can
> use a single port, which you can pick such that it's accessible from your
> clients.
> Long answer.  Galène uses WebRTC.  WebRTC uses RTP.  RTP transmits
> a collection of tracks.  RTP can work in two modes:
>   - port multiplexing: use the UDP port to associate packets with tracks;
>   - SSID multiplexing: multiplex over a single UDP 5-uple, and use data in
>     the RTP header to associate packets with tracks (this is called
>    "bundling" in WebRTC).

Ah, I see. I think I was mentally assuming SSID multiplexing, so that's
what I was missing. Thanks for the clarification!

> Now, there are two limitations:
>   1. Pion is unable to use a single local UDP port for multiple RTP
>      sessions: it uses a distinct UDP port for every RTP session, even if
>      sessions have dinstinct remote addresses;
>   2. Galène uses a distinct RTP session for every stream (pair of audio
>      and video tracks); in other words, Galène ony bundles at most one
>      video and one audio track.
> Fixing (2) is not a high priority, since it would make the code way more
> complex (bundling is fragile, there are some limitations to what you can
> do when bundling streams with different configurations and some limitations
> to how you can mutate a bundle without tearing it down).  It might
> cause issues with AQMs (is it a good idea to use the same 5-uple for
> different videos?), but you're the specialist here.

No, I don't think multiplexing more streams over the same five-tuple is
a good idea if it can be avoided. If the bottleneck does per-flow
queueing (like FQ-CoDel), you'd want each video flow to be scheduled
separately I think.

Another couple of ideas for packet-level optimisations that may be worth
trying (both originally articulated by Dave Taht):

In the presence of an FQ-CoDel'ed bottleneck it may be better to put
audio and video on two separate 5-tuples: That would cause the audio
stream to be treated as a 'sparse flow' with queueing priority and fewer
drops when congested.

(As an aside, is there a reference for the codec constraints in
browsers? And is it possible to tweak codec parameters, say to burn some
bandwidth to enable really high-fidelity audio for special use cases? Or
is Opus so good that it doesn't matter?)

Another packet-based optimisation that could be interesting to try out
is to mark packets containing video key frames as ECN-capable. If the
bottleneck AQM respects ECN, that would prevent key frames from being
dropped. Ideally you'd also actually respond to CE markings, of course,
but just doing selective marking of the ECN-capable bit inside the
stream would theoretically make it possible to protect key frames while
still reacting normally to drops of other data packets...


  reply	other threads:[~2021-01-10 13:47 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
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 [this message]
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:

  List information:

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

  git send-email \ \ \ \ \
    --subject='[Galene] Re: Logging' \

* 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