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

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.

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
>