W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2018

Re: Gaming use cases and ICE

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 27 May 2018 19:36:12 +1000
Message-ID: <CAHp8n2mc6oPMRH8+dHYHbGB1U_p-tUfUd7CJJhdx3aMQTTbN4w@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: public-webrtc <public-webrtc@w3.org>
On Sun, May 27, 2018 at 4:19 PM Bernard Aboba <Bernard.Aboba@microsoft.com>

> Sylvia asked:

> "What's the advantage of this over sending multiple offers in parallel in
> JavaScript (asynch)? In my opinion this is needlessly complicating things
> you need to manage the connection with each endpoint separately anyway."

> [BA]  There are a number of scenarios in which latency and join time need
to be minimized, such as in games.

> In a mesh conference with parallel forking (such as is supported in Ortc
lib), 1 offer can be sent versus (n-1) offers without it.
> So not only does it save 0.5 RTT, but it also reduces code complexity and
total packet traffic.

> By separating the IceGatherer and IceTransport, it is possible to share
local candidate state across multiple IceTransports (each of which are
constructed from a single gatherer).
> Combined with Ice candidate filtering, this allows media to be sent after
only a single check (e.g. using a TURN server).

> The end-result is that the mesh conference comes up much more quickly.

Have you tested this is real life? I'm still dubious whether this will
reduce connection setup time in reality, because even if you just produce
one offer, you still have to send it n times because n different endpoints
have to receive it. You have to duplicate it somewhere in the network stack.

Anyway - I've not done any experiments, so wouldn't know - I'm just
theorising here.

Received on Sunday, 27 May 2018 09:36:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:41 UTC