Re: [MMUSIC] Signaling trickle support

[Emil Ivov <[e-mail]>]

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.

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.

>> 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.

But then, if this really is the case, the offerer knows it and can
choose not to do the probing.

>> 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,
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.

We'll describe this in the next version.

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
>> .
>>
> 
> 

-- 
https://jitsi.org