Re: Issue 497: RID as read-only in setParameters()?

Not allowing the JS to specify the RIDs would be reversing what we agreed
to in Sapporo, and we'd have to go repeat lots of discussion around this.
I don't think it's difficult to avoid conflicts, so it doesn't seem worth
reversing the decision.

​Plus, even if we did reverse that decision, it still wouldn't really avoid
conflicts.  Because while the RID values wouldn't conflict, the *number* of
RIDs values could still conflict, meaning you could end up never offering
simulcast because you specified 3 layers but on an RtpSender that is
already bound to a remote description that doesn't allow any RIDs, in which
case it doesn't matter who chooses the RIDs: they've already been
rejected.  It's the same root problem: when you specify that you want
simulcast, it needs to create a new transceiver to put in the offer,
otherwise it might be rejected before it's offered.

But I think we could still improve the RID selection with a simple rule: if
the RID isn't set by the JS, the browser can still choose one and offer the
encoding.  So, even if the JS calls "pc.addTransceiver("video",
{sendEncodings: [{}, {}, {}]})", then shouldn't createOffer offer RIDs,
chosen by the browser.  I don't recall if decided that or not (I hope we
did, but I can't remember), but the way the W3C spec is currently written
leaves it open to JSEP to allow it.  So I hope we do allow it in JSEP.
That way, apps that care can choose, and apps that don't, don't have to.
​
​



On Sun, Feb 14, 2016 at 9:17 AM, Cullen Jennings (fluffy) <fluffy@cisco.com>
wrote:

>
> I think the RID should be chosen purely by the browser and not changeable
> for JS. We have many other things the JS can use for identifiers so I don't
> see the need for this. Once applications start using it to encode
> information we get into all kinds of questions about what happens with
> conflicts etc. It's better just chosen by browser.
>
>
>