Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Christer Holmberg <[e-mail]>]

Hi,

>> 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.  
> 
> Those are all fair points. I wish we'd had more implementation input when we write our specs.
>
> That's what I'm providing now :).  We can still change the spec, can't we?
​
Sure.

However, as we are talking about a design wise big (in my opinion) change, at a late stage, I'd like to hear what other people think.
 
>>>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.​
​>>
>> Section 8.5.1 says:
>>
>>        "When an offerer generates a subsequent offer, it MUST assign the
>>       previously selected offerer BUNDLE address [Section 8.3.2], to each
>>       bundled "m=" line (including any bundle-only "m=" line), except if:"
>>
>> And, as the usage of the attribute is only defined when the port value is zero, it would not work when the BUNDLE address (read: non-zero port) must be associated with the m- line.
>>
>> Section 6 says:
>>
>>   "The usage of the 'bundle-only' attribute is only defined for a
>>   bundled "m=" line with a zero port value, within an offer.  Other
>>   usage is unspecified."
>
​> Thanks.  That text would be more clear as "with an initial offer" instead of "whithin an offer", since that's what it really means in conjuction with 8.5.1.

Ok.

> However, that's precisely the text that I think we could change.  I think we could change the bundle-only attribute to 
> be allowed in answers and in subsequent offers.  Then clients could use the attribute as a way of avoiding duplication 
> of candidates and the complications with trickle ICE.​

Assuming we would remove the duplication of candidates, I don't think that would require us to change a semantics of the attribute. We could simply say that the candidates don't need to be duplicated in bundled m- lines, no matter if those m- lines are bundle-only or not. 

>>>> 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. 
>>
>> Then someone could ask: what about other (non-candidate) attributes that must have identical values for each bundled m- line? Should those also be assigned to only one of the m- lines?
>
​> If it's something unique to the bundle group, and not the m-line, that seems reasonable to me.  ​
​>
​> But candidates are more painful than those would be because of the interactions with trickle ICE.  If it weren't for trickle ICE this wouldn't be as big of a deal.​

Correct. We just need to make it very clear whether it applies only to candidate attributes, or to attributes with identical values in general.

>>>>>>>> 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.​
​>>>
>> Bundled m- lines in a re-offer can still be rejected by the answerer.
>
​> That sounds the same as an initial offer.  How does it imply that a re-offer must duplicate 
> candidates across m-lines, even when an initial offer doesn't need to?​
​
In the initial offer each m- line contains candidates (unique). If an m- line in the offer is rejected, the answerer must select the offerer BUNDLE address (and the associated candidiates) from another m- line.

Now, in a re-offer, if the m- line containing the candidates is rejected, the answerer needs to include its candidates in another m- line in the answer. That's doable, but it would need to be clearly documented. In other words: it needs to be clear that the candidates can occur in ANY of the bundled m- lines, and that m- line may change between offers and answers.

Regards,

Christer