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

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

Hi Paul/Christer,

We are all in the same page that INFO is not forked and possible to be send
only within the dialg after receiving 18x response.

I have provided this example to clarify that "INFO" as a method does not any
advantage over "UPDATE" in sending SIP Trickle ICE fragments. In IETF-89
meeting, it was mentioned that INFO has advantage over other SIP methods. As
I mailed earlier, SIP Trickle ICE fragments has to send in any SIP method
within the dialog and particularly should be possible using "UPDATE" as
well. We can also discuss whether PRACK shall have SIP trickle ICE fragment
or not.

Thanks
Partha

> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of Christer
> Holmberg
> Sent: Thursday, April 03, 2014 1:30 PM
> To: Paul Kyzivat; [e-mail]
> Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft -
> FORKING
> 
> Hi,
> 
> That is what I tried to say :)
> 
> The INFO itself is not forked, but once you have multiple early dialogs
> you need to send INFO on all of them.
> 
> Regards,
> 
> Christer
> 
> Sent from my Sony Ericsson Xperia arc S
> 
> Paul Kyzivat <[e-mail]> wrote:
> 
> 
> Just to clarify: INFOs are never forked.
> 
> An INFO isn't sent until there is an early (or confirmed) dialog. And
> then each INFO is sent within a particular dialog. If the INVITE is
> forked, then *separate* INFOs can be sent, each in one of the dialogs.
> 
>         Thanks,
>         Paul
> 
> On 3/30/14 5:48 AM, Christer Holmberg wrote:
> > Hi,
> >
> >> 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.
> >
> > I am not sure what you mean by the INFO being forked.
> >
> > When a new fork is created (i.e. when the offerer receives a 18x
> response from a new destination), whatever candidates have been
> trickled on previously created fork(s) of course need to be provided
> also on the new fork.
> >
> > And, when multiple forks exist, whenever a new candidate is to be
> trickled, an INFO carrying the candidate needs to be sent on each fork.
> >
> > I don't see a problem with this, but if it is unclear in the spec
> then some additional text might be needed.
> >
> > Regards,
> >
> > Christer
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic