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:31, Christer Holmberg wrote:
> Hi,
>
>>> IF we consider trickle candidates as being identical to server reflexive
>>
>> You mean peer reflexive, right?
>
> Yes.
>
> But, that actually makes me wonder. Because, I DO believe that peer
> reflexive candidates actually ARE sent in SDP Offers/Answers (server
> reflexive candidates obviously aren't). At least I couldn't any text in
> 5245 indicating otherwise.

Mmmmm .... I am not sure I am following. Server reflexive candidates ARE 
signalled in offer/answer with vanilla ICE. That's how agents learn 
about them.

Peer reflexive candidates MAY be signalled with an updated offer. There 
is no requirement to do this, it can't be relied upon and the benefit is 
limited, if any. The implementations that I am aware of don't do it and 
I believe that, especially with trickle, we can easily update 5245bis 
not to include this.

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

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

> The
> trickle request will add the candidate, but then the Answer will remove
> it (as it does not contain candidate X).
>
> Do you understand what I mean? :)

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?

I think that in 5245bis we could easily limit offer/answer updates to 
only impact ICE in two ways (which I believe is how current 
implementations work anyway):

1. None: ICE ufrag and pwd are the same and the offer only includes the 
candidates currently in use. (i.e. the O/A was performed for some other 
session modification)
2. ICE Restart: ICE ufrag and pwd are different and this is a complete 
reinitialization of ICE processing.

How does that sound?

Emil


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

-- 
https://jitsi.org