Re: Presentation for a call if DTLS Association be started if not requested in the offer - ehterpad

Summarizing my proposal on today's call:

As an offerer:
If the answerer changes either {fingerprint, tls-id} then {
  if (!doing ICE restart) {
    error
  } else {
    do a new DTLS negotiation
  }
}

There is a race condition on the offerer if you are in ICE lite or
something where you might receive DTLS packets before the Answer. The
DTLS-SDP spec requires an ICE restart under these conditions, so you will
not be receiving anything from the old connection on the new 5-tuples.
Thus, you only need to disambiguate between: {RTP or SCTP on the current
DTLS association} and {ClientHello from the new association}. This can be
dealt with by (a) latching on the first thing that looks like it matches
one or the other pattern, i.e., it's either a ClientHello or it decrypts
successfully or (b) discarding everything until you get the answer, which
is something that happens automatically in most ICE scenarios.

As an answerer, JSEP implementations MUST NOT change the TLS-ID or the
Fingerprint unless the offerer sent a new TLS-ID

-Ekr



On Thu, Sep 28, 2017 at 5:00 PM, Christer Holmberg <
[email protected]> wrote:

> Etherpad for the meeting:
>
>
>
> https://etherpad.tools.ietf.org/p/dtls-sdp
>
>
>
> Everyone just volunteered to take notes :)
>
>
>
> Regards,
>
>
>
> Christer
>
>
>

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic