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

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

From: Adam Roach <adam@nostrum.com>
Date: Mon, 17 Dec 2012 13:18:53 -0600
Message-ID: <50CF701D.4040302@nostrum.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 12/17/12 12:57, Christer Holmberg wrote:
> 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?

They are not.

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

/a
Received on Monday, 17 December 2012 19:19:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 December 2012 19:19:20 GMT