Failed to apply the description for m= section with mid='1': Failed to setup RTCP mux.'

neilyoung commented 6 months ago

Which version are you using?

v1.8.2

Which operating system are you using?

[x ] Linux amd64 standard
[ ] Linux amd64 Docker
[ ] Linux arm64 standard
[ ] Linux arm64 Docker
[ ] Linux arm7 standard
[ ] Linux arm7 Docker
[ ] Linux arm6 standard
[ ] Linux arm6 Docker
[ ] Windows amd64 standard
[ ] Windows amd64 Docker (WSL backend)
[ ] macOS amd64 standard
[ ] macOS amd64 Docker
[ ] Other (please describe)

Describe the issue

I'm using a JS client, doing WHIP/WHEP with MediaMTX. This works since months. Today I tried the latest version and ran into this problem: Fetching a video via WHEP suddenly gives this error:

'InvalidAccessError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote answer sdp: Failed to apply the description for m= section with mid='1': Failed to setup RTCP mux.'

Description

Describe how to replicate the issue

We need to agree on a debug session for details

Did you attach the server logs?

yes / no

Did you attach a network dump?

no

I have double checked this with an older version, forked from 1.6.0. There the ANSWER from MediaMTX is not causing a problem.

This is the 1.8.2 WHEP ANSWER forwarded to Chrome's WebRTC, causing the error (anonymized):

v=0
o=- 491515685643552065 1716466204 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 42:C8:C6:DF:4F:91:F5:A1:99:30:45:6F:88:D1:0F:5D:14:B0:3C:F8:5F:0A:17:56:BF:2C:C5:32:09:4B:4C:88
a=extmap-allow-mixed
a=group:BUNDLE 1
m=audio 0 UDP/TLS/RTP/SAVPF 0
c=IN IP4 0.0.0.0
a=candidate:699849915 1 udp 2130706431 172.31.4.10 8189 typ host
a=candidate:699849915 2 udp 2130706431 172.31.4.10 8189 typ host
a=candidate:2315654360 1 udp 2130706431 100.77.36.84 8189 typ host
a=candidate:2315654360 2 udp 2130706431 100.77.36.84 8189 typ host
a=candidate:3861566883 1 udp 1694498815 xx.xx.xx.xx 38990 typ srflx raddr 0.0.0.0 rport 38990
a=candidate:3861566883 2 udp 1694498815 xx.xx.xx.xx 38990 typ srflx raddr 0.0.0.0 rport 38990
a=candidate:3782576977 1 udp 16777215 xx.xx.xx.xx 49688 typ relay raddr 0.0.0.0 rport 39133
a=candidate:3782576977 2 udp 16777215 xx.xx.xx.xx 49688 typ relay raddr 0.0.0.0 rport 39133
a=end-of-candidates
m=video 9 UDP/TLS/RTP/SAVPF 106
c=IN IP4 0.0.0.0
a=setup:active
a=mid:1
a=ice-ufrag:diZaIgQppkbXpKXV
a=ice-pwd:bpHCkISkMIcStBmcaNHguNLuZLBPuiMi
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:106 H264/90000
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtcp-fb:106 goog-remb 
a=rtcp-fb:106 transport-cc 
a=rtcp-fb:106 ccm fir
a=rtcp-fb:106 nack 
a=rtcp-fb:106 nack pli
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=ssrc:1742775820 cname:mediamtx
a=ssrc:1742775820 msid:mediamtx video
a=ssrc:1742775820 mslabel:mediamtx
a=ssrc:1742775820 label:video
a=msid:mediamtx video
a=sendonly

The input stream is produced by NVIDIA DeepStream 7.0 SDK, encoded using nvh264enc. I can fetch the stream via FFPLAY without problem.

The way of my video is: I'm sending it via WHIP from my PC to MediaMTX. There an AI inference process is started, which in turn delivers annotated video back to the local MediaMTX, from which I fetch that with WHEP.

There is also no problem if I fetch the original video with my WHEP client. The answer in that case is:

v=0
o=- 6095146103556255689 1716466341 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 F5:4C:A7:AA:D4:5E:7C:E9:C3:19:8D:FF:33:66:3A:DA:3B:2B:BE:3F:55:F4:76:32:9C:CE:17:48:31:E4:06:99
a=extmap-allow-mixed
a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=setup:active
a=mid:0
a=ice-ufrag:aNrpuVCoTPnmvCNw
a=ice-pwd:cINIHUjAxdSbsQPzWfrFMzbWFMJEnmWX
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=rtcp-fb:111 transport-cc 
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=ssrc:3214820605 cname:mediamtx
a=ssrc:3214820605 msid:mediamtx audio
a=ssrc:3214820605 mslabel:mediamtx
a=ssrc:3214820605 label:audio
a=msid:mediamtx audio
a=sendonly
a=candidate:699849915 1 udp 2130706431 172.31.4.10 8189 typ host
a=candidate:699849915 2 udp 2130706431 172.31.4.10 8189 typ host
a=candidate:2315654360 1 udp 2130706431 100.77.36.84 8189 typ host
a=candidate:2315654360 2 udp 2130706431 100.77.36.84 8189 typ host
a=candidate:3861566883 1 udp 1694498815 xx.xx.xx.xx 34970 typ srflx raddr 0.0.0.0 rport 34970
a=candidate:3861566883 2 udp 1694498815 xx.xx.xx.xx 34970 typ srflx raddr 0.0.0.0 rport 34970
a=candidate:3782576977 1 udp 16777215 xx.xx.xx.xx 59565 typ relay raddr 0.0.0.0 rport 35953
a=candidate:3782576977 2 udp 16777215 xx.xx.xx.xx 59565 typ relay raddr 0.0.0.0 rport 35953
a=end-of-candidates
m=video 9 UDP/TLS/RTP/SAVPF 106
c=IN IP4 0.0.0.0
a=setup:active
a=mid:1
a=ice-ufrag:aNrpuVCoTPnmvCNw
a=ice-pwd:cINIHUjAxdSbsQPzWfrFMzbWFMJEnmWX
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:106 H264/90000
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtcp-fb:106 goog-remb 
a=rtcp-fb:106 transport-cc 
a=rtcp-fb:106 ccm fir
a=rtcp-fb:106 nack 
a=rtcp-fb:106 nack pli
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=ssrc:3359672409 cname:mediamtx
a=ssrc:3359672409 msid:mediamtx video
a=ssrc:3359672409 mslabel:mediamtx
a=ssrc:3359672409 label:video
a=msid:mediamtx video
a=sendonly

Would you know, how to narrow this down?

aler9 commented 6 months ago

hello, yes, this error may happen, but the MediaMTX version you are using is not v1.8.2, but the latest code commit which is not yet part of a release.

neilyoung commented 6 months ago

Indeed, I think I pulled the latest version from git and derived the version number from the release page. You think your binary 1.8.2 doesn't have this problem?

github-actions[bot] commented 5 months ago

This issue is mentioned in release v1.8.3 🚀 Check out the entire changelog by clicking here

bluenviron / mediamtx