- 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