1834806 - Setting RTCRtpEncodingParameters.active does not work for audio

Status: RESOLVED DUPLICATE of bug 1813848

(Core :: WebRTC, defect, P3)

Description

[andysem]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

Changing RTCRtpEncodingParameters.active for an actively sending RTCRtpSender does not work. After calling RTCRtpSender.setParameters() with the updated parameters (with the active flag set to false in one of the encodings), RTCRtpSender.getParameters() returns a set of parameters where the active flag is still true. Consequently, a subsequent call to RTCPeerConnection.createOffer() creates an SDP offer where all simulcast substreams are active (whereas one of them is supposed to be paused).

Here's a piece of code that modifies the active flag:

let sender_parameters = transceiver.sender.getParameters();
console.log("Transceiver sender params for mid: " + mid + ", rid: " + rid + ": " + JSON.stringify(sender_parameters));

if (!sender_parameters.encodings)
{
    console.log("Transceiver for mid: " + mid + " does not have encodings");
    return;
}

let i = 0;
for (; i < sender_parameters.encodings.length; ++i)
{
    if (sender_parameters.encodings[i].rid === rid)
        break;
}

if (i >= sender_parameters.encodings.length)
{
    console.log("Transceiver for mid: " + mid + " does not have a substream with rid: " + rid);
    return;
}

console.log("Is encoding active: " + sender_parameters.encodings[i].active + ", setting active to: " + checkbox.checked);

sender_parameters.encodings[i].active = checkbox.checked;
transceiver.sender.setParameters(sender_parameters);

sender_parameters = transceiver.sender.getParameters();
console.log("Modified transceiver sender params for mid: " + mid + ", rid: " + rid + ": " + JSON.stringify(sender_parameters));

Actual results:

When invoked, the above piece of code produces the following output in the console:

Transceiver sender params for mid: 1, rid: 2: {"codecs":[],"headerExtensions":[],"rtcp":{"cname":"","reducedSize":false},"encodings":[{"active":true,"priority":"low","rid":"2","scaleResolutionDownBy":2.25},{"active":true,"priority":"low","rid":"1","scaleResolutionDownBy":1.5},{"active":true,"priority":"low","rid":"0","scaleResolutionDownBy":1}],"transactionId":"{f0998a51-ab3a-4901-adc5-a9adc7d20133}"} display.js:392:11
Is encoding active: true, setting active to: false display.js:413:11
Modified transceiver sender params for mid: 1, rid: 2: {"codecs":[],"headerExtensions":[],"rtcp":{"cname":"","reducedSize":false},"encodings":[{"active":true,"priority":"low","rid":"2","scaleResolutionDownBy":2.25},{"active":true,"priority":"low","rid":"1","scaleResolutionDownBy":1.5},{"active":true,"priority":"low","rid":"0","scaleResolutionDownBy":1}],"transactionId":"{f0998a51-ab3a-4901-adc5-a9adc7d20133}"} display.js:419:11

Note that the modified params contain "active":true for all encodings.

Expected results:

The active flag should be modifiable. After being set to false, this substream should be indicated as paused in "a=simulcast" in the SDPs created by createOffer/createAnswer.

Note that the same piece of code works as expected in Chrome 113.

Comment 1

[andysem]

Sorry, that third line in the output is produced by this:

sender_parameters = transceiver.sender.getParameters();
console.log("Modified transceiver sender params for mid: " + mid + ", rid: " + rid + ": " + JSON.stringify(sender_parameters));

These two lines immediately follow the piece of code I quoted. This was poor copy/pasting on my part.

Comment 2

[steve s]

RTCRtpEncodingParameters.active also does not work for me, however I'm having an issue with it working with audio-tracks; it seems to do nothing.

The active setting does seems to work with my video-tracks though, but I'm not using simulcasting with my video tracks either.

A few months ago the active setting option was added, but I' guessing that maybe audio was not accounted for. That patched code reference: https://hg.mozilla.org/integration/autoland/rev/4a8af015edd8

Comment 3

[Ina Popescu, Desktop QA]

Setting the component and waiting for the developer's opinion about it.
If this is not the correct component, please feel free to change it to a more appropriate one.

Comment 4

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:mjf, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Michael Froman [:mjf]]

bwc: Do you have any thoughts here?

Comment 6

[Byron Campen [:bwc]]

A few things:

1. setParameters is async; you will not see any modifications you have made if you call getParameters immediately afterward.
2. RTCRtpEncodingParameters.active does not have any effect on SDP. The simulcast pause syntax (a '~' in front of the rid) is not used in the webrtc standard, and almost certainly never will be. RTCRtpEncodingParameters.active only effects what the RTP engine is doing under the hood.
3. RTCRtpEncodingParameters.active was only ever intended for simulcast, so we did not implement for audio. It might be worth doing.

With these things in mind, can you verify whether setting active is having the expected effect?

Comment 7

[andysem]

(In reply to Byron Campen [:bwc] from comment #6)

A few things:

1. setParameters is async; you will not see any modifications you have made if you call getParameters immediately afterward.

Thanks. Calling getParameters() in the returned promise's then() handler does indeed show active:false. Tested in Firefox 115.0.3.

2. RTCRtpEncodingParameters.active does not have any effect on SDP. The simulcast pause syntax (a '~' in front of the rid) is not used in the webrtc standard, and almost certainly never will be. RTCRtpEncodingParameters.active only effects what the RTP engine is doing under the hood.

No, this is not the expected behavior. Changing the RTCRtpEncodingParameters.active must reflect on the SDP, specifically it must be signalled as the paused rid (i.e. with the "~" prefix). Currently, even if RTCRtpEncodingParameters.active is false, the substream is signalled as active (i.e. not paused) in the SDP.

I'll note again that Chrome 115 reflects RTCRtpEncodingParameters.active in SDP as expected.

Comment 8

[Byron Campen [:bwc]]

(In reply to andysem from comment #7)

(In reply to Byron Campen [:bwc] from comment #6)

A few things:

1. setParameters is async; you will not see any modifications you have made if you call getParameters immediately afterward.

Thanks. Calling getParameters() in the returned promise's then() handler does indeed show active:false. Tested in Firefox 115.0.3.

2. RTCRtpEncodingParameters.active does not have any effect on SDP. The simulcast pause syntax (a '~' in front of the rid) is not used in the webrtc standard, and almost certainly never will be. RTCRtpEncodingParameters.active only effects what the RTP engine is doing under the hood.

No, this is not the expected behavior. Changing the RTCRtpEncodingParameters.active must reflect on the SDP, specifically it must be signalled as the paused rid (i.e. with the "~" prefix). Currently, even if RTCRtpEncodingParameters.active is false, the substream is signalled as active (i.e. not paused) in the SDP.

I'm sorry, but the spec explicitly says this is not the case (from https://w3c.github.io/webrtc-pc/#simulcast-functionality):

Using setParameters, simulcast streams can be made inactive by setting the active member to false, or can be reactivated by setting the active member to true. [RFC7728] (RTP Pause/Resume) is not supported, nor is signaling of pause/resume via SDP Offer/Answer.

The reason for this is in order to use this SDP syntax, the endpoint MUST support RFC7728 (from https://www.rfc-editor.org/rfc/rfc8853.html#name-simulcast-capability)

If RTP stream pause/resume [RFC7728] is supported, any rid-id MAY be prefixed by a "~" character to indicate that the corresponding simulcast stream is paused already from the start of the RTP session. In this case, support for RTP stream pause/resume MUST also be included under the same "m=" line where "a=simulcast" is included.

I'll note again that Chrome 115 reflects RTCRtpEncodingParameters.active in SDP as expected.

If Chrome is doing this, it is violating the webrtc-pc w3c spec, and if it is doing it without signaling support for RFC 7728, it is violating the IETF simulcast spec (RFC 8853) as well.

Comment 9

[andysem]

I see. Thank you for posting references to the specs. I suppose, you can close this, unless you're planning some further work.

Comment 10

[Byron Campen [:bwc]]

The lack of support for RTCRtpEncodingParameters.active for audio is a bug, definitely, so I guess we can repurpose this bug to cover that.

Comment 11

[Byron Campen [:bwc]]

Marking as a dupe of the older bug because there's WIP over there.