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

[Christer Holmberg <[e-mail]>]

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.

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

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

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

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.

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