Re: DTLS-SDP and JSEP Conflicts

On Mon, Sep 4, 2017 at 9:16 PM, Roman Shpount <[email protected]> wrote:

> On Tue, Sep 5, 2017 at 12:03 AM, Eric Rescorla <[email protected]> wrote:
>
>>
>>
>> On Mon, Sep 4, 2017 at 8:48 PM, Roman Shpount <[email protected]> wrote:
>>
>>> 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.
>>>
>>
>> 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.
>

Well, to recap, ICE restart can only be initiated by the offerer:
https://tools.ietf.org/rfcmarkup?doc=5245#section-9.2.2

And as we discussed in detail, there's no real way to demux without an ICE
restart, so I'm not interested in trying to preserve that case in the
situations when it happens to work. In general, the offerer can simply
offer a new tls-id if it's willing to accept a new TLS connection. I
appreciate that this will also cause a TLS association even when the
endpoints haven't changed, but this just doesn't seem like that big a deal.

If you have a specific case in mind that this causes a problem for, I'd
need to see a call-flow diagram to understand it.

-Ekr


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

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