fast peerconnection reconstruction?

> 
> During multi-parties conference call, we may setup peerconnection with
> multi-parties. For example, we may have 8 parties  in CC.
> 
> If our web page is refreshed, peerconnections with 8 parties will be
> reconstructed, and ICE candidates will be collected once more and ICE check
> will be carried out once more, it greatly reduce the user expericence due to
> long time restoration.

If the reason the user refreshed the page was the the NAT was rebooted, you need the ICE checks to be carried out. It seems like we need to think about the use cases for different scenarios and how to tell them apart - I agree that some of the time we want to reuse them but some of the time we don't. I think we need to figure out how to tell which of theses two case the browser is in when a refresh happens. 

> 
> So I suggest that can we have a mechanism for ICE storing in server, to let the
> ICE store in server and when web page refresh or communication drop, JS will
> fetch the "checked" ICE candidates from server, which will enable fast
> restoration.

A bunch of the security is premised on the JS not being able to set the ICE secrets so we would need to figure out a proposal that took that into account.

> 
> For example, we can add some parameter in IceCandidateCallback or some else, to
> let web app store the ICE candidates for fast restoration, it is optional, web
> app may choose implement it or not.

I don't see any problem with letting the JS get any of the ICE information so it can store it (it's all in the SDP anyways) but the hard part will be around what is allowed to be set and how that interacts with the ICE state machine.

Received on Thursday, 28 June 2012 17:59:41 UTC