- From: Christer Holmberg <christer.holmberg@ericsson.com>
- Date: Mon, 17 Dec 2012 20:08:15 +0000
- To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi, >>> 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. As the remote guy sent the additional candidates, it's obviously also his view of the state of the session. Especially if he has added them to his local SDP, and will include them in any future SDP sent by him. If the endpoints have different state of the session - especially state that is going to be used in the communication between the endpoints - I think things can get mesy. Regards, Christer
Received on Monday, 17 December 2012 20:08:41 UTC