On Tue, Feb 14, 2012 at 4:23 AM, Harald Alvestrand <harald@alvestrand.no>wrote: > On 02/13/2012 09:00 PM, Suhas Nandakumar (snandaku) wrote: > >> I was wondering why should we link ICE candidate gathering procedures to >> call setup flow. >> Can't this be done by browser periodically independent of RTCWeb call ? >> >> This may end up saving ton of time if the network topology doesn't >> change frequently. >> >> Is this a valid argument ? >> > the chief problem with that thought is that with current APIs, the browser > does not know which STUN/TURN server to use before the PeerConnection is > created (it's an init parameter). > > If we want this separation, we would have to create some object > (PeerConnectionFactory?) that would take the STUN/TURN server name as > parameters, gather the candidates and generate a PeerConnection object with > these candidates when required. > > This may be a Good Thing for other reasons (the rehydration case - > reestablishing a connection when the user does "reload"), but does > complicate the simple case. > > One issue with this is that a single preallocator can't do the right thing if you want to have multiple PeerConnections, or multiple unbundled m= lines. As an alternative, you could simply create a PeerConnection, call startIce to gather candidates (pre-call), and only getUserMedia/send the offer when you are ready to place the call.
Received on Tuesday, 14 February 2012 13:51:51 UTC