Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Bernard Aboba <[e-mail]>]

“Optimize for the most often-used code path” should guide our thinking here.

 

Forcing duplication of ICE candidates on a BUNDLE/mux application just to ensure correctness of a legacy scenario does not represent a good engineering tradeoff. 

 

Today BUNDLE and RTP/RTCP mux represent the most popular mode of operation for WebRTC applications. 

 

If we are using BUNDLE and RTP/RTCP mux within ORTC (and now WebRTC 1.0, now that we have added RTCIceTransport objects), the BUNDLE’d m-lines represent a single RTCIceTransport object and there is only  a single component and a single set of ICE candidates.  

 

This is not to deny that there are legacy interop scenarios  where the Offerer needs to allocate ports RTP and RTCP on each m-line just in case the Answerer does not support BUNDLE and/or RTP/RTCP mux, and thus the Offerer needs to gather ICE candidates that would not be needed if BUNDLE/mux were negotiated.

 

The JS sample code for this is ugly, let alone the implementation code, all for a code path that will only be used a very small percentage of the time (which means that bugs may not get found/fixed).  

 

I’m not advocating that we make that legacy scenario impossible – just that we should not optimize for it.  For example, if we don’t duplicate ICE candidates and that turns out to be required, and another O/A exchange is needed to fix that, it wouldn’t bother me. 

 

From: mmusic [mailto:[e-mail]] On Behalf Of Christer Holmberg
Sent: Tuesday, November 17, 2015 11:22 AM
To: Peter Thatcher <[e-mail]>
Cc: [e-mail]
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

 

Anyone else having an opinion on this?

 

Regards,

 

Christer

 

From: Peter Thatcher [mailto:[e-mail]] 
Sent: 17 November 2015 01:06
To: Christer Holmberg <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[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