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