Subject: Re: [Ice] Peter's review of ICEbis - Christer's input on the rest of Peter's comments

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 May 2017 07:08:47 +0000

Hi,

> - The spec says it's only defined for one TURN server and one STUN server but then it says what to do when more than one TURN server or STUN server is used.  I'm guessing we should remove the part about one TURN server rather than the other way around.
> - Since we won't have aggressive nomination, do we still need the "three-second rule" for when candidates can be freed?
> - The concept of using a Data Indication for a keepalive seems outdated.  In RTCWEB, consent freshness requires the use of binding requests, not data indications.    Should we change this?
> - What does the phrase "through good box and software security on TURN servers." mean?
> - Do we still need all the UNASF stuff?

I have currently no input on the comments above.

> - Should we keep this "send another candidate exchange when you're Complete" thing?  It looks like it's just there to
> let signaling servers learn something, which I think should be out of scope for this document.  Let a SIP document specify that.

Where is this text?

> - The one example in the doc uses aggressive nomination, which no longer exists.

We need to fix that.

> - Do our "changes from 5245" section need to be updated?

Yes...

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 01 Jun 2017 01:25:33 +0000

On Mon, May 29, 2017 at 12:08 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> > - The spec says it's only defined for one TURN server and one STUN
> server but then it says what to do when more than one TURN server or STUN
> server is used.  I'm guessing we should remove the part about one TURN
> server rather than the other way around.
> > - Since we won't have aggressive nomination, do we still need the
> "three-second rule" for when candidates can be freed?
> > - The concept of using a Data Indication for a keepalive seems
> outdated.  In RTCWEB, consent freshness requires the use of binding
> requests, not data indications.    Should we change this?
> > - Should we keep this "send another candidate exchange when you're
> Complete" thing?  It looks like it's just there to
> > let signaling servers learn something, which I think should be out of
> scope for this document.  Let a SIP document specify that.
>
> Where is this text?
>

Search for "updated candidate".  It's referred to about 4 times.  It might
only be for the case where one media stream fails and is thus removed.  Or
it might also be for peer reflexive candidates.

I'm just not sure why it's in this doc at all and not in a using protocol
doc.