Re: Gaming use cases and ICE

On May 27, 2018, at 6:23 AM, Lennart Grahl <lennart.grahl@gmail.com> wrote:
> 
> 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.

[BA] Abstractions like sockets.io deliver the message to all room members but this happens on the server and is opaque to the application, simplifying the logic there. Without support for parallel forking, you would need to discover the Answerers first (1 RTT), then complete an O/A exchange (at least 0.5 RTT if piggybacked on discovery).

> I don't understand why that would result in faster connection establishment. Can you elaborate?

[BA] Gathering only occurs once, with a filtered candidate set. For example, a relay candidate can be offered, allowing media to ge started up immediately.

> 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?

[BA] Total sockets can be an issue on servers but typically not on clients.

> 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?

[BA] TURN mobility (supported in Ortc lib) enables IP address changes while minimizing media glitches via use of a relay. So it does not encounter this problem (which could be addressed while media is still flowing via an ICE restart).

> 3. Would this allow to reuse TURN allocations?

Yes.

Received on Sunday, 27 May 2018 19:46:05 UTC