Re: [MMUSIC] Faster ICE by role reversal?

[Dan Wing <[e-mail]>]

On Jul 30, 2014, at 4:05 PM, Jonathan Lennox <[e-mail]> wrote:

> 
> On Jul 30, 2014, at 7:00 PM, Martin Thomson <[e-mail]> wrote:
> 
>> On 30 July 2014 15:56, Jonathan Lennox <[e-mail]> wrote:
>>> The offerer can’t send its own connectivity checks until it receives an answer, because it needs the remote ufrag and password.  Without this, it doesn’t have any valid pairs, and so can’t send any media.
>> 
>> Of course.  But you could do all the computation necessary for
>> generating the ServerHello and accompanying messages (which in TLS 1.3
>> is quite a bit).
>> 
>>> This suggestion might still save half an RTT, though? I’d need to work through a full ladder diagram to figure it out.
>> 
>> That's the idea.  I haven't plotted it all out either, but I think
>> that this is the fastest possible start assuming that you don't send
>> any DTLS messages prior to getting a successful connectivity check
>> response.
> 
> Actually, if the answerer (controlled endpoint) can send on any Valid pair, as in my suggestion, I don’t think you need the ICE role reversal for this optimization.  It can send ClientHello as soon as its first check succeeds, despite never having received any remote checks (with or without USE-CANDIDATE).

Yep, ICE allows sending media once the pair becomes Valid  (middle of page 69, http://tools.ietf.org/html/rfc5245#page-69).  It is very reasonable that ClientHello is permitted to be sent to a Valid pair, too.

Towards the desire to remove a round trip, has there been consideration to folding the STUN messaging into the ClientHello?

-d