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

On 12/14/2012 10:15 PM, Adam Roach wrote:
> 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.
Actually I'm not sure the remoteDescription matters, because there 
should be no circumstance (except for debugging) when an application 
sends the remoteDescription to another entity and asks that remote 
entity to take action on it. Certainly there is no such expectation in 
RFC 3264.
(a possible exception is storage of remote state for rehydration, if we 
need that - but in this case, we're talking to a future version of 
ourselves, via a non-standardized interface, so compatibility is less 
critical.)

If we interpret remoteDescription as "an SDP-formatted description of 
the current remote configuration", and not as "a protocol object for 
transmission to a compatible entry", it doesn't matter which way we 
resolve this conflict.

For the localDescription, by contrast, we're already seeing code that 
assumes that one can take the localDescription and send it, exactly so 
that the extra candidates can be included - I'd think that counting up 
the version number by one (solution 2) for each added candidate makes 
sense here.

>
> 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
>