[MMUSIC] Comment on SIP Trickle based on INFO draft

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

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