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

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

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Wed, 17 Feb 2016 07:03:26 +0000
To: Peter Thatcher <pthatcher@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, Adam Roach <abr@mozilla.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Message-ID: <BLUPR03MB1499C36192ACD827C707523ECAE0@BLUPR03MB149.namprd03.prod.outlook.com>
Agree that it makes sense for the browser to choose the RID, if it isn’t specified initially.

Also agree that the RID should not be writeable in setParameters().   Not entirely sure that the term “read only” is the best phrase to use to describe this (since the RID can in fact be chosen when calling addTransceiver()), but I don’t have a better suggestion at the moment.

From: Peter Thatcher [mailto:pthatcher@google.com]
Sent: Tuesday, February 16, 2016 9:46 PM
To: Cullen Jennings (fluffy) <fluffy@cisco.com>
Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>; public-webrtc@w3.org; Adam Roach <abr@mozilla.com>
Subject: 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<mailto: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.


Received on Wednesday, 17 February 2016 07:04:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:47 UTC