RTSP SETUP command parsing problem

[RogerHardiman]

Which version are you using?

Current Master branch (5th Jan 2024) Building from source.

Which operating system are you using?

• [x] Linux amd64 standard
• [x] Linux arm64 Docker

Describe the issue

MediaMTX's RTSP code is not accepting the SETUP command from a Grandstream device (GXV3500)

The Grandstream RTSP code is terrible and buggy. I had a hard time making it work with SharpRTSP (I'm a developer on that project) and I'm trying to get it working with MediaMTX for another project. MediaMTX has already had two other Grandstream workarounds applied.

Quick Fix.... The quick fix is to ignore Authentication Headers in the SETUP message. MediaMTX already ignores any Authentication Headers in the PLAY message, but in SETUP it checks the RTSP Header. The problem is that Grandstream returns garbage data.

Problem 1 In SETUP they use the Base URI in the Digest Header and the Control/Track URI in the RTSP Message

SETUP rtsp://192.168.26.61:8554/stream1/trackID=0 RTSP/1.0
Authorization: Digest username="admin", realm="IPCAM", nonce="830280a6c0a1be48aa04bba6b9729b3e", uri="rtsp://192.168.26.61:8554/stream1", response="0f63873862a16f3e114d2af938fee3ab"
CSeq: 5
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: Grandstream RTSP 1.0

Problem 2 If I use the RTSP Message URI or the Digest Header URI, I am not able to compute a matching MD5 hash, so whatever Grandstream are using to compute Digest->response is unknown.

The quick fix is to bypass Digest Authentication checking for SETUP. (you don't do it for PLAY. If you did I would expect we will find even more Grandstream problems)

Describe how to replicate the issue

1. start the server
2. publish with ffmpeg - video only

3. read with Grandstream decoder - of which I have two on my desk

Did you attach the server logs?

Partial logs- just the SETUP commands

Did you attach a network dump?

No

UPDATED A Pull Request has been made. I've actually made two different fixes for consideration a) I've done a Pull Request at the MediaMTX level in the SETUP message hander PR #2882 b) I've done a different Pull Request in gortsplib [https://github.com/bluenviron/gortsplib/pull/495]

Either one works for me. I've done both so you can decide if you want to fix it at the MediaMTX level or the gortsplib level

Thanks Roger

[aler9]

Hello, the two PRs you sent basically allowed anyone to read anything and so they could not be merged.

While it's true that the authentication header is not checked on PLAY, it's only possible to use PLAY after a session has been established with SETUP. Therefore it's enough to check the authentication header during SETUP and then relying on the Session header.

In my opinion, this issue can be solved by relaxing the condition on the URI contained in the Authorization header sent from the Grandstream to the RTSP server. Something similar has been done in case of VLC. If you provide a full server log with option logLevel set to debug, we'll have enough material to start working.

[RogerHardiman]

Hi. Thanks for the feedback and the quick response and I can add a fix into gortsplib like the VLC workaround for the difference in the URIs

But there is a larger problem that I have not been able to compute a matching MD5 Hash from either of the two URIs that are in the SETUP message. So the Digest Hash comparison fails.

You mentioned not needing to authenticate PLAY because you need to have completed a SETUP first.

Would you consider a PR where I skip the authentication on SETUP if we have already authenticated the TCP connection via another RTSP message eg OPTIONS or DESCRIBE.

This would avoid the security issue you spotted of setting the user agent to Grandstream and going directly into a SETUP (if you already know the contents of the DESCRIBE SDP and the Control Tracks)

I'll get the logs over.

Thanks