W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

Re: [rtcweb] ICE Candidate Gathering - Basic Thought

From: Justin Uberti <juberti@google.com>
Date: Tue, 14 Feb 2012 08:51:00 -0500
Message-ID: <CAOJ7v-2ERWHhtZSAZuSvUPP+50LBe-wRRh_h7ba4F4rhdECfrw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>, rtcweb@ietf.org, public-webrtc@w3.org
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=

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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC