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

Probably, I am not sure if the trickle ICE update be linked with SDP Session Version at all.
 Since it doesn't fit in the realm of Offer-Answer Exchange rather than being by-product of the O/A exchange. So i would think, all the trickled candidates are appended to its appropriate media-stream internally on available and we don't need to update the SDP session-version.

Any thoughts ..

Cheers
Suhas
________________________________
From: Harald Alvestrand [harald@alvestrand.no]
Sent: Monday, December 17, 2012 11:51 AM
To: public-webrtc@w3.org
Subject: Re: SDP <sess-version> element and Trickle Ice

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