ICE credentials part of 'createOffer' generated offer

[stefhak]

I've been told that one ambition for ORTC is to be able to underpin the WebRTC 1.0 API.
Part of that is that the offer created by calling createOffer should include local ICE credentials, but createOffer should not start any ICE gathering.
In ORTC it seems that local ICE credentials are to be fetched from an RTCIceGatherer object, but it is not clear to me if that object stars gathering immediately (if so that would be a problem with "createOffer not start any gathering").
Just raising this issue in case this has been overlooked - I may well be misunderstanding ORTC APIs (or the ambition to be able to underpin WebRTC 1.0).

[aboba]

Currently the IceGatherer starts gathering upon construction. Since IceGatherer.getLocalParameters would be needed to form an offer, this does create a problem with emulating createOffer.

Separately, there has been a proposal to add a .gather() method to the IceGatherer that would presumably control the gathering behavior, and this might be another reason to go in that direction.

[aboba]

Here is the text in the JSEP draft (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep) that refers to ICE candidate gathering.

As described below, the onicecandidate callback does not fire until after setLocalDescription() is called. However a pool of ICE candidates can be gathered before then.

So a question is whether the behavior described below could be provided by constructing an IceGatherer (to provide for an ICE candidate pool) but not setting the onlocalcandidate callback in ORTC API until after setLocalDescription() is called.

3.4.4. ICE Candidate Pool

JSEP applications typically inform the browser to begin ICE gathering
via the information supplied to setLocalDescription, as this is where
the app specifies the number of media streams, and thereby ICE
components, for which to gather candidates. However, to accelerate
cases where the application knows the number of ICE components to use
ahead of time, it may ask the browser to gather a pool of potential
ICE candidates to help ensure rapid media setup.

When setLocalDescription is eventually called, and the browser goes
to gather the needed ICE candidates, it SHOULD start by checking if
any candidates are available in the pool. If there are candidates in
the pool, they SHOULD be handed to the application immediately via
the ICE candidate callback. If the pool becomes depleted, either
because a larger-than-expected number of ICE components is used, or
because the pool has not had enough time to gather candidates, the
remaining candidates are gathered as usual.

One example of where this concept is useful is an application that
expects an incoming call at some point in the future, and wants to
minimize the time it takes to establish connectivity, to avoid
clipping of initial media. By pre-gathering candidates into the
pool, it can exchange and start sending connectivity checks from
these candidates almost immediately upon receipt of a call. Note
though that by holding on to these pre-gathered candidates, which
will be kept alive as long as they may be needed, the application
will consume resources on the STUN/TURN servers it is using.

[stefhak]

Do you mean that the browser should always behave as if the application, at createOffer, always "ask[ed] the browser to gather a pool of potential ICE candidates to help ensure rapid media setup."?
Someone more involved in JSEP (Cullen, Justin or Ekr) should respond. But my takeaway of section 4.1.2 createOffer (which ends "Calling this method may do things such as generate new ICE credentials, but does not result in candidate gathering, or cause media to start or stop flowing.") is that ICE gathering should in the normal case not be started.
I'm currently struggling with this part in owr (https://github.com/EricssonResearch/openwebrtc); a clarification would be welcome.

[aboba]

Question posted to IETF RTCWEB mailing list:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg14233.html

[aboba]

Justin and EKR's reply:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg14236.html