Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

2014-08-08 13:21 GMT+02:00 Kevin Dempsey <kevindempsey70@gmail.com>:
> Does the new TCP connection require an ICE restart? If so, then I think an
> new DTLS handshake (and fingerprint check) should be required as the server
> may not be connected to the same endpoint anymore.

Why is ICE restart required at all? We are stating that ICE is a
virtual socket regardless how many valid pairs (UDP or TCP) it
handles. The peer can send media (so also DTLS) over any of those
valid pairs at any time without requiring ICE restart (am I wrong?).

My scenario is a good example of how good ICE can be by itself,
without requiring "restart" or a new SDP O/A signaling. Upon TCP
disconnection there is no need to perform a new DTLS handshake since
the "ICE virtual socket" was still open and both Chrome and the server
have already agreed on which layer 4 tuples can be used to carry media
and DTLS stuff is done. Both peers should be able to change the valid
pair at any time without requiring signaling or ICE restart.

NOTE: Issue open in Chrome:
https://code.google.com/p/chromium/issues/detail?id=401923

> On 8 August 2014 11:49, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>>
>> 2014-07-31 21:08 GMT+02:00 Justin Uberti <juberti@google.com>:
>> > As discussed earlier, DTLS does not require a separate context for each
>> > tuple. DTLS should be agnostic about the lower layer protocol (and we
>> > should
>> > probably create an errata to resolve this confusion).
>>
>> Hi Justin, I agree with that (and I like that), but Chrome does not
>> behave in that way. My experiment:
>>
>> - The server gives a UDP and TCP candidate to Chrome.
>>
>> - Chrome nominates UDP (ICE stuff), sends the DTLS handshake and then
>> media.
>>
>> - Later the server closes its UDP socket, so STUN requests from Chrome
>> are not replied.
>>
>> - At some point Chrome decides to open a TCP connection with the TCP
>> candidate. It also sends ICE stuff (OK).
>>
>> - The problem: Chrome *sends* a new DTLS handshake over the new TCP
>> connection.
>>
>> This is wrong since the server already has a *working* and
>> *established* DTLS session (which as you say MUST be transport
>> agnostic), so the new DTLS HelloClient is ignored by the DTLS
>> machinery at server side and thus, media is never sent.
>>
>>
>> IMHO Chrome should not attempt a new DTLS handshake given that it was
>> already done before over the "ICE virtual socket". You opinion please?
>>
>> BTW: Let me know if you want me to open a bug report, but I would love
>> having this clear :)
>>
>>
>>
>>
>> --
>> Iñaki Baz Castillo
>> <ibc@aliax.net>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>

-- 
Iñaki Baz Castillo
<ibc@aliax.net>