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

[Emil Ivov <[e-mail]>]

Hey Christer,

On 23.10.13, 12:25, Christer Holmberg wrote:
> Hi Emil,
>
> First, I completely messed up with the candidate types. Sorry for the
> confusion :)
>
> Anyway, it doesn't really matter what type of candidates are trickled
> - it's about whether trickled candidates can be affected by
> Offers/Answers.

And by affected you really mean invalidated. OK, I think I understand now.

I don't think there's anything in 5245 that defines semantics which 
would invalidate existing candidates.

I do agree that we could further clarify this in 5245bis and/or Trickle 
for SIP.

>>> So, that would mean that if an Offer is received without the
>>> peer refexive candidates, the answerer would remove them.
>>
>> You lost me. How would an answerer remove candidates from an offer
>> if they weren't there in the first place? Did you mean to say
>> something else?
>
> I referred to the example below, where an Offer does not contain a
> candidate that was previously trickled, and whether the answerer will
> then assume that the candidate is no longer valid.

Right. I don't think there's such a risk. 5245 explicitly forbids update 
Offers and Answers to remove candidates that have been announced 
previously and it allows (as in MAY, not SHOULD) that new candidates be 
added.

The former should address your concern and I believe we could simply 
remove the latter as it is of little use, if any.

>>> The issue that can occur is if you:
>>>
>>> - first send an Answer (to an Offer), without candidate X;
>>>
>>> - then you send a trickle request with candidate X;
>>>
>>> - the trickle request reaches the remote endpoint BEFORE the
>>> Answer.
>>
>> We agreed that the answerer would either wait for a PRACK or an
>> INFO with end-of-candidates before starting trickling, so I don't
>> think this can happen.
>
> But, in the example above the Offer, and the Answer, may not contain
> any new candidates, the Answer simply contains a list of previously
> negotiated candidates. I don't think there will be an INFO with
> end-of-candidates in that case, or a PRACK (in case the Offer was
> received in an UPDATE, or in a POF).

Yes, maybe not. This would be a non-restarting update Offer and we could 
specify that such offers (and their answers) don't get to change ICE. 
Only ICE restarts do.

> Anyway, once some rules regarding WHEN candidates can be trickled, it
> may be easier to point on concrete issues (if any).

OK.

> It would also be easier to explain the issues with a whiteboard :)
>
>> I think I do but I am not sure. Why would you consider lack of a
>> candidate as an indication that a candidate needs to be removed if
>> including that candidate was a MAY in the first place?
>
> Again, IF we say that trickled candidates MAY be present in
> Offers/Answers, and will not be removed in case they are not present,
> then there should be no issue.

OK, agreed.

Emil

>
> Regards,
>
> Christer
>
>
>
>
>
>>>> 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/> <https://jitsi.org/>
>>
>> -- https://jitsi.org <https://jitsi.org/>
>>
>
> -- https://jitsi.org
>

-- 
https://jitsi.org