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

[Jonathan Lennox <[e-mail]>]

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.

-- 
Jonathan Lennox
[e-mail]