RE: SDP <sess-version> element and Trickle Ice

Hi,

>>> If we are changing the sess-version of localDescription because we've added that candidate, then the smallest increase possible would be to change sess-version to 2.
>>>
>>> Now, imagine that the remote party, at some point in the future, sent us a new offer with a sess-version of 2.
>> Maybe I'm missunderstanding the issue, but don't we have that issue already today, without trickle ICE?
>>
>> Assume I send you an SDP offer, with candidates A, B and C, and sess-version 1. No trickle ICE - pure good old legacy ICE.
>>
>> Later, you receive a STUN reuqest which generates a peer-relexive candidate, candidate D, from me. You will now update your candidate list etc, but I don't think you are going to update the sess-version in the SDP offer I previously sent you.
>>
>
> Let's back up for a second. You are *familiar* with the remoteDescription attribute on the PeerConnection class, yes?

Yes. It returns the previously stored remote description, and any additional candidate(s) that have been added later.

And, to verify that I understand the issue correctly: the question is whether, whenever I add a candidate to the stored remote description, the sess-version should be incremented.

One question (my appologies if I've missed it in the trickle ICE discussion): whenever a new SDP offer IS received (for whatever reasons), will it also contain the trickle candidates that were not present in the previous SDP offer, but were later conveyed using some other mechanism?

Regards,

Christer

Received on Monday, 17 December 2012 19:43:35 UTC