Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

[Eric Rescorla <[e-mail]>]

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?

-Ekr



> As far as possible implementation options are concerned there are two
> possible solutions:
>
> a. Always require a new DTLS association whenever an offer is generated in
> the response to a request for a new offer (INVITE with no SDP in case of
> SIP). This will match ICE behavior where new ICE restart is required in
> such case. This is workable, but is excessive and will generate new DTLS
> association establishment when it is not required. This is why we preferred
> the currently described solution.
>
> b. Allow answering party to force a new DTLS association by changing
> dtls-id. This is something that will address third party call control case,
> since new end point will generate a new tls-id. This also removes unneeded
> DTLS associations if third party call control ends up connecting to the
> same end point (which happens more often then expected due to 3pcc agents
> doing connectivity checks).
>
> This is why I would strongly prefer to leave current specification as it
> is.
>
> Regards,
> _____________
> Roman Shpount
>
>