WebRTC source bad Content-Type -- got 'application/sdp; charset=utf-8'

[fusetim]

Which version are you using?

v1.7.0

Which operating system are you using?

• Linux amd64 standard
• Linux amd64 Docker (bluenviron/mediamtx:latest)
• 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 currently trying mediamtx, and I wanted to try the WHEP ingest function.
To do so, I used VDO.Ninja service, that is known to work very well as a WebRTC streaming service.
Unfortunately, this service responds to WHEP resquests with the following Content-Type header: application/sdp; charset=utf-8.
Mediamtx does not like it, as it expects exactly application/sdp as Content-Type, and the content is not retrieved.

Describe how to replicate the issue

Add this snippet to the mediamtx configuration:

paths:
  vdoninja:
    source: wheps://whep.vdo.ninja/p827NUkn
    sourceFingerprint: 37D9BBAC4946965FE430AD3AA2822ACCEE6D604056B03E5913C1BF94F3881ACE

After launching the stream using VDO.Ninja -- Host a VDO.Ninja stream as a WHEP source with the WHEP token p827NUkn, and starting the mediamtx container, it fails with the following message:

ERR [path vdoninja] [WebRTC source] bad Content-Type: expected 'application/sdp', got 'application/sdp; charset=utf-8'

Did you attach the server logs?

$ docker run --rm -it --network=host -v $PWD/mediamtx.yml:/mediamtx.yml bluenviron/mediamtx                                                  36.3s  ven. 19 avril 2024 09:48:37
2024/04/19 07:48:40 INF MediaMTX v1.7.0
2024/04/19 07:48:40 INF configuration loaded from /mediamtx.yml
2024/04/19 07:48:40 DEB [path vdoninja] created
2024/04/19 07:48:40 DEB path manager created
2024/04/19 07:48:40 INF [RTMP] listener opened on :1935
2024/04/19 07:48:40 INF [WebRTC] listener opened on :8889 (HTTP), :8189 (ICE/UDP)
2024/04/19 07:48:40 INF [SRT] listener opened on :8890 (UDP)
2024/04/19 07:48:40 INF [path vdoninja] [WebRTC source] started
2024/04/19 07:48:40 DEB [path vdoninja] [WebRTC source] connecting
2024/04/19 07:48:43 DEB [path vdoninja] [WebRTC source] peer connection state: closed
2024/04/19 07:48:43 ERR [path vdoninja] [WebRTC source] bad Content-Type: expected 'application/sdp', got 'application/sdp; charset=utf-8'
2024/04/19 07:48:48 DEB [path vdoninja] [WebRTC source] connecting
2024/04/19 07:48:51 DEB [path vdoninja] [WebRTC source] peer connection state: closed
2024/04/19 07:48:51 ERR [path vdoninja] [WebRTC source] bad Content-Type: expected 'application/sdp', got 'application/sdp; charset=utf-8'
^C2024/04/19 07:48:55 INF shutting down gracefully
2024/04/19 07:48:55 INF [SRT] listener is closing
2024/04/19 07:48:55 INF [WebRTC] listener is closing
2024/04/19 07:48:55 INF [RTMP] listener is closing
2024/04/19 07:48:55 DEB path manager is shutting down
2024/04/19 07:48:55 INF [path vdoninja] [WebRTC source] stopped: path is closing
2024/04/19 07:48:55 DEB [path vdoninja] destroyed: terminated
2024/04/19 07:48:55 INF waiting for running hooks

Did you attach a network dump?

no

why? the network traffic is encrypted with TLS, therefore, we cannot observe the headers/data transmitted.

Others

I might create a PR if I have the time and if I figure out a solution to this issue.

[fusetim]

Suggested changes:

• Remove this line

  mediamtx/internal/protocols/webrtc/whip_client.go

  Line 288 in 2bd8ac7

  if contentType != "application/sdp" {

• Replace it with a check for strings.Trim(strings.Split(contentType, ";")[0]) != "application/sdp"

[fusetim]

#3274 helps but unfortunately it stiil does not work with VDO.ninja. The next error is:

2024/04/19 10:03:58 ERR [path vdoninja] [WebRTC source] wrong Accept-Patch: expected 'application/trickle-ice-sdpfrag', got ''

It certainly necessitates another issue, but I'm unsure if it is an error of mediamtx or VDO.Ninja.

[aler9]

Thanks for reporting the new WHIP/WHEP feature of vdo.ninja. The second blocking issue is fixed by #3277

[github-actions]

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

[fusetim]

Thanks for reporting the new WHIP/WHEP feature of vdo.ninja. The second blocking issue is fixed by #3277

Thank you for your responsiveness and your great work on mediamtx.