- From: Cullen Jennings <fluffy@cisco.com>
- Date: Sun, 10 Jun 2012 10:20:03 -0400
- To: Justin Uberti <juberti@google.com>
- Cc: public-webrtc@w3.org
I think we need to look at how constrains get merged form one call to the next. If the browser remembers any previous constrains in the peerConnectionObject, this might mean the next call that passes in constraints needs to remember set { "restarts":false } to clear the previous value.
I suspect something like this could be made to work but a few more details are needed on constraints.
On Jun 1, 2012, at 16:40 , Justin Uberti wrote:
>
> Regarding updateIce():
> void updateIce (optional 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 Sunday, 10 June 2012 14:20:24 UTC