Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft

Hello,

On 23 Mar 2014 12:00 PM, "Parthasarathi R" <partha@parthasarathi.co.in>
wrote:
>
> Hi all,
>
> The below mentioned UPDATE overlap with INFO usecase and INFO forking
> scenario has to be clarified before adopting this draft as WG item as I'm
> not seeing any solution with INFO based mechanism.
>
> Thanks
> Partha
>
> > -----Original Message-----
> > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of
> > Parthasarathi R
> > Sent: Tuesday, March 18, 2014 5:25 AM
> > To: 'Emil Ivov'; 'Enrico Marocco (TiLab)'; 'Christer Holmberg'
> > Cc: mmusic@ietf.org
> > Subject: [MMUSIC] Comment on SIP Trickle based on INFO draft
> >
> > Hi all,
> >
> > SIP Trickle INFO is projected as the back channel for collecting the
> > candidates in IETF-89 MMUSIC meeting. Unfortunately, it impacts
> > Offer/answer
> > (RFC 3264) in case one another offer/answer started before SIP trickle
> > INFO
> > is completed.

I am still not sure why you think that and exactly what you have in mind.

> > The race condition between second offer/answer and
> > earlier SIP
> > trickle INFO is not stated in the draft-ivov-mmusic-trickle-ice-sip.

No, indeed it hasn't but it has been mentioned in discussions many times: a
new offer answer would generally cause an ICE restart.

> > I
> > have
> > explained those issues in
> > http://www.ietf.org/mail-archive/web/mmusic/current/msg12666.html and
> > no
> > reply from you folks.

I am sorry, I don't understand the mail you point to above. It says it
raises issues in 3264 situations but then refers to BUNDLE and UPDATEs.

If the scenario below is the one you are worried about, then I'll answer
there.

> > This race condition is very much possible during
> > early
> > dialog scenarios with UPDATE.
> >
> > Could you please explain how SIP trickle ICE using INFO works for
> >
> > 1) UPDATE from remote before Trickle ICE is completed

This is analogous to an UPDATE that is received before regular 5245 ICE
processing has completed.

> >     a) INVITE from local
> >     b) 183 session progress from remote
> >     c) PRACK from local
> >     d) INFO from local (relay candidates)
> >     e) UPDATE from remote
> >
> > Here, the remote has to consider whether INFO belongs to UPDATE or
> > INVITE as
> > it is possible for INFO to reach before 200 OK for UPDATE as well in
> > the
> > same sequence.

And CSeq headers wouldn't help here because ....?

> > Also, RFC 2976

which FWIW is obsoleted by RFC6086

> > clarifies that
> >
> > " - The extensions that use the INFO message MUST NOT rely on the
> >      INFO message to do anything that effects the SIP call state or the
> >      state of related sessions."

And I don't believe that it does.

> > But SIP Trickle ICE state is depend upon the "state of related
> > sessions" as
> > UPDATE would have change the state in the remote.

I am not sure what you are saying or why it is a problem.

> > 2) Trickle ICE INFO with serial forking

INFO requests are sent within a dialog. They will go through the prong
associated with that dialog and would not be forked.

> >   a) INVITE from local
> >   b) INVITE is forked by proxy to first remote destination
> >   c) 100 trying is reaching local
> >   d) INFO with Trickle ICE from local

No, this should't happen. We can't send the INFO before we have a dialog.

> >   e) INFO is forward by proxy to first remote destination
> >   f) INVITE is forked by proxy to second remote destination
> >   g) Whether INFO has to be forked?

See above.

> > It is not mentioned in the draft whether INFO has to be forked to the
> > second
> > remote destination as well. Could you please explain the expect
> > behavior for
> > this scenario.

I think the above commencts should answer your questions. We will make sure
we add those as clarifications before our next submission (hopefully as a
WG document)

Emil

> > Thanks
> > Partha
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>