Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Peter Thatcher <[e-mail]>]

On Thu, Nov 12, 2015 at 1:12 PM, Christer Holmberg <
[e-mail]> wrote:

> Hi Peter,
>
>
>
> >While implementing BUNDLE, we ran into a few questions
> about draft-ietf-mmusic-sdp-bundle-negotiation-23,
>
> >especially section 11 and when ICE candidates are included in m-lines:
>
> >
>
> >
>
> >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?

​


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


> 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.​





>
>
> >3. (more for editors)  Everything refers to "11.1", but 11.1 doesn't say
> much.  Does it mean "11.2.1", which has more substance?
>
> >
>
> >4. (more for editors) 11.2.2 and 11.2.5 are exactly the same.  Why not
> just remove 11.2.5 and say 11.2.2 refers to all offers?
>
>
>
> I have to do some editorial fixes based on comments from Flemming, so I’ll
> take a look at these at the same time :)
>
>
>
> Regards,
>
>
>
> Christer
>
>
>