Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Paul Kyzivat <[e-mail]>]

WFM

On 2/18/16 1:56 PM, Christer Holmberg wrote:
> Hi Paul,
>
>>> Ok, so assuming the scope of this change would only be ICE, we could
>>> say that shared ICE candidates don’t have to be associated with each
>>> m- line within a BUNDLE group – it’s enough if they are associated with one m- line.
>>
>> I haven't been following this discussion closely, so forgive me if I have misunderstood...
>
> Don't worry - there hasn't been much discussion :)
>
>> I see how it might be inconvenient to redundantly provide all the candidates with each m-line. But at the least
>> this exception will need very careful specification, or else it could lead to very confusing implementations.
>
> Correct, and that's one reason I suggest that we limit the scope to ICE, eventhough we probably could do the same thing for any IDENTICAL and TRANSPORT category attribute.
>
>> (For instance, different subsets of the candidates associated with different m-lines.)
>
> Note that we are talking about m- lines within a given BUNDLE group, where the same set of shared candidates apply to each m- line. There will be no subset.
>
>> So if this is to be done, I think it should be quite restrictive.
>> Perhaps either duplicate candidates with every m-line or else all the candidates with only one m-line, and no candidates with any of the other m-lines in the bundle.
>
> We could e.g. say that shared candidates MUST be placed in the m- line representing the BUNDLE address (first mid in the mid list). Then we can either forbid them to be placed elsewhere, or say that they can be discarded if placed elsewhere.
>
> (Unique candidates must obviously always be explicitly placed in the m- line they belong to.)
>
>> If in all m-lines of the offer then also in all accepted m-lines in the answer. If in only one m-line in the offer, then only in the corresponding m-line of the answer.
>>
>> Even then, what is to be done if the candidates are with only one of the m-lines in the offer, and the answerer wants to reject *that* m-line but
>> accept others in the bundle? Does the answerer pick a different m-line to carry the candidates in the answer?
>
> Mandating the candidates in the m- line representing the BUNDLE address would work, because that m- line always belongs to the BUNDLE group.
>
> Regards,
>
> Christer
>
> 	
>
>> Q1: Does this apply only to the SDP ‘candidate’ attribute, or also to
>> other ICE-related SDP attributes?
>>
>> Q2: Is it a RECOMMENDED/SHOULD/MAY/MUST/MUST NOT?
>>
>> Now, if I don’t hear any feedback on this, I am NOT going to do the
>> change. Those who asked for this change (or otherwise have an opinion
>> on it), please speak up now.
>>
>> Regards,
>>
>> Christer
>>
>> *From:*mmusic [mailto:[e-mail]] *On Behalf Of *Christer
>> Holmberg
>> *Sent:* 16. helmikuuta 2016 17:15
>> *To:* Peter Thatcher
>> *Cc:* [e-mail]
>> *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>>
>> 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] <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
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>