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

On Mon, May 12, 2014 at 11:59 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> Why not:
>
> 1. pc.createOffer(...)
> 2. success callback fires (0 candidates)
> 3. pc.setLocalDescription(offer)
> 4. onicecandidate fires some number of times
> 5. onicecandidate fires with a null candidate
> 6. send pc.localDescription (as opposed to the original offer)
>
> No need to run multiple rounds of createOffer or anything nasty like that.
>

This doesn't seem like a complete answer. The spec explicitly allows
multiple CreateOffers, so what is the impact of that?

-Ekr

> Note that we don't have an onicegatheringstatechange event that would
> let us monitor that state more directly, but the actual code cost is
> identical either way.
>
>
> On 12 May 2014 09:14, Harald Alvestrand <harald@alvestrand.no> wrote:
> > On 05/12/2014 05:17 PM, Eric Rescorla wrote:
> >
> >
> >
> >
> > On Mon, May 12, 2014 at 6:51 AM, Harald Alvestrand <harald@alvestrand.no
> >
> > wrote:
> >>
> >> 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> 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.
> >
> >
> > So you mean:
> >
> > 1. CreateOffer()
> > 2. success callback fires.
> > 3. SetLocal()
> > 4. onicecandidate(...)
> > 5. onicecandidate(null)
> >
> > Then later (w/ no changes to the MSTs)
> >
> > 6. CreateOffer()
> > 7. success callback fires
> > 8. SetLocal (????)
> > 9. onicecandidate(null)
> >
> > I believe this would be a change to the W3C API (not that this is
> > necessarily bad)
> >
> >
> > Something like that, yes. Or in more detail, for a call requiring 2
> > candidates:
> >
> > 1. CreateOffer()
> > 2. success callback fires (1 candidate present)
> > 3. SetLocal()
> > 4. onicecandidate(...)
> > 5. onicecandidate(null)
> >
> > Then later (w/ no changes to the MSTs)
> >
> > 6. CreateOffer()
> > 7. success callback fires (2 candidates present)
> > 8. SetLocal ()
> > 9. onicecandidate(null)
> >
> > Then still later (after having done something that requires a 3rd
> > candidate):
> >
> > 10. CreateOffer()
> > 11. successCallback fires (2 candidates present)
> > 12. SetLocal()
> > 13. onicecandidate(...)
> > 14. onicecandidate(null)
> >
> > If we don't have the null onicecandidate in case 2 (step 9), it gets
> hard to
> > support case 3 (step 12-14).
> >
> >
> > -Ekr
> >
> >>
> >>
> >>
> >> -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] On Behalf Of ext Eric
> >>> Rescorla
> >>> Sent: Monday, May 12, 2014 8:52 AM
> >>> To: 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.
> >>
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>