Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

[Roman Shpount <[e-mail]>]

On Tue, Sep 5, 2017 at 12:03 AM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Mon, Sep 4, 2017 at 8:48 PM, Roman Shpount <[e-mail]> wrote:
>
>> On Mon, Sep 4, 2017 at 10:41 AM, Eric Rescorla <[e-mail]> wrote:
>>
>>>
>>>
>>> On Mon, Sep 4, 2017 at 7:37 AM, Paul Kyzivat <[e-mail]>
>>> 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.
>>>
>>>
>> The main reason new DTLS association can started by the answering party
>> is third party call control. The new DTLS association will be required if
>> as a result of the offer/answer exchange two new end points ends up being
>> connected with each other by a third party call control agent. This is a
>> fairly common scenario. If it is not supported interoperability with
>> existing implementations will be seriously affected. Please note that in
>> existing specification new DTLS association can already be started by the
>> answerer changing fingerprints, transport parameters, or setup role.
>>
>
> Well, as has been noted, the current specification is fairly unclear (I
> feel comfortable saying that as one of the authors), but as a practical
> matter, this only works if you already are doing an ICE restart. Is that
> what is happening in this instance?
>
>
Current specification is not very specific about ICE. It does allow
answerer to start a new DTLS association even if ICE restart is not
initiated. I am not sure how this will work in all the cases, but it
definitely works for third party call control, which, as far as I am
concerned, is the only useful use case of answerer triggering a new DTLS
association. ICE restart is required in case of the new offer generated in
response to INVITE with no SDP. Because of this, answerer can successfullu
establish a new DTLS association by changing fingerprints. And, since
answerer is a new end point, ICE candidate pair nominated for transport
will end up to be a new distinct 5-tuple so new and old DTLS associations
can be easily demuxed. So, in some sense, current specification works
almost by accident.

I would really like for this to continue to work since this is being used.

Regards,
_____________
Roman Shpount