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