1653720 - Firefox with RTX enbaled (>=80) Chrome SDP interop error

Status: RESOLVED FIXED

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

Description

[Manjesh Malavalli]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Steps to reproduce:

Steps to reproduce the problem:

1. Open this codepen in Chrome and Firefox 79+: https://codepen.io/manjeshbhargav/pen/bGEMraR
2. Create and apply an offer in Firefox 79+.
3. Copy and apply the offer in Chrome.
4. Create and apply an answer in Chrome.
5. Copy and apply the answer in Firefox 79+.
6. Create and apply an offer in Chrome.
7. Copy and apply the offer in Firefox 79+.
8. Create and apply an answer in Firefox 79+.
9. Copy and apply the answer in Chrome.

Actual results:

During Step 9, the following warning and error messages are shown in the Chrome console:

Warning: "[Deprecation] "Complex" Plan B SDP detected! Chrome will switch the default sdpSemantics in M72, around January 2019 from 'plan-b' to the standardized 'unified-plan' format and this peer connection is relying on the default sdpSemantics. This SDP is not compatible with Unified Plan and will be rejected by clients expecting Unified Plan. For more information about how to prepare for the switch, see https://webrtc.org/web-apis/chrome/unified-plan/."

Error: "DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote answer sdp: Media section has more than one track specified with a=ssrc lines which is not supported with Unified Plan."

Expected results:

No console errors.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Philipp Hancke [:fippo]]

Nils: as discussed in https://bugs.chromium.org/p/chromium/issues/detail?id=1106157#c2 I think the problem is the additional ssrc without having a mediastream in the subsequent offer.

Comment 3

[Byron Campen [:bwc]]

Looking at the SDP in comment 2, we put multiple ssrcs in that m-section because we've negotiated rtx, which needs both ssrcs to be signaled.

Comment 4

[Philipp Hancke [:fippo]]

bwc: the sdp from comment 2 works (I got confused myself).
The sdp that breaks is (the video part):
m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125
c=IN IP4 0.0.0.0
a=inactive
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:124 apt=120
a=fmtp:121 max-fs=12288;max-fr=60
a=fmtp:125 apt=121
a=ice-pwd:03f002e53b4eacb48adb93df449e98cb
a=ice-ufrag:9898cda7
a=mid:1
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:121 transport-cc
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=setup:passive
a=ssrc:3217337736 cname:{d2d6d1a1-1867-40c7-ae1b-6cd5d0722187}
a=ssrc:2969694815 cname:{d2d6d1a1-1867-40c7-ae1b-6cd5d0722187}
a=ssrc-group:FID 3217337736 2969694815

This has no a=msid and is inactive so why is it negotiating a FID group?
(I agree that chrome could be smarter in its plan-detection...)

Comment 5

[Alex Chronopoulos [:achronop]]

Byron, can you please help me triage this one?

Comment 6

[Byron Campen [:bwc]]

I guess we could avoid adding this if we are not sending RTX, similar to bug 1646092?

Comment 7

[Nils Ohlmeier [:drno]]

[Tracking Requested - why for this release]: this could result in WebRTC call failures between Firefox and Chrome users, independent of the WebRTC service used.

Comment 8

[Nils Ohlmeier [:drno]]

I really dislike that we need to take of things on our end here again, which should be taken care of on the Chrome side (see https://bugs.chromium.org/p/chromium/issues/detail?id=1106157). But since this could affect a lot of interop calls if Firefox has RTX enabled can one of you Byron or Dan please look into getting a fix for this landed in 81 and uplifted into 80?

Comment 9

[Dan Minor [:dminor]]

Attachment: Bug 1653720 - Do not generate kFid ssrc-group if no msid is present; r=bwc!

Chrome's SDP parser has problems with an ssrc-group being present if the media
section is inactive and does not have an msid.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6f401501c42a
Do not generate kFid ssrc-group if no msid is present; r=bwc

Comment 11

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/6f401501c42a

Comment 12

[Dan Minor [:dminor]]

Comment on attachment 9166890 [details]
Bug 1653720 - Do not generate kFid ssrc-group if no msid is present; r=bwc!

Beta/Release Uplift Approval Request

• User impact if declined: WebRTC calls may fail on certain sites when communicating with Chrome.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk, this adds an extra check to already existing logic.
• String changes made/needed: None

Comment 13

[Julien Cristau [:jcristau]]

Comment on attachment 9166890 [details]
Bug 1653720 - Do not generate kFid ssrc-group if no msid is present; r=bwc!

webrtc interop fix, approved for 80.0b5

Comment 14

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/9e3c055f903c