Re: [rtcweb] ICE Candidate Gathering - Basic Thought

On Tue, Feb 14, 2012 at 9:07 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> **
> On 02/14/2012 02:51 PM, Justin Uberti wrote:
>
>
>
> 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.
>
> 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.
>

You are correct. I should have said that it is harder for the preallocator
to know what to do (i.e. we would need more API for it).

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

Yes. If you use the IceCallback, you can be notified when all the
candidates are ready, instead of using a timeout. But a timeout would work
too.


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

Exactly. I tried to indicate that in section 4.5 of the -01 draft.

>
>
>                     Harald
>
>
>