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

Hi,

>>I also think the sess-version value should be updated whenever the remote description changes.
>>
>> I am not sure I understand the need for using the timestamp. If SDP is not used on-the-wire, then the local JS app can update the remote description value however it wants.
>>
>> If SDP is used on-the-wire, then the remote entity shall update the sess-version value however it wants.
>
> The problem is that we cannot be authoritative for the remote sess-version. And while the recommendation is to use an NTP timestamp, the only actual requirement is that it increase whenever the session description changes.
>
> The degenerate case here is that we get an SDP from the remote party with a sess-version of 1.
>
> Then they send us a trickle ICE candidate.

I guess the assumption is that they are not sent in an SDP, right?

> 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.

Regards,

Christer

Received on Monday, 17 December 2012 18:57:33 UTC