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.

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

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

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

Regards,

Christer