- From: Lennart Grahl <lennart.grahl@gmail.com>
- Date: Sun, 27 May 2018 15:23:12 +0200
- To: public-webrtc@w3.org
- Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>
On 27.05.2018 08:13, Bernard Aboba wrote: > 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. I think Silvia has a point that this offer needs to be duplicated somewhere, so it's questionable whether it requires less traffic. And I'm also wondering why it would spare half an RTT. > 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. I don't understand why that would result in faster connection establishment. Can you elaborate? IIRC an RTCCertificate can be reused already, so the only advantage I see is reusing existing UDP sockets of the local candidates. A few questions on that: 1. AFAIK UDP sockets are extremely cheap. Do we have use cases where having many UDP sockets is a problem, maybe on embedded platforms? 2. IIRC this technique requires multiplexing based on the source addresses for incoming packets, so they can be mapped back to their ICE transport. Wouldn't this prevent (possible) mobility extensions in the future where the UDP source IP changes on-the-fly? 3. Would this allow to reuse TURN allocations? Cheers Lennart
Received on Sunday, 27 May 2018 13:23:38 UTC