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

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