Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Christer Holmberg <[e-mail]>]

Hi,

We still need to conclude this issue before we can ship BUNDLE, so I’d like to hear some input from people. I do intend to request agenda time to discuss it in Buenos Aires, but if we can find a solution before that there will be more time for cookies…

Regards,

Christer

From: Peter Thatcher [mailto:[e-mail]]
Sent: 17. marraskuuta 2015 1:06
To: Christer Holmberg
Cc: [e-mail]
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE



On Mon, Nov 16, 2015 at 2:58 PM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
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.

​That sounds fair.  I'd like to hear what others think about this.​
​



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

That would work as well.
​


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

​So a rule of "the candidates can be in any one of the m-lines, and it doesn't matter which, and it can change any time".  That seems reasonable to me.  It leave the most flexibility to the one writing the SDP, and it's very easy to implement for the one reading the SDP.​



Regards,

Christer