- From: Justin Uberti <juberti@google.com>
- Date: Fri, 1 Jun 2012 16:40:55 -0400
- To: public-webrtc@w3.org
- Message-ID: <CAOJ7v-0WPhz1wuBDPomhysue1jkHUHOKNTRiyss5dZNeuUF7jQ@mail.gmail.com>
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.
Received on Friday, 1 June 2012 20:41:45 UTC