From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: UPDATE mechanism for Trickle ICE - Comment on
 draft-ivov-mmusic-trickle-ice-sip-01
Thread-Index: Ac7Oi3Z+e3UP57hvROCS8x6y31/feAAJw8IAACFHcIAAAcFGAAAEeh/hAAAm54r//+FhgIAAIpUB///8bUCAAAAHAP/+8S7AgAIsaoD//9DwgA==
Date: Wed, 23 Oct 2013 14:06:06 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se>
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>
In-Reply-To: <5267CA43.8020304@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 'mmusic' <mmusic@ietf.org>
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on
 draft-ivov-mmusic-trickle-ice-sip-01
Precedence: list

Hi,

>> First, I completely messed up with the candidate types. Sorry for the=20
>> confusion :)
>>
>> Anyway, it doesn't really matter what type of candidates are trickled
>> - it's about whether trickled candidates can be affected by=20
>> 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 me=
ans that it's invalidated, or the default value (if such has been specified=
) is assumed.

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.

But, that really depends on whether the candidates are considered part of t=
he SDP state or not. IF so, trickled candidates would update that state, in=
 the same way SDP Offers/Answers do.

My point is that these things need to be clearly clarified.

>>>> So, that would mean that if an Offer is received without the peer=20
>>>> refexive candidates, the answerer would remove them.
>>>
>>> You lost me. How would an answerer remove candidates from an offer if=20
>>> they weren't there in the first place? Did you mean to say something=20
>>> else?
>>
>> I referred to the example below, where an Offer does not contain a=20
>> candidate that was previously trickled, and whether the answerer will=20
>> 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 remo=
ve 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 t=
rigger an error, as the trickled candidate is not included in the Answer (a=
s the Answer was sent before the candidate was trickled :)

Regards,

Christer