Re: [MMUSIC] Trickle ICE for SIP Questions

[Emil Ivov <[e-mail]>]

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

-- 
https://jitsi.org