- From: Adam Roach <adam@nostrum.com>
- Date: Mon, 17 Dec 2012 13:18:53 -0600
- To: Christer Holmberg <christer.holmberg@ericsson.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 12/17/12 12:57, Christer Holmberg wrote: > 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. > I guess the assumption is that they are not sent in an SDP, right? They are not. > >> 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. > Maybe I'm missunderstanding the issue, but don't we have that issue already today, without trickle ICE? > > Assume I send you an SDP offer, with candidates A, B and C, and sess-version 1. No trickle ICE - pure good old legacy ICE. > > Later, you receive a STUN reuqest which generates a peer-relexive candidate, candidate D, from me. You will now update your candidate list etc, but I don't think you are going to update the sess-version in the SDP offer I previously sent you. > Let's back up for a second. You are *familiar* with the remoteDescription attribute on the PeerConnection class, yes? /a
Received on Monday, 17 December 2012 19:19:20 UTC