From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1610286457; bh=E58tMapInG85nRJ0V2XlhwyxG/Q468vLYdmPK953tEs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=vxnz5Ij6axJtxOG8G4CmFk4SArWqalNDaEKJLh3hTHRr1mYqDDyjehSPuZR53uwR2 eyOWkOUGINbYlJhcfzvBeiLGCUsD3Udz82qUk/R+SC55piOxOgSWdRgM/tBItBNV9V BlmYQYSvmeNXlC4tfgJK6Rib6xWFi2Wpg6xvAR7gjunT2eivGTEx1U6vW7fpr7a2pT dAFqGp0jUDrhQRdnKirr2NfzINaFNdA9Mi5SjNDHMP533MAWgz9kSfw0+BjtXVKabW qS7SD83fXJgAry71AaL2SkpVp/WgyAvgaTPOrY4sLUjiZPS6qJC7x0VNb4fRMaMFBH krUTb5ra9aREw== To: Juliusz Chroboczek In-Reply-To: <87wnwmnsj9.wl-jch@irif.fr> References: <875z485swt.wl-jch@irif.fr> <87wnwnha9w.fsf@toke.dk> <87v9c77e20.wl-jch@irif.fr> <87turrh6y2.fsf@toke.dk> <87mtxj789e.wl-jch@irif.fr> <87o8hzgr4j.fsf@toke.dk> <871rev6w4a.wl-jch@irif.fr> <87im87gdy3.fsf@toke.dk> <87wnwmnsj9.wl-jch@irif.fr> Date: Sun, 10 Jan 2021 14:47:37 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877dokhpja.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 6SI32BHC7XWEMCB6D45QOQ6ZNX2P566Z X-Message-ID-Hash: 6SI32BHC7XWEMCB6D45QOQ6ZNX2P566Z X-MailFrom: toke@toke.dk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: galene@lists.galene.org X-Mailman-Version: 3.3.2 Precedence: list Subject: [Galene] Re: Logging List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: 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=C3=A8ne needs hundreds or even thousands of ports. TUR= N can > use a single port, which you can pick such that it's accessible from your > clients. > > Long answer. Gal=C3=A8ne 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=C3=A8ne uses a distinct RTP session for every stream (pair of au= dio > and video tracks); in other words, Gal=C3=A8ne ony bundles at most o= ne > 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 limitatio= ns > 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... -Toke