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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 17 Dec 2012 20:51:40 +0100
Message-ID: <50CF77CC.1080407@alvestrand.no>
To: public-webrtc@w3.org
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.

>
> /a
Received on Monday, 17 December 2012 19:52:11 GMT

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