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

On Dec 7, 2015, at 09:20, Philipp Hancke <fippo@goodadvice.pages.de<mailto:fippo@goodadvice.pages.de>> wrote:


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.

[BA] That is a consequence of the max-compat bundle policy:


  max-compat:  All media sections will contain transport parameters;
      none will be marked as bundle-only.  This policy will allow all
      streams to be received by non-BUNDLE-aware endpoints, but require
      separate candidates to be gathered for each media stream.

If ice gatherers are not created for each media section then it would not be possible to gather separate candidates for each potentially separate media stream. Also, once setLocalDescription() is called and an Offer is sent, the Offerer needs to be prepared to receive ICE connectivity checks, which requires a gatherer for each media section to be listening for them.

I don't understand why getLocalParamaters() is part of the gatherer and not the transport...

[BA] It is part of the gatherer because in the forking case there can be a single gatherer but multiple transports, one for each responder.

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 transport would allow creating the gatherer in setLocalDescription or attaching one from the pool.

[BA] If the gatherer were constructed in setLocalDescription(), how could an ICE candidate pool be provided if that was specified in the configuration passed in the PeerConnection constructor?