Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Christer Holmberg <[e-mail]>]

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). That is not an issue in the answer, as the same candidates can be assigned to each m- line in the bundle group.

Also keep in mind that, when a subsequent offer is sent, the bundle-only attribute is no longer used. Would you then also in the subsequent offer only assign possible candidates to only one m- line within the bundle group?
 
>>> 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.

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

Regards,

Christer