Re: [rtcweb] When are ICE candidates added to the SDP

On 05/12/2014 02:39 PM, Eric Rescorla wrote:
>
>
>
> On Mon, May 12, 2014 at 2:03 AM, Rauschenbach, Uwe (NSN - DE/Munich)
> <uwe.rauschenbach@nsn.com <mailto:uwe.rauschenbach@nsn.com>> wrote:
>
>     Hi Eric, all,
>
>      
>
>     Is the consequence of "always trickle" that ICE candidates have to
>     be added by non-trickling applications via SDP manipulation?
>
>     I consider this indeed quite inconvenient for non-trickling
>     applications.
>
>
> So, my understanding was that we had agreed that no candidates would
> be available in the first CreateOffer() no matter how many candidates were
> in the pool.
>
> The intent of this message is to ask if that is useful.

If an application is written as

1) CreateOffer()
2) wait for the end of candidates callback
3) negotiate

then I would think it might have trouble if all the candidates are
present in the SDP, and therefore no callbacks were called.
Solution: Always fire the end of candidates callback after calling the
success callback, even if all candidates are in the SDP already.

>
> -Ekr
>
>     A way out would be that the SDP always contains the candidates
>     collected so far (as currently defined in the JSEP snippet cited),
>
>     or that a switch in the API allows an application to configure the
>     behavior when adding ICE candidates.
>
>      
>
>     Kind regards,
>     Uwe
>
>      
>
>      
>
>     *From:*rtcweb [mailto:rtcweb-bounces@ietf.org
>     <mailto:rtcweb-bounces@ietf.org>] *On Behalf Of *ext Eric Rescorla
>     *Sent:* Monday, May 12, 2014 8:52 AM
>     *To:* rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     *Subject:* [rtcweb] When are ICE candidates added to the SDP
>
>      
>
>     See: https://github.com/rtcweb-wg/jsep/issues/11
>
>      
>
>     Section 3.4 reads:
>
>      
>
>     When a new ICE candidate is available, the ICE Agent will notify the
>
>     application via a callback; these candidates will automatically be
>
>     added to the local session description. When all candidates have
>
>     been gathered, the callback will also be invoked to signal that the
>
>     gathering process is complete.
>
>      
>
>     However, we agreed in London that we would do "always trickle", and
>
>     that even if there were candidates available at the time when
>     CreateOffer
>
>     (because of candidate pooling) was called, they would not be included
>
>     in the initial offer. Consider the following sequence of events.
>
>      
>
>     0. pc = new RTCPeerConnection();
>
>     1. pc.AddStream(stream);
>
>     2. pc.CreateOffer();
>
>     3. CreateOffer callback fires with offer A, and you call
>     SetLocalDescription();
>
>     4. onicecandidate fires with candidate X.
>
>     5. pc.CreateOffer()
>
>     6. CreateOffer callback fires with offer B.
>
>     7. onicecandidate fires with null.
>
>      
>
>     So, in London, I think we agreed that offer A would have no
>     candidates.
>
>     The above text implies that if you were to examine
>     localdescription prior
>
>     to step #5 or at step #7 it would contain candidate X, and
>     probably that offer B would
>
>     also contain candidate X.
>
>      
>
>     Note that it's quite inconvenient for non-trickle applications to
>     never
>
>     have any candidates in the SDP, especially after gathering is
>     completed
>
>     at step #7. However it also seems kind of inconsistent to only
>     update the
>
>     candidates after SetLocal() has been called.
>
>      
>
>     -Ekr
>
>      
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.