Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01

[Emil Ivov <[e-mail]>]

Hey Christer,

On 24.10.13, 15:01, Christer Holmberg wrote:
> Hi,
>
>>>>> First, I completely messed up with the candidate types. Sorry
>>>>> for the confusion :)
>>>>>
>>>>> Anyway, it doesn't really matter what type of candidates are
>>>>> trickled - it's about whether trickled candidates can be
>>>>> affected by Offers/Answers.
>>>>
>>>> And by affected you really mean invalidated. OK, I think I
>>>> understand now.
>>>>
>>>> I don't think there's anything in 5245 that defines semantics
>>>> which would invalidate existing candidates.
>>>
>>> Generally, in SDP Offer/Answer, when an SDP attribute is not
>>> present, it means that it's invalidated, or the default value (if
>>> such has been specified) is assumed.
>>
>> What I meant was that 5245 explicitly states that all previously
>> signalled candidates MUST be signalled in updated Offers, so
>> candidate removal in the middle of ICE processing is not something
>> that is defined for ICE.
>>
>> Also, non-signalled candidates, like peer reflexive, are not
>> required to be signalled in update Offers, so their absence in an
>> offer cannot in any way be construed as a request for their
>> removal.
>
> So, IF we can define the same for trickled candidates, then there
> might not be an issue.

That's also my thinking (without the IF ;) ).

> We have to remember, though, that a trickled candidate is not a new
> candidate "type". The candidate types you trickle are the same types
> you send in Offer/Answer - tickle is simply an alternative candidate
> transport mechanism.

Yes, that's right. I am not sure why you are saying it though.

>>> But, that really depends on whether the candidates are considered
>>> part of the SDP state or not. IF so, trickled candidates would
>>> update that state, in the same way SDP Offers/Answers do.
>>
>> Right, and I've already mentioned that I don't see any reason to
>> consider them as part of the SDP state, just as you wouldn't
>> consider peer-reflexive candidates to be part of it.
>
> If a trickled candidate is eventually selected, doesn't a "clean up"
> SDP Offer have to be sent (as for any other non-default candidate),
> where the c- line is aligned with the candidate? In that case the
> candidate becomes part of the SDP state :)

As a result of the update offer, not as a direct result of trickle (just 
as with peer-reflexive candidates, which I seem to like repeating :) )

Emil

-- 
https://jitsi.org