Re: [MMUSIC] Trickle ICE for SIP Questions

Hi,

Two different UASs could have the same Contact value, if they e.g. are located in private networks.

Of course, you could use the instance-id, but then we would need to require support of that extension...

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Parthasarathi R [partha@parthasarathi.co.in]
To: &apos;Emil Ivov&apos; [emcho@jitsi.org] &apos;MMUSIC IETF WG&apos; [mmusic@ietf.org]
Subject: 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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic