1747234 - Direction of a=inactive in SDP not compatible with a=simulcast:recv

Status: RESOLVED DUPLICATE of bug 1807193

(Core :: WebRTC: Signaling, defect, P2)

Description

[Petar Minchev]

Attachment: Firefox_SDP_Error.txt

Steps to reproduce:

1. Publish simulcast video stream into a peer connection
2. Then deactivate the track (a=inactive direction) of the m=video.

It works under Chrome, but not under Firefox. Looking at the source code of Firefox when it sees a=simulcast:recv it expects a=recvonly. In my opinion a=inactive should be supported too.

Actual results:

Firefox throws an error:
WebRTC error: DOMException: SIPCC Failed to parse SDP: SDP Parse Error on line 30: simulcast attribute has a direction that is inconsistent with the direction of this media section.

Expected results:

Firefox should just deactivate the track.
a=inactive should be compatible with a=simulcast:recv as Chrome supports it and just deactivates the track.

Here is the relevant snippet of Firefox source code which throws the error:

bool SipccSdpMediaSection::ValidateSimulcast(
sdp_t* sdp, uint16_t level, SdpErrorHolder& errorHolder) const {
if (!GetAttributeList().HasAttribute(SdpAttribute::kSimulcastAttribute)) {
return true;
}

const SdpSimulcastAttribute& simulcast(GetAttributeList().GetSimulcast());
if (!ValidateSimulcastVersions(sdp, level, simulcast.sendVersions, sdp::kSend,
errorHolder)) {
return false;
}
if (!ValidateSimulcastVersions(sdp, level, simulcast.recvVersions, sdp::kRecv,
errorHolder)) {
return false;
}
return true;
}

bool SipccSdpMediaSection::ValidateSimulcastVersions(
sdp_t* sdp, uint16_t level, const SdpSimulcastAttribute::Versions& versions,
sdp::Direction direction, SdpErrorHolder& errorHolder) const {
if (versions.IsSet() && !(direction & GetDirectionAttribute().mValue)) {
errorHolder.AddParseError(sdp_get_media_line_number(sdp, level),
"simulcast attribute has a direction that is "
"inconsistent with the direction of this media "
"section.");
return false;
}

Comment 1

[Byron Campen [:bwc]]

I think you're right, there's nothing in the spec that says this is invalid SDP. We ought to just let this slide I think.

Comment 2

[Marco Castelluccio [:marco]]

Given we have no reports from the field, should we still consider this as S2?

Comment 4

[Petar Minchev]

Is it expected after direction is changed to inactive that Firefox drops all simulcast layers from the transceiver?
This issue doesn't occur in Chrome or Safari and creates difficulties when disabling, reenabling cam which drops the simulcast layers.
Ideally it should work like in Chrome and Safari and not drop the simulcast layers, just because direction is temporarily inactive.

Comment 5

[Byron Campen [:bwc]]

(In reply to Petar Minchev from comment #4)

Is it expected after direction is changed to inactive that Firefox drops all simulcast layers from the transceiver?
This issue doesn't occur in Chrome or Safari and creates difficulties when disabling, reenabling cam which drops the simulcast layers.
Ideally it should work like in Chrome and Safari and not drop the simulcast layers, just because direction is temporarily inactive.

Could you be more specific about what you mean by "drops all simulcast layers"? Are you saying that simulcast does not resume if a=sendonly/sendrecv is subsequently negotiated? Or are you referring to something like RTCRtpSender.getParameters()/getStats() not containing what you expect?

Comment 6

[Petar Minchev]

By “drops all simulcast layers”, I mean that after renegotiating the video m-section to a=inactive, Firefox removes the simulcast from the SDP for that transceiver, specifically the a=rid lines and the a=simulcast line.

What I am observing is:

1. Initial negotiation with simulcast enabled works as expected.
2. Camera is disabled and the transceiver direction is renegotiated to inactive.
   In Firefox, the subsequent local SDP no longer contains the simulcast SDP lines for that transceiver.
3. After re-enabling the camera and renegotiating back to sendonly or sendrecv, simulcast does not resume as before, because the transceiver now appears to have lost its simulcast envelope and only a single encoding remains negotiated.

Comment 7

[Byron Campen [:bwc]]

Ahhh, bug 1834821, got it.