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

[Paul Kyzivat <[e-mail]>]

I'm far from an expert on ICE, so maybe this is covered and I just don't 
know it...

ISTM there is a need for some real clarity about the relationship 
between ICE state and SDP O/A state, and if/when pieces of state move or 
are synchronized between them. This isn't clear even for SDP O/A on its 
own, but with ICE, and now with trickle ICE, and with Partial O/A it is 
becoming even more of a problem.

RFC 6337 started to clarify SDP O/A itself, but it didn't deal with the 
sorts of issues that are coming up in this discussion.

	Thanks,
	Paul

On 10/24/13 11:36 AM, Jonathan Lennox wrote:
>
> On Oct 24, 2013, at 10:34 AM, Christer Holmberg <[e-mail]>
>   wrote:
>
>> Hi,
>>
>>>> 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.
>>
>> Because when you say:
>>
>> 	"we treat trickle candidates in the same way as peer-reflexive candidates"
>>
>> ...it sounds like a trickle candidate is a new type of candidate (similar to peer-reflexive candidate), which is not true.
>>
>>
>> You should say:
>>
>> 	"We treat candidates that were provided using the trickle ICE mechanism in the same way as peer-reflexive candidates"
>
> There's a problem with this.
>
> RFC 5245 says:
>
>     However, the peer reflexive candidate is not paired with other remote
>     candidates.  This is not necessary; a valid pair will be generated
>     from it momentarily based on the procedures in Section 7.1.3.2.2.  If
>     an agent wishes to pair the peer reflexive candidate with other
>     remote candidates besides the one in the valid pair that will be
>     generated, the agent MAY generate an updated offer which includes the
>     peer reflexive candidate.
>
> In other words, peer-reflexive candidates aren't automatically paired with all remote candidates; they're only paired with the remote candidate you were checking when you discovered them, unless you send them in an updated offer.
>
> Candidates provided over Trickle don't have a remote candidate to be automatically paired with, so "treating them like peer-reflexive candidates" doesn't make much sense.
>