RE: Issue 181: ICE credentials part of 'createOffer' generated offer

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.




________________________________________
From: Robin Raymond [robin@hookflash.com]
Sent: Friday, February 20, 2015 8:48 AM
To: public-ortc@w3.org
Subject: Issue 181: ICE credentials part of 'createOffer' generated  offer

https://github.com/openpeer/ortc/issues/181


Stefan Hakansson wrote:
--

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


Bernard Aboba replied:
---

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.

---

Received on Friday, 20 February 2015 17:53:46 UTC