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

Hi,

Regarding the local description: I think the sess-version value should be updated when the SDP is changed.

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.

Regards,

Christer


From: Adam Roach [mailto:adam@nostrum.com]
Sent: 14. joulukuuta 2012 17:50
To: public-webrtc@w3.org
Subject: SDP <sess-version> element and Trickle Ice

I'm looking over the most recent version of the WebRTC spec, and think we need to be a bit clearer on the definition of localDescription and remoteDescription.

For localDescription, we describe the contents to be whatever was passed down in setLocalDescription " plus any local candidates that have been generated by the ICE Agent since then." Similarly, remoteDescription is described as whatever was passed down in setRemoteDescription "plus any remote candidates that have been supplied via addIceCandidate() since then."

Basically, this means that the WebRTC specification semantically treats trickle ICE operations as modifications to the session data.

Now, in RFC 4566, there is a stipulation that sess-version " is increased when a modification is made to the session data."

So, as a browser, I get a call to createOffer, and generate an SDP with a sess-version of 129517597601544000. Shortly after then, I get a setLocalDescription containing that same SDP. Now if the javascript checks localDescription, they should get back SDP with that same sess-version.

A bit later, I've gathered some ICE candidates and updated the local SDP with them. When the script checks localDescription, it will be *different* (since it contains these new local candidates). Should the sess-version in that SDP be 129517597601544000? Or should it be a larger number to indicate that the session information has changed?

As the whole point of the sess-version element is to allow shortcutting of reading through the entire SDP contents to find out whether any changes have taken place, I would argue that it should be different. And that's easy to take care of, since it's all our own SDP.

Where it starts to get tricky is when you consider the remoteDescription side. Since the sess-version's "usage is up to the creating tool," we can't be authoritative for the sess-version in the remote party's SDP.

It seems to me that we can resolve this one of four ways:

  1.  Leave the sess-version alone when new candidates are added to the SDP. If it cares, the web app will need to parse the entire SDP to find out whether any candidates have been added.
  2.  Simply increase the SDP sess-version by one whenever a new candidate is added. This is very hack-ish, but works as long as both parties follow the recommendation to use NTP timestamps.
  3.  Specify that WebRTC implementations MUST use NTP timestamps for their sess-versions, and change the SDP sess-version to the current NTP timestamp whenever a new candidate is added. This does run the risk of some races if the sess-version is updated by both sides simultaneously and/or there is significant time drift between their clocks.
  4.  Require that any new ICE candidates sent between implementations also contain a new SDP sess-version so that the SDP can be properly updated.

I don't like 2 or 3 very much, since there are some obvious ways in which they can go wrong. I'm not terribly fond of number 1, since it changes the semantics of RFC 4566 -- but it certainly seems to be the least disruptive path forward. Number 4 changes the API in a way that I don't expect we want to change it at the moment. In any case, this definitely needs to be made explicit in the specification. I'd hate to see implementations doing this differently, since applications could end up relying on one behavior and failing when they see another...

/a