Re: DTLS-SDP and JSEP Conflicts

On Mon, Sep 4, 2017 at 10:41 AM, Eric Rescorla <[email protected]> wrote:

>
>
> 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.
>
>
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.

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

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