Re: New spec: Restarting ICE

This seems simplify the inferface and make still possible for ice restart
by adding a new parameter to createOffer().

But updateice has a parameter called configuration may correlate with
stun/turn server configuration, if no updateice, where we can change the
server configuration in createOffer or any others?

It seems only call a new peerconnection constructor to change it?



On Sat, Jun 2, 2012 at 4:40 AM, Justin Uberti <juberti@google.com> wrote:

> Regarding updateIce():
>
> void updateIce <http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-PeerConnection-updateIce-void-IceServers-configuration-MediaConstraints-constraints-Boolean-restart-false> (optional IceServers <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-IceServers> configuration,   optional MediaConstraints constraints,   optional Boolean restart=false);
>
> RFC 5245 makes it clear that an ICE restart is triggered by choosing a new ICE ufrag/pwd combintation. Therefore, it seems logical to me that an application should restart ICE by creating a new offer with a new ufrag/pwd and installing it via setLocalDescription. This offer could either be generated manually, by munging the ice-ufrag/pwd fields in the output of createOffer, or by creating a new constraint/hint which indicated that a new ufrag/pwd should be generated.
>
> In other words, we get a calling sequence like:
>
> createOffer(function(sdp) { setLocalDescription/sendOffer; }, null, { "restartIce": true });  // restarts ICE and notifies remote side
>
> instead of
>
> updateIce(old_config, old_constraints, true);  // restarts ICE state machine
> createOffer(function(sdp) { setLocalDescription/sendOffer; }, null, null );  // notifies remote side that ICE is restarting
>
> and the need for a restart function parameter to updateIce is removed.
>
>


-- 
Yang
Huawei