Re: DTLS-SDP and JSEP Conflicts
Eric Rescorla <[email protected]> Mon, 4 Sep 2017 07:41:00 -0700
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CABcZeBM3m6Sdou5-VE6hjtdQpzC8sEpeSH1fUzauW68NqoSiog@mail.gmail.com> |
On Mon, Sep 4, 2017 at 7:37 AM, Paul Kyzivat <[email protected]> wrote: > On 9/4/17 6:14 AM, Christer Holmberg wrote: > > Now, based on your suggestion, if the offerer doesn¹t know whether the >>>> answerer supports tls-id, does that mean that the only way >>>> for the offerer to ensure that the re-offer will trigger a new DTLS >>>> association is by modifying the fingerprint set in the offer? >>>> >>> >>> That's true in any case, because we have implementations which behave >>> that way and we can't change them. >>> >> >> On GitHub you also suggested >> (https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the answerer, >> even if it supports tls-id, shall not be able to trigger a new DTLS >> association (read: change the tls-id value). I assume that means the >> answerer would not be able to change its fingerprint set either, or do >> anything else that would trigger a new DTLS association? >> > > Why would you want to *prevent* the answerer from triggering a new DTLS > association??? > As noted previously, it's confusing and it's only possible at all in the edge case where the offerer offers an ICE restart but not a new DTLS association. -Ekr Thanks, > Paul > > > _______________________________________________ > mmusic mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic