[MMUSIC] UPDATE vs INFO for SIP Trickle ICE [was RE: Trickle ICE for SIP Questions]

Hi Emil & all,

I had gone through UPDATE vs INFO argument for SIP trickle ICE. As Trickle
ICE is candidate sharing only and also shall happen incrementally, so the
INFO based back channel mechanism was preferred. I have concern with SDP
back channel mechanism after the first O/A is complete as there are more
possibity for race conditions between INFO from UAS and UPDATE from UAC.
UPDATE from UAC is sent across for multiple reasons and  I'll list update
few of the scenarios which come to my mind immediately :

1) Bundle
2) ICE restart
3) Commit for the single codec after negotiation

INFO for trickle ICE leads to confusion due to race conditions between
UPDATE from UAC and un-ordered INFO from UAS. 

Also, it is not clear to me how media IP address as part back channel as it
is part of SDP O/A. In case SDP is designed to carry to media codec
negotiation & media IP address separately (like Jingle/H.245), back channel
mechanism works well 

Thanks
Partha 

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Emil Ivov
> Sent: Thursday, July 25, 2013 10:08 PM
> To: 'MMUSIC IETF WG'
> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
> 
> Hey Partha,
> 
> On 25.07.13, 17:48, Parthasarathi R wrote:
> > Hi Emil,
> >
> > In the mentioned situation, different To-tag with same contact header
> for
> > trickled SDP, So there will be no "N" locations.
> 
> Having the same contact header does not automatically suggest that this
> is somehow a fake fork (unless I am missing the text that says this in
> 3261). You could potentially have this if the fork is done by a B2BUA
> or
> a PSTN gateway for example.
> 
> > My reading of the draft is that this draft is not required in case
> UPDATE
> > (RFC 3311) method is supported. UPDATE with SDP will update trickle
> > candidate within 18x.
> 
> Use of UPDATE has already been discussed and we pretty much agreed not
> to go that way.
> 
> A mail from Alan and the preceding discussion:
> http://www.ietf.org/mail-archive/web/mmusic/current/msg10660.html
> 
> A follow up with a nice summary from Dale:
> http://www.ietf.org/mail-archive/web/mmusic/current/msg10678.html
> 
> > The aim of the draft is to support Trickle ICE for SIP user agent
> which does
> > not support RFC 3311 for last 11 years. AFAIK, different "to tag" is
> the
> > simpler way to solve the problem in UAS side. I have concern w.r.t
> INFO
> > mechanism as it adds one method for handling SDP and complicates the
> > existing SDP O/A handling (RFC 6337).
> 
> That's the thing, trickle ICE is not part of Offer/Answer. It's a
> separate channel for agent-to-agent communication. Use of SDP is just a
> convenient coincidence.
> 
> > Including Christer in this mail thread as he replied in the parallel
> mail
> > thread.
> 
> I believe he is on the list I don't think that's an issue :)
> 
> Cheers,
> Emil
> >
> > Thanks
> > Partha
> >
> >> -----Original Message-----
> >> From: Emil Ivov [mailto:emcho@jitsi.org]
> >> Sent: Thursday, July 25, 2013 2:19 AM
> >> To: Cullen Jennings (fluffy)
> >> Cc: Vijaya Mandava (vimandav); Parthasarathi R; Alan Johnston;
> MMUSIC
> >> IETF WG
> >> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
> >>
> >>
> >>
> >> On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote:
> >>>
> >>> On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav)
> >> <vimandav@cisco.com> wrote:
> >>>
> >>>> 180 with different to-tag would mean call is forked.
> >>>> If uac side do not support call forking, then we cannot use this
> 180
> >>>> response to collect trickled candidates.
> >>>
> >>> If it is a UAC, it supports this so I don't see the problem.
> >>
> >> One problem is that the UAC could support it to the extent of making
> it
> >> visible to the user:
> >>
> >>     "Your contact is being alerted on these N locations"
> >>
> >> And of course there's also the fact that we would be creating
> several
> >> dialogs per call, that we'd then need to clean and garbage collect.
> >>
> >> Why would we want to go there?
> >>
> >> Emil
> >>
> >> --
> >> https://jitsi.org
> >
> >
> 
> --
> https://jitsi.org
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic