Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01

[Emil Ivov <[e-mail]>]

On 22.10.13, 20:04, Christer Holmberg wrote:
> Hi,
>
> IF we consider trickle candidates as being identical to server reflexive

You mean peer reflexive, right?

> candidates, I am not sure whether there is a risk of an O/A glare.

I don't think so either.

> Because, we don't signal server reflexive candidates in O/A either, do we?
>
> If so, then I assume that Offers and Answers would have no impact on
> trickle candidates (unless, of course, there is an ICE restart). Or?

Yes, I believe that's the way to go. We might need to state this 
explicitly in 5245 in order to avoid confusion.

Emil

>
> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
> *From:* Emil Ivov [[e-mail]]
> *Sent:* Tuesday, 22 October 2013 8:52 PM
> *To:* Parthasarathi R
> *Cc:* Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
> *Subject:* Re: UPDATE mechanism for Trickle ICE - Comment on
> draft-ivov-mmusic-trickle-ice-sip-01
>
> On 22.10.13, 19:01, Parthasarathi R wrote:
>> Emil,
>>
>> In case of ICE Trickle handling in SIP (based on RFC 3261), glare is
>> unavoidable
>
> I don't think this is true.
>
>> as per RFC 3264 offer/answer mechanism. The glare handling has
>> to be done by SIP provided mechanism like 491 handling in UPDATE/RE-INVITE.
>> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE compliant
>> SIP UA and no need of extra extension.
>
> Yes, there is a well defined mechanism for handling glare with 3264.
> With that I agree. (Adoption and implementation levels are a different
> story but let's not worry about that right now.)
>
> The thing is that this mechanism would be hugely inefficient for
> trickle. The likelihood of glare occurring even more than once there is
> extremely high when using UPDATEs.
>
> You are actually quite likely to make the whole process even longer than
> Vanilla ICE so unless your purpose is to make Trickle pointless, I don't
> think this is a good idea.
>
>> INFO based mechanism fails to identify the actual glare situation in
>> offer/answer.
>
> I think you might have misunderstood the way trickle ICE works with INFO.
>
> Once the initial offer/answer is complete (and those rely on the regular
> glare handling, independently of trickle or ICE) there are no additional
> offers and answers.
>
> INFO requests transport asynchronous signalling between ICE agents (NOT
> offers and answers) and it is perfectly fine for either party to be
> sending them at any point in time. There's no possibility of glare here.
>
> Does this help clarify things?
>
> Emil
>
>
>> Of course,  it is possible to reduce the trickle ICE glare handling with
>> special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE in case
>> both endpoints supports the mechanism.
>>
>> Please read inline for more comments.
>>
>> Thanks
>> Partha
>>
>>
>>
>>> -----Original Message-----
>>> From: Emil Ivov [mailto:[e-mail]]
>>> Sent: Tuesday, October 22, 2013 6:39 AM
>>> To: Parthasarathi R
>>> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic
>>> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-
>>> mmusic-trickle-ice-sip-01
>>>
>>> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R
>>> <[e-mail]> wrote:
>>>> Hi all,
>>>>
>>>> I have mailed earlier why SIP INFO is not the right choice for
>>> Trickle ICE
>>>> in
>>>>http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.
>>>
>>> I remember. Have you noticed my answer?
>>>
>>>http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html
>>>
>>
>> <Partha> Please note that my question is after your answer (msg11964 >
>> msg11932). </Partha>
>>
>>>> The main
>>>> reason is the glare handling. I have added the callflow in Sec 6.4 of
>>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will
>>> look for
>>>> Trickle ICE handling in SIP w.r.t JSEP mapping.
>>>
>>> I am confused. You say that your main issue is glare handling and yet
>>> your draft proposes a solution that *introduces* glare (through
>>> crossing UPDATEs) and then doesn't say anything about handling it. Is
>>> this intentional? Am I missing something?
>>>
>>
>> <Partha> 491 is the only known glare handling. We shall work and further
>> enhance glare handling in UPDATE/RE-INVITE as it is obvious glare situation.
>> I wish to confirm that INFO mechanism does not work for this situation
>> before deep diving. </Partha>
>>
>>>> Could you please explain how
>>>> glare with Trickle ICE Info package will be handled.
>>>
>>> That's simple. Glare does NOT occur when trickling through INFO.
>>
>> <Partha> The actual glare situation will be missed in INFO </Partha>
>>
>>>
>>> Emil
>>>
>>> --
>>>https://jitsi.org <https://jitsi.org/>
>>
>>
>
> --
> https://jitsi.org <https://jitsi.org/>

-- 
https://jitsi.org