- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 14 Feb 2012 10:23:02 +0100
- To: "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>
- CC: rtcweb@ietf.org, public-webrtc@w3.org
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.
Harald
Received on Tuesday, 14 February 2012 09:23:31 UTC