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 <adam@nostrum.com> 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>