Open Bug 1892073 (snapchat) Opened 1 year ago Updated 1 month ago

Snapchat for web is not supported on Firefox

Categories

(Web Compatibility :: Site Reports, task, P1)

Product:
Web Compatibility
Component:
Site Reports
Type:
task

Tracking

(Webcompat Priority:P2, Webcompat Score:4)

Status:
ASSIGNED
Project Flags:
Webcompat Priority P2
Webcompat Score 4

People

(Reporter: ksenia, Assigned: twisniewski)

References

(Depends on 2 open bugs,
URL
)

Details

(4 keywords)

User Story

platform:windows,mac,linux,android
impact:blocked
configuration:general
affects:all
diagnosis-team: video-conferencing
outreach-response-date: 2025-04-17
user-impact-score:100

Attachments

(2 files)

Bug 1892073 - add a nightly-only, desktop-only UA override for Snapchat; r?denschub
48 bytes, text/x-phabricator-request
Details | Review
Bug 1892073 - also ship our UA override for Snapchat to beta; r?denschub
48 bytes, text/x-phabricator-request
Details | Review

A tracking bug for https://web.snapchat.com not supporting Firefox.

from https://github.com/webcompat/web-bugs/issues/107613

Depends on: 1892078
Depends on: 1829758
Depends on: 1876865
No longer depends on: 1892078
Depends on: 1892084
Depends on: 1892086

Besides linked dependencies there are 2 important features that don’t work when spoofing as Chrome and need more investigation to figure out the root cause:

  1. Calling - once a call is made, recipient receives the call, but can’t connect. Looks like there is something missing in the sdp offer preventing successful connection to the remote peer.
  2. Snaps - when taking snaps the resulting picture has incorrect aspect ratio and images appear skewed.
Severity: -- → S2
User Story: (updated)
Keywords: webcompat:needs-contact, webcompat:needs-diagnosis
Priority: -- → P1
User Story: (updated)

Any chance you could record a WebRTC logging profile of a failed call and share in the bug?
Steps would be:

  • on about:logging select WebRTC preset and start logging
  • reproduce
  • back on about:logging, stop logging
  • Firefox Profiler opens up in a new tab, upload the profile including hidden threads.

That might contain something actionable.

Also if I may hypothesize a bit, point 2 in comment 1 may be that they assume chrome's behavior on getUserMedia's handling of constraints (our bug 1286945) rather than check the actual video dimensions.

Flags: needinfo?(kberezina)

