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

[Emil Ivov <[e-mail]>]

On 23.10.13, 16:06, 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.

> You could of course argue that, if a candidate has never been carried in an SDP Offer/Answer to begin with, SDP Offer/Answers should have no impact on it.

Yes, that's exactly what I'd argue since this is pretty much what 5245 
says (I say "pretty much" because it doesn't explicitly state it for 
trickle, but the general case matches).

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

> My point is that these things need to be clearly clarified.

I also agree that a clarification would be helpful (especially a clear 
one ;) ). It's easy to get lost in all this.

>>>>> So, that would mean that if an Offer is received without the peer
>>>>> refexive candidates, the answerer would remove them.
>>>>
>>>> You lost me. How would an answerer remove candidates from an offer if
>>>> they weren't there in the first place? Did you mean to say something
>>>> else?
>>>
>>> I referred to the example below, where an Offer does not contain a
>>> candidate that was previously trickled, and whether the answerer will
>>> then assume that the candidate is no longer valid.
>>
>> Right. I don't think there's such a risk. 5245 explicitly forbids update Offers and Answers to remove candidates that have been announced previously and it allows (as in MAY, not SHOULD) that new candidates be added.
>>
>> The former should address your concern and I believe we could simply remove the latter as it is of little use, if any.
>
> Well, then there is of course a risk that the receiver of the Answer
> will trigger an error, as the trickled candidate is not included in
> the Answer (as the Answer was sent before the candidate was trickled
> :)

Lost me again. I think some ascii art or a web sequence diag [0] would 
be very helpful here. Want to give it a try?

Or we could continue this discussion once we have the specific cases in 
the new version of the draft. Hopefully it would be easier that way.

Emil

[0] WebSequenceDiagrams: https://www.websequencediagrams.com/

>
> Regards,
>
> Christer
>

-- 
https://jitsi.org