Re: [MMUSIC] Trickle ICE for SIP Questions

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

Hi Emil,

In the mentioned situation, different To-tag with same contact header for
trickled SDP, So there will be no "N" locations. 

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. 

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

Including Christer in this mail thread as he replied in the parallel mail
thread.

Thanks
Partha

> -----Original Message-----
> From: Emil Ivov [mailto:[e-mail]]
> 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)
> <[e-mail]> 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