W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2012

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

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Mon, 17 Dec 2012 18:57:06 +0000
To: Adam Roach <adam@nostrum.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <7594FB04B1934943A5C02806D1A2204B0689D2@ESESSMB209.ericsson.se>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 December 2012 18:57:33 GMT