Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

On Mon, Sep 4, 2017 at 7:37 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>