Re: DTLS-SDP and JSEP Conflicts

Hi,

So, does anyone *OBJECT* to the remove-ufrag-from-section-4 proposal? I
assume Justin and Cullen would be ok with it, since it is what JSEP does,
but it would still be nice to hear them say that :)

I assume we could still keep section 3.3, but we should remove the ³(see
Section 4)² part. Because, section 3.3 does not say that a ufrag change
triggers a new DTLS association, it simply says that if one changes the
ufrag AND wants to create a new DTLS association, the tls-id must be
changed.

We could also clarify section 3.3:

   "If an endpoint uses ICE, and modifies a local ufrag value, and if the
   modification requires a new DTLS association, the endpoint MUST
   change its local SDP 'tls-id' attribute value, <new> as a modification
of 
   the local ufrag value does not itself trigger a new DTLS association
</new>"

Regards,

Christer




From:  mmusic <[email protected]> on behalf of Taylor Brandstetter
<[email protected]>
Date:  Saturday 26 August 2017 at 02:32
To:  "[email protected]" <[email protected]>
Cc:  "[email protected]" <[email protected]>
Subject:  Re: [MMUSIC] DTLS-SDP and JSEP Conflicts


I think I'm just echoing Roman at this point, but might as well send the
email since I already wrote it.
 

(Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart?
The primary rationale outlined in RFC5245 for restarting ICE
 is changing the destination (IP address or port) of an ongoing media
stream -- which would commonly involve changing to a different physical
device.


The purpose of section 4 is to describe what should happen for an
"existing implementation that has not been updated to support the 'tls-id'
attribute", correct? And existing WebRTC implementations do not create a
new DTLS association upon ICE restarts.
 In my experience, ICE restarts are mostly used to restore connectivity
when network interfaces change, not to transfer a call to a new endpoint.
So I'd say the "ICE ufrag value" bullet in section 4 should be removed.


I hate to throw new engineering into the document at this point, but
shouldn't it be possible to distinguish between these two circumstances by
examining the candidates and determining whether they're completely
 new (versus having at least one in common with the existing connection)?
This means that you won't know whether to restart DTLS until
 trickling has ended (for trickle), but you can solve that by not doing
aggressive (or passive-aggressive) nomination -- just wait until you have
all the candidates before you start connecting.

Does that sound like it would work?


If I understand correctly, you're saying "wait until trickling has ended,
and use a new DTLS association if the list of candidates is completely
new, and old association if it contains an old candidate"? That doesn't
work for a couple reasons:

1. The list may be completely new, but the endpoint may still want to use
the existing DTLS association. This is what existing WebRTC
implementations do. They continue sending media over the old candidate
pair while they're doing an ICE restart, but they don't
 trickle the old candidate again.

2. It could take a long time to tell that trickling ended, which would
delay media. It would defeat a large part of the benefit of trickle ICE.




On Fri, Aug 25, 2017 at 4:28 PM, Adam Roach
<[email protected]> wrote:

On 8/25/17 6:23 PM, Roman Shpount wrote:

More importantly this is not how existing implementations work. They
simply do not start new DTLS association on ufrag change. This is for
legacy interop only, so we might as well do what legacy end points do and
ignore ufrag.




This seems pretty compelling, as arguments go.

/a

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