W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > September 2019

Re: [webrtc-pc] Can simulcast offers renegotiate rids? (#2314)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Mon, 30 Sep 2019 15:04:06 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-536604273-1569855845-sysbot+gh@w3.org>
> I interpret this as saying (indirectly) that rids can't be renamed, you can only propose new ones.

Hmm, I interpret it as saying rids MAY be renamed. Regardless, we can't normatively specify what WILL come in, only what to do with it.

Looks like MMUSIC wants to manage expectations, but I find it hard to draw normative lines from it:

> Offers and answers inside an existing session follow the rules for initial session negotiation. Such an offer MAY propose a change in the number of RIDs in use.

Either:
 1. Should've been lower-case "may"; can't specify what WILL come in, only what to do with it. 
 2. Implementations MAY reject offers over rid number mismatch.

> To avoid race conditions with media, any RIDs with proposed changes SHOULD use a new ID, rather than re-using one from the previous offer/answer exchange.

Paraphrasing: Proposing changes in RIDs with same ID MAY cause media race conditions.

> RIDs without proposed changes SHOULD re-use the ID from the previous exchange.

Anything can change.

In webrtc-pc, the *"layers cannot be removed"* is from https://github.com/w3c/webrtc-pc/pull/2081 and applies to SRD(simulcastoffer). But the normative steps in the same PR do not appear to back this up. @amithilbuch Do you recall the intent here?

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2314#issuecomment-536604273 using your GitHub account
Received on Monday, 30 September 2019 15:04:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:29 UTC