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

["Rauschenbach, Uwe (NSN - DE/Munich)" <[e-mail]>]

Hi Martin,

Ok with your proposed flow as long as the SDP obtained in step 6 via the API contains the candidates (currently the W3C spec states they are included when using pc.localDescription).

A question on step 6 and your statement below the sequence: What would be the difference between an SDP created by pc.createOffer in step 6 and one obtained by getting pc.localDescription in step 6? Why do you consider multiple pc.createOffer calls nasty?

Thanks, Uwe 

> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of ext Martin
> Thomson
> Sent: Tuesday, May 13, 2014 3:59 AM
> To: Harald Alvestrand
> Cc: [e-mail]
> Subject: Re: [rtcweb] When are ICE candidates added to the SDP
> 
> 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.
> 
> 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 <[e-mail]> wrote:
> > On 05/12/2014 05:17 PM, Eric Rescorla wrote:
> >
> >
> >
> >
> > On Mon, May 12, 2014 at 6:51 AM, Harald Alvestrand
> <[e-mail]>
> > 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)
> >> <[e-mail]> 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:[e-mail]] On Behalf Of ext Eric
> >>> Rescorla
> >>> Sent: Monday, May 12, 2014 8:52 AM
> >>> To: [e-mail]
> >>> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >>
> >>
> >> --
> >> Surveillance is pervasive. Go Dark.
> >>
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb