Message-ID: <526945F3.1060205@alum.mit.edu>
Date: Thu, 24 Oct 2013 12:08:19 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <00a401cece8b$7b00f780$7102e680$@co.in>	<CAPvvaaK3YOOB-Ta8+eoRcfQ8NrNRDdDf5a3VvOaN0vK=0unf7A@mail.gmail.com>	<00ce01cecf48$6c0b5500$4421ff00$@co.in>,
 <5266BB46.4070305@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>,
 <5266C0A7.5040305@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se>	<5266DAB0.7020001@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se>	<5267CA43.8020304@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se>	<5267E052.6020401@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4F0FED@ESESSMB209.ericsson.se>	<52692E69.8020109@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4F223D@ESESSMB209.ericsson.se>
 <369B690E-2456-48AD-923E-93B88A620817@vidyo.com>
In-Reply-To: <369B690E-2456-48AD-923E-93B88A620817@vidyo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on
 draft-ivov-mmusic-trickle-ice-sip-01
Precedence: list

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 <christer.holmberg@ericsson.com>
>   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.
>