I'm working on WebRTC streaming which streams video from a device to a browser. This streaming works in Chromium browsers just fine but fails in Firefox. There is a failure with the SDP exchange which then halts the rest of the connection (no ICE candidates sent after SDP exchange).
There are some issues with Firefox's answer SDP I've found but I haven't discovered a reason for the issues: SDP mentions VP8 but we use H264 only; m=video 0 has port 0 but typically that's non zero; I typically get an a=inactive line; a=sendrecv should probably be a=recvonly; many other lines are missing (for example, ICE-specific lines)
SDP examples below:
Example SDP offer from the device while using Firefox (Chrome has a similar format):
v=0
o=- 1709142607078008990 0 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle
a=group:BUNDLE video0
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:3/ygyy34xZMRXsru4Z1KuPht0mJvnSqj
a=ice-pwd:0stYVWAG9GKvu+vwp8v5ZRU+WaBdIoGp
a=rtcp-mux
a=rtcp-rsize
a=sendrecv
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack pli
a=framerate:9
a=fmtp:96 packetization-mode=1;profile-level-id=4d4016;sprop-parameter-sets=Z01AFo2NQFAX/LgLcBAQFAAAD6AAARlDoYAL/wAD0JLvLjQwAX/gAHoSXeXCgA==,aO44gA==
a=ssrc:984898564 msid:user2537555540@host-7396b709 webrtctransceiver30
a=ssrc:984898564 cname:user2537555540@host-7396b709
a=mid:video0
a=fingerprint:sha-256 2D:05:6B:57:E7:93:01:DE:CA:BB:57:EE:93:F6:28:3F:1A:96:5D:E9:EC:CB:33:EF:2F:96:DE:68:F0:F7:D2:98
Example SDP answer from Firefox, with comments pointing out questionable lines:
v=0
o=mozilla...THIS_IS_SDPARTA-88.0 4439569731226206324 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv // Often or always is recvonly in other browsers, not sendrecv
a=fingerprint:sha-256 7A:C6:F8:FF:57:1E:E5:63:86:09:A2:CB:38:ED:59:45:7D:06:63:B8:68:0A:71:89:18:54:85:59:22:8A:DD:A7
a=ice-options:trickle
a=msid-semantic:WMS *
m=video 0 UDP/TLS/RTP/SAVPF 120 // Why is the port 0?
c=IN IP4 0.0.0.0
a=inactive // This seems incorrect
a=mid:video0
a=rtpmap:120 VP8/90000 // This should be H264
For comparison, here is an answer SDP from Chrome which streams successfully:
v=0
o=- 4481503930448229400 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video0
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 96 // Port 9 used here
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:U/NT
a=ice-pwd:KVGFr/KEWwTJfam3FXRuKn98 // There are more ICE values here
a=ice-options:trickle
a=fingerprint:sha-256 98:D9:7D:22:7C:BB:00:58:73:20:F1:91:C1:F4:1E:D8:AE:1F:FE:60:57:5C:27:68:EF:17:BB:C6:93:65:76:73
a=setup:active
a=mid:video0
a=recvonly // recvonly instead of sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 H264/90000 // Using H264
a=rtcp-fb:96 nack pli
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0015
I initially tried SDP munging with the Firefox SDP answer to manually add H264 into my local answer in Firefox, but that doesn't fully work because there are many other required ICE values that I probably can't fake. At this point I'm wondering if the offer from the device needs any updated values that will specifically work with Firefox, but I'm unsure what those would be. Possibly the a=mid:video0 since it has the trailing 0, but why would Chrome work and return the same value? Possibly the profile-level-id, though I'm not sure how much that affects.
Anyone know what issue could be happening here and what fixes might be required?
Firefox likely doesn't support the profile level id 0x4d4016. Then you have no codecs in common and the media is rejected (which is what port 0 means). Without any non-rejected m-line your connection will fail.