Re: [MMUSIC] Trickle ICE for SIP Questions

Hi Emil,

Please read inline.

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.
> 
<Partha>The discussion is not about fake fork. The contact indicates
location of the UAS. In case of PSTN & B2BUA as UAS, PSTN & B2BUA contact
SIP URI is the location for UAC. From the UAC perspective, there is no "N"
location in UAS due to fake forking as you expect.</Partha>

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

<Partha> Sorry for the delay discussion. I'm still seeing few aspects  
Missing from the discussion. I'll write the separate mail thread for this
</Partha> 

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