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 14:00:59 -0600
Message-ID: <50CF79FB.2030106@nostrum.com>
To: Harald Alvestrand <harald@alvestrand.no>
CC: public-webrtc@w3.org
On 12/17/12 13:51, Harald Alvestrand wrote:
> On 12/17/2012 03:56 PM, Adam Roach wrote:
>> On 12/17/12 06:11, Christer Holmberg wrote:
>>> 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. 
>> 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.
>>
>> Whoops.
> If we follow the logic of "the RemoteDescription is a picture of what 
> the browser's view of the state of the session is, not what the remote 
> guy sent us", the logical sess-version is 1.0001, not 1.
>
> Yes, that's not a value allowed by the SDP spec. And that's an advantage.

Are you proposing that we use that syntax (or one substantially similar 
to it) in order to address this situation?

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

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