Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.]

[Ted Hardie <[e-mail]>]

On Thu, Feb 7, 2013 at 11:09 AM, Flemming Andreasen <[e-mail]> wrote:
>  If that weren't the case, you'd have to keep open the
>> possibility that more candidates might come in.
>
> The above would seem to favor an explicit indication.
>
>
>> But I think I've been thinking of this the other way around--if both
>> sides are known to support trickle-ICE, the client sends
>> a=end-of-candidates whenever it's done *even if that is on the first
>> candidate set sent*.
>
> Not sure I follow - this would terminate trickle-ICE prematurely, no ?
>
It would terminate it, but not prematurely.  The client sends
a=end-of-candidates whenever it's done sending candidates; it just
allows you to send that indicator if you already had the full list on
the first use.  So if it did the blocking version of candidate
gathering, it sends that as the indicator that it is done.

>
>> Perhaps that is "vanilla ICE with sprinkles",
>> but it seems to solve the problem without another indicator/round of
>> negotiation.  As you note, that may overload the the ice-option
>> semantics, but it seems likely to work reasonable well.
>
> I don't think it does since it would seem to terminate trickle-ICE
> prematurely, but maybe we should wait for the authors to clarify.
>

Well, I'd certainly be happy to have the authors or others chime in.
But I am personally okay with the presumption that you always use
Trickle-ICE if Trickle-ICE is available at both ends, because it is
easy to get Vanilla ICE semantics using Trickle-ICE syntax.  I agree,
though, that this overloads the ice-option.

regards,

Ted Hardie