Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Peter Thatcher <[e-mail]>]

On Fri, Nov 13, 2015 at 2:14 PM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> >>>1.  It says "answerer MUST assign shared ICE candidates to each bundled
> 'm=' line ... in the answer".  What is
> >>>the reasoning for duplicating candidates in this way in the answer?
> Clearly at this point, the offerer understands
> >>>BUNDLE and BUNDLE is negotiated, and the offerer (when using
> bundle-only) doesn't include duplicate candidates,
> >>>so what's value in duplicating the candidates in the answer?  If there
> isn't a good reason, I'd prefer to not duplicate
> >>>them, even if that means using 'a=bundle-only' in the answer (which is
> currently unspecified)
> >>
> >>At an early stage, we made a design decision that we’ll explicitly
> include all information in each m- line (like we do for non-BUNDLE), even
> if that means duplicating information.
> >>
> >>Otherwise we have to define procedures what happens if the m- line, in
> which the candidates were included, is e.g. later removed
> >>from the BUNDLE group. Then the candidates have to be assigned to some
> other m- line within the BUNDLE group, to make sure
> >>they are “seen” in the current SDP associated with the BUNDLE group. Etc.
> >
> ​> But that's not true for offers.  Offers can put "a=bundle-only" in the
> m-line and then leave out ICE candidates.  So why can't answers do that
> also?
>
> The reason you don't need to include candidates in a bundle-only m- line
> is so that you don't need to reserve unique candidates for the m- line (as
> the m- line is not going to be used unless it's placed in a bundle group,
> and hence will share the candidates associated with the bundle group).


​In the case of an m-line in an answer that is an answer to a bundle-only
m-line in an offer, the same logic applies:  the m-line is not going to be
used unless it's place in a bundle group, so you don't need to reserve
unique candidates, so you don't need to include any candidates.



> That is not an issue in the answer, as the same candidates can be assigned
> to each m- line in the bundle group.
>
>
​I thinking mandating the candidates be duplicated in the answer has three
issues:

1.  It conflicts with trickle ICE.
2.  It's slightly more complex to implement (we have to go add extra logic
to go duplicate these things)
3.  It's a complete waste of time/space/effort.  The recipient of these
duplicate candidates is never going to anything with them.


> Also keep in mind that, when a subsequent offer is sent, the bundle-only
> attribute is no longer used.


​Can you point out where in the draft it says that?  I tried finding it and
I had a difficult time seeing where bundle-only wasn't allowed in a
reoffer.​
​


> Would you then also in the subsequent offer only assign possible
> candidates to only one m- line within the bundle group?
>

​That sounds logical to me.  They aren't included in the first offer.  Why
add them to subsequent offers?  It's inconsistent, and a waste.



>
> >>> 2.  If the answerer does not include any candidates in the answer and
> instead trickles them later, should it trickle them
> >>> N times (once for each m-line in the BUNDLE group) or >1 time?  1 time
> seems much more reasonable than N times, but
> >>> if we duplicate candidates in the answer, but not duplicate them while
> trickling, that's a bit inconsistent.  Yet >another reason to not duplicate
> in the answer :).
> >>
> >> Assuming you use SDP to signal the trickled candidates, it’s true that
> you would duplicate them,
> >>
> >​What's the rationale for that?  These duplicates provide no value, and
> in the case of many m-lines (such as a conferencing
> >system with many participants), we could be talking about 30x the number
> of candidates being signaled.
>
> I hear what you are saying.
>
> But, if we would do a change, we also need to look at the full picture,
> and consider subsequent offers etc.
>

​I think a simple rule would be "if you know it's going to be bundled onto
another m-line, don't include candidates".  That would go for bundle-only
m-lines in an offer, bundled m-lines in an answer, and bundled m-lines in a
re-offer.​
​



>
> > but you would still indicate each in a single SDP message sent towards
> the offerer.
> >
> > The default behavior of trickle ICE webrtc is for the "onicecandidate"
> ​> event ​to have one candidate in each event, which means the simple
> WebRTC application will be signalling
> ​> each candidates individually.  For a single SDP message to contain many
> candidates, the application would
> > have to implement some form of candidate batching.  But a smart
> application wouldn't bother doing that.
> > It would just de-duplicate the candidates instead.  Which means it would
> just be counteracting this duplication.
>
> ​> This seems like just a silly waste to me, especially since it's
> apparently only required on the answerer side, and not on the offerer side.​
>
> Why don't you think it's needed on the offerer side? Are you saying that,
> in subsequent offers, each m- line would contain duplicated candidates?
>
>
​I was referring only to initial offers, where they aren't duplicated.  But
as I mentioned, I think bundle-only m-lines should contain in subsequent
offers should contain the same candidates as the initial offer (+ trickled
candidates).   There's no reason to duplicate candidates in a subsequent
offer.



> Regards,
>
> Christer
>
>