Re: [MMUSIC] Signaling trickle support

[Flemming Andreasen <[e-mail]>]

On 11/8/12 11:29 AM, Emil Ivov wrote:
> Hey Flemming,
>
> On 08.11.12, 10:53, Flemming Andreasen wrote:
>> On 11/8/12 10:46 AM, Martin Thomson wrote:
>>> Trolled.
>>>
>>> Though to be honest, I don't see a way around this particular problem.
>>>    The idea of using a Require: trickle header is fraught with problems;
>>> the idea that you might use an a= line doesn't give you the
>>> characteristics you desire.  I just don't know how to cause the
>>> failure that is needed when this isn't supported.
>> Can we capture the desired characteristics and failure mode for starters ?
> The "really" desired characteristic is knowing in advance whether or not
> the remote party can do trickle so that you know whether you can afford
> to send an empty offer without causing it to freak out.
Why would you send an empty offer ?

> Since protocols like SIP don't really have things like XMPP disco and
> Cap Neg that would have allowed it, we were considering other options.
> One such option would be to send a trickle offer and format it in a way
> that would cause a non-trickle answerer to reject it in a _predictable_
> way. This would allow the offerer to retry with a regular ICE offer.
I thought the point with trickle-ICE was to reduce call setup latency 
and hence you would want to make sure that things complete in as few 
round-trips as possible. This doesn't seem to line up with that (?).

>
>>> Besides, the failure modes all lead to an expenditure of time that is
>>> worse than the simple candidate gathering scenarios (reflexive,
>>> relay), though not "other" gathering methods (UPnP, etc...).
>> Is there a requirement here that needs to be written down ?
> The point that Martin is making is that sending an offer and then
> waiting for the failure may potentially take longer than just gathering
> your candidates. This is true especially in cases where the offerer is
> only planning on using a single port, on a single interface, with a
> single STUN/TURN server and no other candidate gathering mechanisms.
I would agree with that.
>
> But then, if this really is the case, the offerer knows it and can
> choose not to do the probing.
Agreed.
>>> half-trickle is a reasonable solution.
>> Sorry - what's half-trickle ?
> We had that in the slides on Tuesday but it's not yet in the draft. The
> idea is that if you can't confirm support for trickle in the answerer,
Do you mean: if you don't know if the answerer supports it before 
sending an offer to him [since confirming support in the answer should 
be easy]  ?
> you just send a vanilla ICE offer and you also indicate you do support
> trickle. A trickle ICE answerer can then trickle candidates and in
> general you get half the optimizations of Trickle ICE. You even get more
> than that in case the offerer is able to predictively gather candidates
> before the call is initiated.
Agreed.
>
> We'll describe this in the next version.
Ok - thanks for the explanation.

-- Flemming
>
> Cheers,
> Emil
>
>> -- Flemming
>>
>>
>>> On 8 November 2012 10:12, Emil Ivov <[e-mail]> wrote:
>>>> I actually think this was supposed to be a joke. At least that's how I
>>>> got it.
>>>>
>>>> Emil
>>>>
>>>> On 08.11.12, 10:01, Flemming Andreasen wrote:
>>>>> This is very different from the way we normally handle extensions in SDP
>>>>> both from a pure signaling and negotiation point of view. I share the
>>>>> sentiment of others that this does not look like a good idea but would
>>>>> like to understand if there were other considerations for suggesting
>>>>> this radically different approach.
>>>>>
>>>>> Thanks
>>>>>
>>>>> -- Flemming
>>>>>
>>>>> On 11/8/12 9:23 AM, Christer Holmberg wrote:
>>>>>> +1
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Miguel A. Garcia
>>>>>> Sent: 8. marraskuuta 2012 9:30
>>>>>> To: Paul Kyzivat; Martin Thomson; Emil Ivov
>>>>>> Cc: [e-mail]
>>>>>> Subject: Re: [MMUSIC] Signaling trickle support
>>>>>>
>>>>>> As an individual...
>>>>>>
>>>>>> I concur with Paul, changing the v= version in the SDP is a very bad idea.
>>>>>>
>>>>>> Let met quote RFC 4566:
>>>>>>
>>>>>>
>>>>>>        The "v=" field gives the version of the Session Description Protocol.
>>>>>>        This memo defines version 0.  There is no minor version number.
>>>>>>
>>>>>>
>>>>>> This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works.
>>>>>>
>>>>>> /Miguel
>>>>>>
>>>>>> On 07/11/2012 20:27, Paul Kyzivat wrote:
>>>>>>> On 11/7/12 8:59 AM, Martin Thomson wrote:
>>>>>>>> Matthew, Justin and I were discussing the problem of signaling
>>>>>>>> trickle ICE support and the following proposal was made:
>>>>>>>>
>>>>>>>> The 24th bit in SDP is currently set to zero.  This bit is
>>>>>>>> specifically reserved for forward compatibility purposes.  We can use
>>>>>>>> this bit.  Set this bit to one to indicate support for trickle ICE.
>>>>>>>>
>>>>>>>> This meets the "works if supported, fails if it doesn't criteria".
>>>>>>>>
>>>>>>>> This solution may also be appropriate for bundle/mmt/whatever.
>>>>>>> After some side discussion, I guess you are talking about bits in the
>>>>>>> value of the v= field ???
>>>>>>>
>>>>>>> If so, I still have no idea what you are talking about. The syntax for
>>>>>>> the value of v= is 1*DIGIT. You can choose to represent that in binary
>>>>>>> and then choose bit 24 if you want, but that has no significance in 4566.
>>>>>>>
>>>>>>> Assigning a new SDP version to signal Trickle ICE support seems like
>>>>>>> an incredibly bad idea.
>>>>>>>
>>>>>>>         Thanks,
>>>>>>>         Paul
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mmusic mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>
>>>>>> --
>>>>>> Miguel A. Garcia
>>>>>> [phone]
>>>>>> Ericsson Spain
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>> .
>>>>>>
>>>> --
>>>> https://jitsi.org
>>> .
>>>
>>