W3C home > Mailing lists > Public > public-ortc@w3.org > December 2015

Re: Suggestion for changes to IceGatherer to make it possible to signal IceParameters without gathering

From: Philipp Hancke <fippo@goodadvice.pages.de>
Date: Mon, 7 Dec 2015 09:19:03 -0800
To: public-ortc@w3.org
Message-ID: <5665BF87.6070606@goodadvice.pages.de>
Am 27.11.2015 um 15:43 schrieb Bernard Aboba:
> Some questions:
> A. For adapter.js, is the idea to delay calling the start() method until setLocalDescription() so that onlocalcandidate events only start firing then? If so, how would an ICE candidate pool be created prior to that? Is the idea to call start() but not set the onlocalcandidate event handler until later?
>
> With the current API, is it viable to construct an IceGatherer but delay attaching the onlocalcandidate event handler until IceCandidates are desired?

The bigger concern here is BUNDLE. Currently, using the max-compat 
bundle policy one would have to create ice gatherers for each 
mediasection. If the peer supports bundle, those are destroyed soon when 
receiving the answer and bundling everything onto one transport.


I don't understand why getLocalParamaters() is part of the gatherer and 
not the transport... possibly because of parallel forking? Which might 
be another use-case for being able to create a transport with certain 
ufrag/pwd.

Having getLocalParameters as part of the transportc would allow creating 
the gatherer in setLocalDescription or attaching one from the pool.
Received on Monday, 7 December 2015 17:19:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:57 UTC