Firefox generated offer isn't accepted by native WebRTC SDK - firefox

Question

I'm trying to connect my iOS/Android app that uses native WebRTC framework to web
While Chrome works just fine, Firefox generates invalid offer
iOS responds with RTCPeerConnection::setRemoteDescription: Error Failed to set remote offer sdp: Failed to set remote data description send parameters. and android just crashes with signal 11
Here is SDP offer generated by Firefox
v=0
o=mozilla...THIS_IS_SDPARTA-69.0.2 1330778261957800593 0 IN IP4 127.0.0.1
s=-
t=0 0
a=fingerprint:sha-256 52:13:5A:F1:78:DA:88:9E:B5:F6:6D:A6:3B:E5:8C:6C:3A:0C:1C:BB:9F:8D:2D:FB:54:1E:DC:8F:2B:32:46:7E
a=group:BUNDLE 0 1 2
a=ice-options:trickle
a=msid-semantic:WMS *
m=video 9 UDP/TLS/RTP/SAVPF 120 121 126 97
c=IN IP4 127.0.0.1
a=sendrecv
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:121 max-fs=12288;max-fr=60
a=ice-pwd:0b05e736dc7b9b60e6045bb32ecf1a4a
a=ice-ufrag:2a06fb0e
a=mid:0
a=msid:- {2c03d601-9874-c541-88e5-fdf246db7ceb}
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:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=ssrc:89993993 cname:{4f658c59-75d0-c34f-b6f3-3abde4bd69f3}
m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 127.0.0.1
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:0b05e736dc7b9b60e6045bb32ecf1a4a
a=ice-ufrag:2a06fb0e
a=mid:1
a=msid:- {9f4e7ccb-6c53-da4d-a1d2-6e8bfe79ed05}
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000/1
a=setup:actpass
a=ssrc:2126371479 cname:{4f658c59-75d0-c34f-b6f3-3abde4bd69f3}
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 127.0.0.1
a=sendrecv
a=ice-pwd:0b05e736dc7b9b60e6045bb32ecf1a4a
a=ice-ufrag:2a06fb0e
a=mid:2
a=setup:actpass
a=sctp-port:5000
a=max-message-size:1073741823
What's wrong with it?
I'm using Firefox Quantum 69.0.2
UPD: I've disabled data channels and now it's fine, so issue is somewhere in last 4 lines

Answer 1

The problem is you're using rtp datachannels, which are obsolete and non-standard.
To fix it, locate and remove any mention of DtlsSrtpKeyAgreement and RtpDataChannels.
These were old experiments that only work in Chrome. Chances are you copied them from an old book, and don't really need them. But they continue to create interop headaches, because people cut'n'paste and assume Chrome is correct in supporting them.
All browsers support standard datachannels these days, even Chrome, so there's really no reason to add these problem keywords.

Answer 2

Since disabling data channel solves the problem for now my guess is that the other endpoints can't handle Firefox spec compliant way of signaling data channels with webrtc-datachannel in the m=application line, but still expect a port number there instead.

Answer 3

What actually helped me is following settings in constraints:
{'DtlsSrtpKeyAgreement': isFirefox},
{"RtpDataChannels" : !isFirefox},