W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2016

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

From: Peter Thatcher <pthatcher@google.com>
Date: Tue, 16 Feb 2016 21:45:43 -0800
Message-ID: <CAJrXDUHeEMTrf8ZMguxPaao=Ds0PpFEgrN7ZL6W+96f6OZMKWQ@mail.gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Adam Roach <abr@mozilla.com>
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>

> 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.
Received on Wednesday, 17 February 2016 05:46:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:13 UTC