Nitpick: I propose it be called "IceRestart", for consistency with the existing "IceTransports". On Wed, Apr 3, 2013 at 2:20 AM, Harald Alvestrand <harald@alvestrand.no>wrote: > Hello folks, > > speaking as contributor: > I believe we now have all the pieces we need to restart ICE properly, > except for one little detail. Can we get this in, and close the book on ICE > restart? > > What's in: > > - under setLocalDescription: "If a local description contains a different > set of ICE credentials, then the ICE Agent must trigger an ICE restart." > .... " If the local description was set with content that caused an ICE > restart, then set connection's ice gathering state<http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection-ice-gathering-state> > to gathering." > > - in the description of the RTCIceConnectionState Enum: "(any state, ICE > restart occurs): new" > > The only remaining challenge is to get a local description with a > different set of ICE credentials. > Since SDP mangling is just so last year, I suggest adding a constraint to > the list in section 13.1 "Constraints": > > RestartIce - this is an enum type constraint that can take the values > "true" and "false". The default is a non-mandatory "false". > When the value of the constraint is mandatory "true", the generated > description will have ICE credentials that are different from the current > credentials (as visible in the localDescription attribute's SDP). Applying > the generated description will restart ICE. > When the value of the constraint is mandatory "false", and the > localDescription attribute has valid ICE credentials, the generated > description will have the same ICE credentials as the current value from > the LocalDescription attribute. > When the constraint is optional, the implementation may choose to generate > new credentials or not based on other criteria. > > If this is non-controversial, can we "just add it"? > If it is controversial - what's the controversy? > > Harald > > > > >Received on Wednesday, 3 April 2013 23:23:48 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:42 UTC