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

Re: [rtcweb] ICE Candidate Gathering - Basic Thought

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 14 Feb 2012 15:07:37 +0100
Message-ID: <4F3A6AA9.60503@alvestrand.no>
To: Justin Uberti <juberti@google.com>
CC: "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>, rtcweb@ietf.org, public-webrtc@w3.org
On 02/14/2012 02:51 PM, Justin Uberti wrote:
>
>
> On Tue, Feb 14, 2012 at 4:23 AM, Harald Alvestrand 
> <harald@alvestrand.no <mailto: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.
If multiple local ports are needed (and the code seems to be simplest if 
they are): yes, we need to allocate more than one port. That doesn't 
mean that a preallocator can't do it, just that it needs to know how 
many are needed.

>
> 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.

Which made me realize that this isn't clear from the current drafts: If I do

pc = new PeerConnection()
pc.startIce()
<wait 3 seconds>
pc.CreateOffer()

will the created offer contain the candidates that have been generated?

If it does, it seems to me that people who don't need/can't use trickle 
candidates don't need to handle the ICE machinery at all.

                     Harald
Received on Tuesday, 14 February 2012 14:08:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 14 February 2012 14:08:16 GMT