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

["Parthasarathi R" <[e-mail]>]

Hi Emil,

 

Please read inline for more comments.

 

Thanks

Partha

 

From: Emil Ivov [mailto:[e-mail]] 
Sent: Sunday, March 23, 2014 5:24 PM
To: Parthasarathi R
Cc: mmusic; Christer Holmberg; Enrico Marocco (TiLab)
Subject: RE: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft

 

Hello,

On 23 Mar 2014 12:00 PM, "Parthasarathi R" <[e-mail]>
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:[e-mail]] On Behalf Of
> > Parthasarathi R
> > Sent: Tuesday, March 18, 2014 5:25 AM
> > To: 'Emil Ivov'; 'Enrico Marocco (TiLab)'; 'Christer Holmberg'
> > Cc: [e-mail]
> > 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.

<Partha> As I mentioned in the another mail thread
(http://www.ietf.org/mail-archive/web/mmusic/current/msg13267.html)
offer/answer is impacted in case SIP ICE trickle INFO has to be implemented
</Partha>

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

<Partha> INFO & UPDATE example is one of the example for this discussion.
</Partha>

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

<Partha> Sorry in case BUNDLE confused the discussion. The main point is
that how 3264 offer/answer impacted by this INFO based Trickle ICE proposal.
Also, the mail thread points out the limitation in RFC 3264 to adapt Trickle
ICE. </Partha>

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.

<Partha> No, in case UDPATE before the offer is completed, 491 response will
send out whereas it will not happen in case of INFO </Partha>

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

<Partha> Thanks..I still majorly interwork with RFC 2976 implementation :-(
but please note that RFC 6086 does not change much in these SIP dialog or
session aspects. The exact snippet of RFC 6086 is as follows:

"Note that the INFO method is not used to update characteristics of a

   SIP dialog or session, but to allow the applications that use the SIP

   session to exchange information (which might update the state of

   those applications)."

 </Partha>

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

<Partha> No, it is not possible to implement this draft without impact
offer/answer state machine </Partha>

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

<Partha> By now, you would have realized that how offer/answer "o" line has
dependency in INFO trickle ICE </Partha>

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

<Partha> IOW, Trickle ICE INFO will be buffered till 18x response is
received. So, INFO has no much advantage compare to UPDATE except for the
non-reliable response scenario. Please note that INFO is not possible to be
handled 491 scenario wherein offer/answer is impacted </Partha>

> >   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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
>