(In reply to Andreas Pehrson [:pehrsons] from comment #2)

Any chance you could record a WebRTC logging profile of a failed call and share in the bug?
Steps would be:

  • on about:logging select WebRTC preset and start logging
  • reproduce
  • back on about:logging, stop logging
  • Firefox Profiler opens up in a new tab, upload the profile including hidden threads.

That might contain something actionable.

Also if I may hypothesize a bit, point 2 in comment 1 may be that they assume chrome's behavior on getUserMedia's handling of constraints (our bug 1286945) rather than check the actual video dimensions.

Hello Andreas, here is the profile https://share.firefox.dev/44Nqf2S (recorded it following these steps while making a call from Firefox Nightly to Chrome)

Flags: needinfo?(kberezina)

I've noticed that during establishing a connection with the receiving end there is a call to this.connection.setRemoteDescription(n); which fails with an error DOMException: Answer had no codecs in common with offer in m-section 1.

It appears that n is not based on the answer from receiving end, but rather a combination of await this.connection.createOffer(); and a custom function om() that produces a hardcoded sdp answer:

const xf = 99
 , Zf = {
            payloads: "99 98",
            rtp: [{
                payload: xf,
                codec: "H264",
                rate: 9e4
            }, {
                payload: 98,
                codec: "rtx",
                rate: 9e4
            }],
            fmtp: [{
                payload: 98,
                config: "apt=99"
            }],
            rtcpFb: [{
                payload: xf,
                type: "transport-cc"
            }, {
                payload: xf,
                type: "nack"
            }, {
                payload: xf,
                type: "nack",
                subtype: "pli"
            }, {
                payload: xf,
                subtype: "fir",
                type: "ccm"
            }, {
                payload: xf,
                type: "goog-remb"
            }],
            type: "video"
        };
        function Xf(e) {
            return "audio" === e ? Kf : Zf
        }

function om(e, t, n) {
            const i = Ff.qg(e)
              , o = (e,t)=>e.remoteSsrcs.filter((e=>e.type === Pf[t])).map(Hf)
              , a = n.remoteAuthData
              , r = {
                ...(s = n.streamerConnParams.endpoint,
                {
                    origin: {
                        username: "server",
                        sessionId: "1",
                        sessionVersion: 1,
                        netType: "IN",
                        ipVer: 4,
                        address: s
                    },
                    name: "test",
                    timing: {
                        start: 0,
                        stop: 0
                    },
                    icelite: "ice-lite",
                    setup: "passive"
                }),
                fingerprint: {
                    type: a.dtlsFingerprint.type,
                    hash: a.dtlsFingerprint.digest
                },
                media: [{
                    ...Qf(n.streamerConnParams.webrtcPort),
                    ...Xf("audio"),
                    ...Jf(a),
                    ext: nm("audio", i.media[0]),
                    ssrcs: [...o(n, "audio")],
                    mid: "0",
                    direction: "recvonly"
                }, {
                    ...Qf(n.streamerConnParams.webrtcPort),
                    ...Xf("video"),
                    ...Jf(a),
                    ext: nm("video", i.media[1]),
                    ssrcs: [...o(n, "video")],
                    mid: "1",
                    direction: "recvonly"
                }]
            };
            var s;
            r.media.push({
                ...Qf(n.streamerConnParams.webrtcPort),
                ...Xf("video"),
                ...Jf(a),
                ext: nm("video", i.media[2]),
                ssrcs: [...o(n, "screen")],
                mid: "2",
                direction: "recvonly"
            });
            for (let e = 3; e < i.media.length; ++e) {
                const o = i.media[e];
                try {
                    if (!o.mid)
                        throw Error("mid is not specified for m section");
                    if (!o.direction)
                        throw Error("direction is not specified for m section");
                    const e = im(o.mid.toString(), o.type, o.direction, o, t, n, o);
                    r.media.push(e)
                } catch (e) {
                    (0,
                    c.Cp)(e),
                    o.mid && r.media.push(em(o.type, o.mid))
                }
            }
            return r.groups = tm(r.media),
            {
                type: "answer",
                sdp: Ff.M9(r)
            }
        }
connectMedia(e) {
              this.applyMediaConnChange(
                (
                  async() => {
                    try {
                      this.webrtcConnParams = e;
                      const t = await this.connection.createOffer();
                      await this.connection.setLocalDescription();
                      const n = om(t.sdp ?? '', this.users, this.webrtcConnParams);
                      await this.connection.setRemoteDescription(n);
                      for (const t of e.remoteMediaParams) this.addNewUser(t);
                      await this.renegotiatePeerConnection(),
                      this.videoTransceiver?.sender.track &&
                      await cm(this.videoTransceiver.sender),
                      await this.addIceCandidates(e.streamerConnParams)
                    } catch (e) {
                      (0, c.Cp) (e),
                      this.listener.onMediaConnectionFailed(Zu.FATAL)
                    }
                  }
                )
              )
            }

This is the result, it's pretty much the same all the time:

{
  "type": "answer",
  "sdp": "v=0\r\no=server 1 1 IN IP4 str1-uswest2-104-193-186-207.addlive.io\r\ns=test\r\nt=0 0\r\na=setup:passive\r\na=ice-lite\r\na=fingerprint:sha-256 9D:88:1A:6B:CE:27:59:46:43:00:62:49:9D:8A:2C:38:9D:E4:18:ED:37:59:EF:9C:5F:A7:D8:C0:FE:6A:12:C8\r\na=group:BUNDLE 0 1 2\r\nm=audio 443 UDP/TLS/RTP/SAVPF 111\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=40;useinbandfec=1\r\na=rtcp:443 IN IP4 0.0.0.0\r\na=rtcp-fb:111 transport-cc\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=setup:passive\r\na=mid:0\r\na=ptime:40\r\na=recvonly\r\na=ice-ufrag:/Ko/7PoZvgkgbPZ2\r\na=ice-pwd:02c76bdead61041f4526a6fd17db00d0\r\na=fingerprint:sha-256 9D:88:1A:6B:CE:27:59:46:43:00:62:49:9D:8A:2C:38:9D:E4:18:ED:37:59:EF:9C:5F:A7:D8:C0:FE:6A:12:C8\r\na=ssrc:1514483164 cname:35929\r\na=rtcp-mux\r\nm=video 443 UDP/TLS/RTP/SAVPF 99 98\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:99 H264/90000\r\na=rtpmap:98 rtx/90000\r\na=fmtp:98 apt=99\r\na=rtcp:443 IN IP4 0.0.0.0\r\na=rtcp-fb:99 transport-cc\r\na=rtcp-fb:99 nack\r\na=rtcp-fb:99 nack pli\r\na=rtcp-fb:99 ccm fir\r\na=rtcp-fb:99 goog-remb\r\na=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=setup:passive\r\na=mid:1\r\na=recvonly\r\na=ice-ufrag:/Ko/7PoZvgkgbPZ2\r\na=ice-pwd:02c76bdead61041f4526a6fd17db00d0\r\na=fingerprint:sha-256 9D:88:1A:6B:CE:27:59:46:43:00:62:49:9D:8A:2C:38:9D:E4:18:ED:37:59:EF:9C:5F:A7:D8:C0:FE:6A:12:C8\r\na=ssrc:1265379532 cname:93035\r\na=rtcp-mux\r\nm=video 443 UDP/TLS/RTP/SAVPF 99 98\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:99 H264/90000\r\na=rtpmap:98 rtx/90000\r\na=fmtp:98 apt=99\r\na=rtcp:443 IN IP4 0.0.0.0\r\na=rtcp-fb:99 transport-cc\r\na=rtcp-fb:99 nack\r\na=rtcp-fb:99 nack pli\r\na=rtcp-fb:99 ccm fir\r\na=rtcp-fb:99 goog-remb\r\na=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=setup:passive\r\na=mid:2\r\na=recvonly\r\na=ice-ufrag:/Ko/7PoZvgkgbPZ2\r\na=ice-pwd:02c76bdead61041f4526a6fd17db00d0\r\na=fingerprint:sha-256 9D:88:1A:6B:CE:27:59:46:43:00:62:49:9D:8A:2C:38:9D:E4:18:ED:37:59:EF:9C:5F:A7:D8:C0:FE:6A:12:C8\r\na=ssrc:1846621312 cname:98964\r\na=rtcp-mux\r\n"
}

In case it can be helpful, this is the code for createOffer / setLocalDescription

onWebsocketOpen(e, t) {
                this.applyMediaConnChange((async()=>{
                    try {
                        await this.initLocalMediaForCall(),
                        this.setupInputStreamListeners();
                        const n = await this.connection.createOffer()
                          , [i,o] = function(e) {
                            const t = Ff.qg(e)
                              , n = (e,t)=>{
                                if (!t)
                                    return;
                                const n = t.find((t=>t.uri === e.uri));
                                if (!n)
                                    return;
                                if (n.value === e.value)
                                    return;
                                const i = t.find((t=>t.value === e.value));
                                i && (i.value = n.value),
                                n.value = e.value
                            }
                            ;
                            if (t.media.length < 3)
                                throw Error("invalid SDP: not enough m sections");
                            n(Gf, t.media[0].ext),
                            n(Vf, t.media[0].ext),
                            n(Vf, t.media[1].ext),
                            n(Vf, t.media[2].ext);
                            const i = t.media[0];
                            if (!i.fingerprint?.type)
                                throw Error("invalid SDP: missing DTLS fingerprint type");
                            if (!["md5", "sha-1", "sha-224", "sha-256", "sha-384", "sha-512"].includes(i.fingerprint.type))
                                throw Error("Unsupported DTLS fingerprint type: " + i.fingerprint.type);
                            if (!i.fingerprint.hash)
                                throw Error("invalid SDP: missing DTLS fingerprint hash");
                            if (!/^[0-9a-fA-F:]+$/.test(i.fingerprint.hash))
                                throw Error("invalid SDP: invalid DTLS fingerprint: " + i.fingerprint.hash);
                            return [{
                                type: "offer",
                                sdp: Ff.M9(t)
                            }, {
                                dtlsFingerprint: {
                                    type: i.fingerprint.type,
                                    digest: i.fingerprint.hash
                                }
                            }]
                        }(n.sdp ?? "");
                        await this.connection.setLocalDescription(i);
                        const a = {
                            salt: e.salt,
                            signature: e.signature,
                            talkId: {
                                talkUserId: e.userId,
                                userSessionId: BigInt(0),
                                sessionType: Xu.WEB
                            },
                            expiresMs: e.expires
                        };
                        this.listener.onSignalingConnected(o, a, t)
                    } catch (e) {
                        (0,
                        c.Cp)(e),
                        this.listener.onSignalingConnectionFailed(Zu.NETWORK)
                    }
                }
                ))
            }

Here is the offer that Firefox produces in this function:

{
  "type": "offer",
  "sdp": "v=0\r\no=mozilla...THIS_IS_SDPARTA-99.0 6646352392749310203 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 64:AD:DB:EE:9F:BD:AF:BC:A9:A4:EF:C0:4C:85:DC:C9:2F:8A:29:8C:6B:99:92:89:14:F1:4F:0F:3F:07:76:D0\r\na=ice-options:trickle\r\na=msid-semantic: WMS *\r\na=group:BUNDLE 0 1 2\r\nm=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 101\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:109 opus/48000/2\r\na=rtpmap:9 G722/8000/1\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:101 telephone-event/8000/1\r\na=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1\r\na=fmtp:101 0-15\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level\r\na=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=setup:actpass\r\na=mid:0\r\na=msid:- {680f56fb-5887-47b1-9d97-0a8374657d1d}\r\na=sendonly\r\na=ice-ufrag:d2af540f\r\na=ice-pwd:b960cf3bcd5d61d70ba0352231efee23\r\na=fingerprint:sha-256 64:AD:DB:EE:9F:BD:AF:BC:A9:A4:EF:C0:4C:85:DC:C9:2F:8A:29:8C:6B:99:92:89:14:F1:4F:0F:3F:07:76:D0\r\na=ssrc:2519914297 cname:{a2590e9d-ab23-4b7d-a240-b9771637c5df}\r\na=rtcp-mux\r\nm=video 0 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98 123 122 119\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:120 VP8/90000\r\na=rtpmap:124 rtx/90000\r\na=rtpmap:121 VP9/90000\r\na=rtpmap:125 rtx/90000\r\na=rtpmap:126 H264/90000\r\na=rtpmap:127 rtx/90000\r\na=rtpmap:97 H264/90000\r\na=rtpmap:98 rtx/90000\r\na=rtpmap:123 ulpfec/90000\r\na=rtpmap:122 red/90000\r\na=rtpmap:119 rtx/90000\r\na=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1\r\na=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1\r\na=fmtp:120 max-fs=12288;max-fr=60\r\na=fmtp:124 apt=120\r\na=fmtp:121 max-fs=12288;max-fr=60\r\na=fmtp:125 apt=121\r\na=fmtp:127 apt=126\r\na=fmtp:98 apt=97\r\na=fmtp:119 apt=122\r\na=rtcp-fb:120 nack\r\na=rtcp-fb:120 nack pli\r\na=rtcp-fb:120 ccm fir\r\na=rtcp-fb:120 goog-remb\r\na=rtcp-fb:120 transport-cc\r\na=rtcp-fb:121 nack\r\na=rtcp-fb:121 nack pli\r\na=rtcp-fb:121 ccm fir\r\na=rtcp-fb:121 goog-remb\r\na=rtcp-fb:121 transport-cc\r\na=rtcp-fb:126 nack\r\na=rtcp-fb:126 nack pli\r\na=rtcp-fb:126 ccm fir\r\na=rtcp-fb:126 goog-remb\r\na=rtcp-fb:126 transport-cc\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-fb:97 goog-remb\r\na=rtcp-fb:97 transport-cc\r\na=rtcp-fb:123 nack\r\na=rtcp-fb:123 nack pli\r\na=rtcp-fb:123 ccm fir\r\na=rtcp-fb:123 goog-remb\r\na=rtcp-fb:123 transport-cc\r\na=rtcp-fb:122 nack\r\na=rtcp-fb:122 nack pli\r\na=rtcp-fb:122 ccm fir\r\na=rtcp-fb:122 goog-remb\r\na=rtcp-fb:122 transport-cc\r\na=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:7 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay\r\na=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=setup:actpass\r\na=mid:1\r\na=msid:- {b7f7e0be-e4ee-4f0f-ba0c-de1647a0c45b}\r\na=sendonly\r\na=ice-ufrag:d2af540f\r\na=ice-pwd:b960cf3bcd5d61d70ba0352231efee23\r\na=ssrc:2958383365 cname:{a2590e9d-ab23-4b7d-a240-b9771637c5df}\r\na=ssrc:3663266707 cname:{a2590e9d-ab23-4b7d-a240-b9771637c5df}\r\na=ssrc-group:FID 2958383365 3663266707\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=bundle-only\r\nm=video 0 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98 123 122 119\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:120 VP8/90000\r\na=rtpmap:124 rtx/90000\r\na=rtpmap:121 VP9/90000\r\na=rtpmap:125 rtx/90000\r\na=rtpmap:126 H264/90000\r\na=rtpmap:127 rtx/90000\r\na=rtpmap:97 H264/90000\r\na=rtpmap:98 rtx/90000\r\na=rtpmap:123 ulpfec/90000\r\na=rtpmap:122 red/90000\r\na=rtpmap:119 rtx/90000\r\na=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1\r\na=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1\r\na=fmtp:120 max-fs=12288;max-fr=60\r\na=fmtp:124 apt=120\r\na=fmtp:121 max-fs=12288;max-fr=60\r\na=fmtp:125 apt=121\r\na=fmtp:127 apt=126\r\na=fmtp:98 apt=97\r\na=fmtp:119 apt=122\r\na=rtcp-fb:120 nack\r\na=rtcp-fb:120 nack pli\r\na=rtcp-fb:120 ccm fir\r\na=rtcp-fb:120 goog-remb\r\na=rtcp-fb:120 transport-cc\r\na=rtcp-fb:121 nack\r\na=rtcp-fb:121 nack pli\r\na=rtcp-fb:121 ccm fir\r\na=rtcp-fb:121 goog-remb\r\na=rtcp-fb:121 transport-cc\r\na=rtcp-fb:126 nack\r\na=rtcp-fb:126 nack pli\r\na=rtcp-fb:126 ccm fir\r\na=rtcp-fb:126 goog-remb\r\na=rtcp-fb:126 transport-cc\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-fb:97 goog-remb\r\na=rtcp-fb:97 transport-cc\r\na=rtcp-fb:123 nack\r\na=rtcp-fb:123 nack pli\r\na=rtcp-fb:123 ccm fir\r\na=rtcp-fb:123 goog-remb\r\na=rtcp-fb:123 transport-cc\r\na=rtcp-fb:122 nack\r\na=rtcp-fb:122 nack pli\r\na=rtcp-fb:122 ccm fir\r\na=rtcp-fb:122 goog-remb\r\na=rtcp-fb:122 transport-cc\r\na=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:7 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay\r\na=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=setup:actpass\r\na=mid:2\r\na=msid:- {c26f31da-7485-46d2-8076-085974eea64c}\r\na=sendonly\r\na=ice-ufrag:d2af540f\r\na=ice-pwd:b960cf3bcd5d61d70ba0352231efee23\r\na=ssrc:191380688 cname:{a2590e9d-ab23-4b7d-a240-b9771637c5df}\r\na=ssrc:3553358822 cname:{a2590e9d-ab23-4b7d-a240-b9771637c5df}\r\na=ssrc-group:FID 191380688 3553358822\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=bundle-only\r\n"
}

And these are offer and the same hardcoded answer on a working call from Chrome to an iOS device:

{
    "type": "offer",
    "sdp": "v=0\r\no=- 4187000013522082025 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=extmap-allow-mixed\r\na=msid-semantic:  WMS\r\na=group:BUNDLE 0 1 2\r\nm=audio 9 UDP/TLS/RTP/SAVPF 111\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=10;useinbandfec=1\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=rtcp-fb:111 transport-cc\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=setup:actpass\r\na=mid:0\r\na=msid:- 176d24ce-8d08-4f7d-976a-504ed62bba1d\r\na=sendonly\r\na=ice-ufrag:fFrY\r\na=ice-pwd:8a484ae89e1a85343b9d33808a652f93\r\na=fingerprint:sha-256 F3:F4:26:47:F0:3A:9C:F0:9C:5C:C0:5E:96:AB:5D:B8:7B:45:03:00:44:AC:2E:4F:30:7E:B2:4C:D4:31:62:9A\r\na=ice-options:trickle\r\na=ssrc:1275596850 cname:X3mfm62lBgk8xjbo\r\na=ssrc:1275596850 msid:- 176d24ce-8d08-4f7d-976a-504ed62bba1d\r\na=rtcp-mux\r\nm=video 9 UDP/TLS/RTP/SAVPF 108 109\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:108 H264/90000\r\na=rtpmap:109 rtx/90000\r\na=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f\r\na=fmtp:109 apt=108\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=rtcp-fb:108 goog-remb\r\na=rtcp-fb:108 transport-cc\r\na=rtcp-fb:108 ccm fir\r\na=rtcp-fb:108 nack\r\na=rtcp-fb:108 nack pli\r\na=extmap:14 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:13 urn:3gpp:video-orientation\r\na=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay\r\na=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type\r\na=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing\r\na=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id\r\na=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id\r\na=setup:actpass\r\na=mid:1\r\na=msid:- f266e2fd-4c81-48c0-9b3a-c6f5053d232e\r\na=sendonly\r\na=ice-ufrag:fFrY\r\na=ice-pwd:8a484ae89e1a85343b9d33808a652f93\r\na=fingerprint:sha-256 F3:F4:26:47:F0:3A:9C:F0:9C:5C:C0:5E:96:AB:5D:B8:7B:45:03:00:44:AC:2E:4F:30:7E:B2:4C:D4:31:62:9A\r\na=ice-options:trickle\r\na=ssrc:878407681 cname:X3mfm62lBgk8xjbo\r\na=ssrc:878407681 msid:- f266e2fd-4c81-48c0-9b3a-c6f5053d232e\r\na=ssrc:1588052075 cname:X3mfm62lBgk8xjbo\r\na=ssrc:1588052075 msid:- f266e2fd-4c81-48c0-9b3a-c6f5053d232e\r\na=ssrc-group:FID 878407681 1588052075\r\na=rtcp-mux\r\na=rtcp-rsize\r\nm=video 9 UDP/TLS/RTP/SAVPF 108 109\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:108 H264/90000\r\na=rtpmap:109 rtx/90000\r\na=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f\r\na=fmtp:109 apt=108\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=rtcp-fb:108 goog-remb\r\na=rtcp-fb:108 transport-cc\r\na=rtcp-fb:108 ccm fir\r\na=rtcp-fb:108 nack\r\na=rtcp-fb:108 nack pli\r\na=extmap:14 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:13 urn:3gpp:video-orientation\r\na=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay\r\na=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type\r\na=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing\r\na=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id\r\na=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id\r\na=setup:actpass\r\na=mid:2\r\na=msid:- a041f5d2-c5d0-49d6-b41e-b237c97b7301\r\na=sendonly\r\na=ice-ufrag:fFrY\r\na=ice-pwd:8a484ae89e1a85343b9d33808a652f93\r\na=fingerprint:sha-256 F3:F4:26:47:F0:3A:9C:F0:9C:5C:C0:5E:96:AB:5D:B8:7B:45:03:00:44:AC:2E:4F:30:7E:B2:4C:D4:31:62:9A\r\na=ice-options:trickle\r\na=ssrc:3345640908 cname:X3mfm62lBgk8xjbo\r\na=ssrc:3345640908 msid:- a041f5d2-c5d0-49d6-b41e-b237c97b7301\r\na=ssrc:3277484822 cname:X3mfm62lBgk8xjbo\r\na=ssrc:3277484822 msid:- a041f5d2-c5d0-49d6-b41e-b237c97b7301\r\na=ssrc-group:FID 3345640908 3277484822\r\na=rtcp-mux\r\na=rtcp-rsize\r\n"
}

{
    "type": "answer",
    "sdp": "v=0\r\no=server 1 1 IN IP4 str1-uswest2-104-193-186-207.addlive.io\r\ns=test\r\nt=0 0\r\na=setup:passive\r\na=ice-lite\r\na=fingerprint:sha-256 E9:1B:22:0E:40:9A:CE:C8:69:CF:86:84:31:95:A0:C7:89:C2:00:B3:C9:49:15:CF:98:CE:6B:CE:09:DC:02:4E\r\na=group:BUNDLE 0 1 2\r\nm=audio 443 UDP/TLS/RTP/SAVPF 111\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=40;useinbandfec=1\r\na=rtcp:443 IN IP4 0.0.0.0\r\na=rtcp-fb:111 transport-cc\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=setup:passive\r\na=mid:0\r\na=ptime:40\r\na=recvonly\r\na=ice-ufrag:kpzYmoK4BLPK+hPz\r\na=ice-pwd:d4ce8339cc01879cf168259f14ed3c3a\r\na=fingerprint:sha-256 E9:1B:22:0E:40:9A:CE:C8:69:CF:86:84:31:95:A0:C7:89:C2:00:B3:C9:49:15:CF:98:CE:6B:CE:09:DC:02:4E\r\na=ssrc:901502696 cname:36403\r\na=rtcp-mux\r\nm=video 443 UDP/TLS/RTP/SAVPF 99 98\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:99 H264/90000\r\na=rtpmap:98 rtx/90000\r\na=fmtp:98 apt=99\r\na=rtcp:443 IN IP4 0.0.0.0\r\na=rtcp-fb:99 transport-cc\r\na=rtcp-fb:99 nack\r\na=rtcp-fb:99 nack pli\r\na=rtcp-fb:99 ccm fir\r\na=rtcp-fb:99 goog-remb\r\na=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=setup:passive\r\na=mid:1\r\na=recvonly\r\na=ice-ufrag:kpzYmoK4BLPK+hPz\r\na=ice-pwd:d4ce8339cc01879cf168259f14ed3c3a\r\na=fingerprint:sha-256 E9:1B:22:0E:40:9A:CE:C8:69:CF:86:84:31:95:A0:C7:89:C2:00:B3:C9:49:15:CF:98:CE:6B:CE:09:DC:02:4E\r\na=ssrc:3167636275 cname:88714\r\na=rtcp-mux\r\nm=video 443 UDP/TLS/RTP/SAVPF 99 98\r\nc=IN IP4 0.0.0.0\r\na=rtpmap:99 H264/90000\r\na=rtpmap:98 rtx/90000\r\na=fmtp:98 apt=99\r\na=rtcp:443 IN IP4 0.0.0.0\r\na=rtcp-fb:99 transport-cc\r\na=rtcp-fb:99 nack\r\na=rtcp-fb:99 nack pli\r\na=rtcp-fb:99 ccm fir\r\na=rtcp-fb:99 goog-remb\r\na=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=setup:passive\r\na=mid:2\r\na=recvonly\r\na=ice-ufrag:kpzYmoK4BLPK+hPz\r\na=ice-pwd:d4ce8339cc01879cf168259f14ed3c3a\r\na=fingerprint:sha-256 E9:1B:22:0E:40:9A:CE:C8:69:CF:86:84:31:95:A0:C7:89:C2:00:B3:C9:49:15:CF:98:CE:6B:CE:09:DC:02:4E\r\na=ssrc:3606614340 cname:13705\r\na=rtcp-mux\r\n"
}

There seems to be a mismatch in H264 video codec payload in both Firefox and Chrome, though I'm not sure why it works in Chrome.
Andreas, wonder if you have any thoughts on this?

Flags: needinfo?(apehrson)

I think our code should allow this but it is not exactly trivial. I believe Daniel has been in that code recently so asking him.
Do note in the profile's logs I do see what looks like a SetLocalDescription with an empty sdp followed by a rollback, in case that brings with it any unexpected issues.

Flags: needinfo?(apehrson) → needinfo?(dbaker)

In regards to the error Answer had no codecs in common with offer in m-section 1. This seems to be an issue with how we are negotiating H264. The hard coded answer seems to exclude specifying a profile-level-id attribute in the SDP this is causing us issues. My understanding is that if no profile-level-id is present then baseline with level 1 is implied and probably a change we would need to make this work.

I wonder if updating the hardcoded answer to include a profile-level-id is possible as a work around until such change is made in Firefox and released.

Depends on: 1900114

Has anyone reached out to Snapchat about this?

From RFC 6184:

 If no profile-level-id is present, the Baseline profile, without additional constraints at Level 1, MUST be inferred.

Probably sdp_attr_get_fmtp_profile_id() just needs a default value

Flags: needinfo?(apehrson)

Perhaps bug 1900114 fixed this though

Without the fix in bug 1900114 we would not find a matching codec as we did not have a match for Baseline and only have been signaling constrained baseline.
There is one more fix still needed:
We are setting a default profile-level-id https://searchfox.org/mozilla-central/source/dom/media/webrtc/sdp/SdpAttribute.h#1296 when none is signaled, it's setting baseline with no constraints but an invalid level of 1.6. I'm correcting the level in bug 1901160 so we will properly infer baseline, without additional constraints and at level 1.

There are still other issues but this should resolve the problems with SDP parsing and matching codecs.

I assume we also have the other issue reported in comment 1:
Snaps - when taking snaps the resulting picture has incorrect aspect ratio and images appear skewed.

That and there are still errors for camera not being in permissions I believe bug 1609427 and I saw an error about getCapabilities may be bug 1179084.

Product is handling outreach for this issue afaik.

Flags: needinfo?(apehrson)
Depends on: 1886719
User Story: (updated)
User Story: (updated)
Depends on: 1609427

There are two snap features here we're dealing with - snaps (photos) and calling. Here's a bug breakdown for both -

snaps:
Bug 1286945 - Offer downscaled resolutions and decimated framerates in getUserMedia
This work has been on the team's todo list for a while. Resource constraints have prevented us from working on it.

calling:
Bug 1876865 - Difference in certificate fingerprint location in createOffer() output between Firefox and Chrome
This is an issue with the way snap does sdp parsing. We can 'do what chrome does' but their approach isn't optimal and changing this may well break other sites. Best handled through outreach.
Bug 1900114 - Firefox does not support H264 signaled without fmtp attributes AKA Basline
We landed this improvement but we have not shipped it to release (currently nightly only) because the change broke ring.com. Currently doing some outreach on that.
Bug 1892084 - Site breakage related to missing setCodecPreferences in RTCRtpTransceiver
Pretty sure this is already implemented.
Bug 1609427 - Add microphone and camera to PermissionDescriptor for navigator.permissions.query
Working on this project currently.
Bug 1179084 - Implement MediaStreamTrack::getCapabilities() and MediaTrackCapabilities
Needs to be implemented. Apparently a pretty small amount of work. Resource constraints are holding this up.

We have some contacts at Snapchat and have been exchanging emails with them.

Keywords: webcompat:needs-contact
User Story: (updated)
User Story: (updated)
Depends on: 1525241

Note the fix in -
Bug 1900114 - Firefox does not support H264 signaled without fmtp attributes AKA Basline
didn't ship to release due to a ring.com issue. We plan to address this and get this fixed in release.

Flags: needinfo?(dbaker)
Depends on: 1917127

We have a decent idea of what needs to happen next here on our side and snapchats side.

Keywords: webcompat:needs-diagnosis → webcompat:blocked, webcompat:platform-bug

Hey Jeff, why did we hook this bug up here?

Bug 1525241 - getFingerprints() method is missing from the Certificate returned by RTCPeerconnection.generateCertificate()

I think we wanted -

Bug 1876865 - Difference in certificate fingerprint location in createOffer() output between Firefox and Chrome

which we fixed with a one-off fix for snap chat.

Flags: needinfo?(jmuizelaar)

In our thread with Snapchat they wrote "This works in Chrome but not in FF due to missing certificate.getFingerprints(). Are there plans to implement it?"

Flags: needinfo?(jmuizelaar)
Alias: snapchat
Webcompat Priority: --- → P1
Webcompat Score: --- → 10
Depends on: 1952183
Webcompat Score: 10 → 9
Type: defect → task
User Story: (updated)

We have reached out to Snapchat regarding their support for Firefox after changes we have made to get calling to work. John Krzemien responded with the below which seems to indicate this has not been a priority for them yet.

Unfortunately we haven't had a chance to look into this as our priorities shifted this quarter. We can revisit this later in the year as we evaluate our teams prioritization.

Thanks, 
John

We may need to consider implementing a site specific intervention to spoof the UA to enable calling in Snapchat while we wait for them to no longer block this feature from Firefox.

Yeah, spoofing probably makes sense at this point.

Keywords: webcompat:needs-sitepatch
User Story: (updated)
User Story: (updated)
Keywords: leave-open
Assignee: nobody → twisniewski
Status: NEW → ASSIGNED
Pushed by twisniewski@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/5eec84f533b7 https://hg.mozilla.org/integration/autoland/rev/596a9586dbf0 add a nightly-only, desktop-only UA override for Snapchat; r=webcompat-reviewers,ksenia
User Story: (updated)
Webcompat Score: 9 → 5
Webcompat Priority: P1 → P2

We haven't received any feedback, so let's ship the intervention to beta as well as nightly and see if anyone notices any problems.

Pushed by twisniewski@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/31fd8e987056 https://hg.mozilla.org/integration/autoland/rev/1b3aec3ad6ed also ship our UA override for Snapchat to beta; r=denschub,webcompat-reviewers
User Story: (updated)
Webcompat Score: 5 → 4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: