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

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. The race condition between second offer/answer and
> earlier SIP
> trickle INFO is not stated in the draft-ivov-mmusic-trickle-ice-sip. I
> have
> explained those issues in
> http://www.ietf.org/mail-archive/web/mmusic/current/msg12666.html and
> no
> reply from you folks. 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
> 
>     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. Also, RFC 2976 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."
> 
> But SIP Trickle ICE state is depend upon the "state of related
> sessions" as
> UPDATE would have change the state in the remote.
> 
> 2) Trickle ICE INFO with serial forking
> 
>   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
>   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?
> 
> 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.
> 
> Thanks
> Partha
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic