Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Paul Kyzivat <[e-mail]>]

On 2/18/16 7:19 AM, Christer Holmberg wrote:
> **sounds of crickets**
>
> 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...

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.

(For instance, different subsets of the candidates associated with 
different m-lines.)

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

	Thanks,
	Paul

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