Can simulcast offers renegotiate rids?

[jan-ivar]

We appear to allow remote simulcast offers to renegotiate rids and number of layers:

If the description is of type "offer" and contains a request to receive simulcast, use the order of the rid values specified in the simulcast attribute to create an RTCRtpEncodingParameters dictionary for each of the simulcast layers, populating the rid member according to the corresponding rid value, and let sendEncodings be the list containing the created dictionaries. Otherwise, let sendEncodings be an empty list.

This differs from the local side, and conflicts with 5.4.1.:

The addTransceiver method establishes the simulcast envelope which includes the maximum number of simulcast streams that can be sent, as well as the ordering of the encodings ... Once the envelope is determined, layers cannot be removed.

If we allow the rids to be renegotiated (say, we start with 'low', 'med', and 'high', and then a renegotiation happens that changes to rids 'tall', 'grande', and 'venti'), then we have a referential integrity problem with payloadType. See https://github.com/w3c/webrtc-pc/issues/2313.

cc @docfaraday

[alvestrand]

If this isn't clear from the IETF rid spec (whether rids can be renamed in renegotiation), the rid spec has a problem.

[alvestrand]

https://tools.ietf.org/html/draft-ietf-mmusic-rid-15#section-6.5

6.5. Modifying the Session

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. 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. RIDs without proposed changes SHOULD re-use the ID from the previous exchange.

I interpret this as saying (indirectly) that rids can't be renamed, you can only propose new ones.

[alvestrand]

and it's perfectly legal (but one can question if it's reasonable) to refuse to accept any more rids after the initial negotiation.

[docfaraday]

and it's perfectly legal (but one can question if it's reasonable) to refuse to accept any more rids after the initial negotiation.

Especially considering that webrtc-pc currently forbids JS from changing the rids with setParameters, and there's prose in there that hints that the intent was to disallow changes like this at all.

[jan-ivar]

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 tries 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 (disallow?) 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?

[alvestrand]

Proposed fix:

• Webrtc-pc says that removed RIDs lead to disabled encodings
• Webrtc-pc says that additional RIDs in renegotiation are rejected (alternative: increase the encoding#)
• Webrtc-pc says that a RID with the same value will always refer to the same encoding

[alvestrand]

VI resolution: Reject all changes in a remote offer. Supporting them is too much to figure out at this point, and has no obvious use case.

[amithilbuch]

for some reason, this thread escaped my email filters. sorry about that.

the envelope should be set during initial negotiation and cannot change thereafter. this should be similar to the inability to change the 'mid' of an existing section. what you can do is set a layer as inactive to disable it. if you wanted to add a layer or change something you would need to negotiate a new section.

the intent is to make things simpler:

1. envelope is negotiated once and cannot change so there are no questions about removing a layer, then adding it back later (which could technically be considered different to adding a new layer altogether). no need to keep two states (remember what was removed).
2. mechanism already requires (i.e. valid use case) an 'active' flag on layers. so if i wanted to remove a layer, i could deactivate it 'permanently'.

re: normative steps - once initial offer/answer exchange is complete, the envelope is set. so a layer can be rejected in the initial answer (for reasons like encoding not supported). this is consistent with other negotiations (like codecs, sections, etc.), but not in a subsequent offer.

i support Harald's solution.

[jan-ivar]

@alvestrand are you providing a PR on this one?

[alvestrand]

Yes.