Re: New spec: Restarting ICE

Hi Harald

talking about this next call, I want to say something.

In traditional LTE world, that UE can retain some bearer context and IP
addresses both in the network and devices, to save the time for setup IP
connection with network.

I have no concrete proposal, but why not peerconnection can has an idle
state, but must be closed after call finished? Especailly when you open an
webrtc page with your friend for a long talk (several hours?), you may put
peerconnection in idle state to save bandwidth and resources, and when you
click to call again, the peerconnection and restore from idle to connected
for very short time.

Just some thought on this, may not be correct.

On Mon, Jun 11, 2012 at 6:16 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> On 06/10/2012 04:20 PM, Cullen Jennings wrote:
>
>> 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.
>>
> Is there such a concept as "next call" in a PeerConnection?
>
> With "serial forking" by using PRANSWER, I take it we can have a
> PeerConnection pointing at multiple endpoints, but I have been making the
> assumption that once you enter the "closed" state, there is no way back.
>
> If you want to remember constraints on a next call, just create a new
> PeerConnection object and apply the constraints you want to it.
>
>
>
>
>>
>> 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.
>>>
>>
>>
>
>


-- 
Yang
Huawei