Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Hi Peter,

>>> 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.
>
> While it would be nice to remove any duplication, the duplication is particularly painful for ICE candidates, because 
> there can be a lot of them, and because they change without any offer/answer action (thanks to trickle ICE).   
> So if we just covered that candidates, we'd be getting most of the value.

Assuming the scope is ICE, shouldn't the same still apply also to other ICE related attributes? I assume the values for the "remote-candidates",  "ice-lite", "ice-mismatch", "ice-ufrag", "ice-pwd", "ice-pacing" and "ice-options" attributes will be identical within a BUNDLE group, so...

...

>> 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.
>
> Just allowing the candidates to only be in the m-line representing the BUNDLE is exactly what I was asking for.  If you further *mandate* it, I can't complain.  Sounds good to me.

Unless someone objects, *only* allowing in the m- line representing the BUNDLE address makes things easier :)

(Of course, a good implementation should still be able to handle a case when it receives an offer/answer with the candidates in multiple m- lines within 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:mmusic-bounces@ietf.org] *On Behalf Of *Christer
> Holmberg
> *Sent:* 16. helmikuuta 2016 17:15
> *To:* Peter Thatcher
> *Cc:* mmusic@ietf.org
> *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:pthatcher@google.com]
> *Sent:* 17. marraskuuta 2015 1:06
> *To:* Christer Holmberg
> *Cc:* mmusic@ietf.org <mailto:mmusic@ietf.org>
> *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>
> On Mon, Nov 16, 2015 at 2:58 PM, Christer Holmberg
> <christer.holmberg@ericsson.com
> <mailto:christer.holmberg@ericsson.com>>
> 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic