Support RTSP 1.0 RFC

[saschwan]

Context

Please select one:

• I use the docker image ullaakut/cameradar
• I use my own build of the docker image
• I use the pre-compiled binary
• I use my own build of the binary
• None of the above / I don't know

Please select one:

• I use a specific version:
• I use the latest commit of the master branch
• I use the latest commit of the develop branch
• I use a forked version of the repository:
• I use a specific commit:

Environment

My operating system:

• Windows
• OSX
• Linux
• Other

OS version: 10.15.7
OS architecture:

Issue

What was expected

I know the correct RTSP URL to the camera and the route exists in the route directory. Finds the corrects IP address and username/password combination for the IP camera but the RTSP URL cannot be found.

What happened

Using VLC, the URL 'rtsp://office:[email protected]:554/stream1' connects to the camera's stream and I can view it. However, when I run camaradar it cannot connect to the exact same RTSP although it clearly attempts to use the /stream1 route to connect to it.

Also, the suggested device model seems to be wrong. It's a Tapo C200 camera

✖	Admin panel URL:	http://192.168.1.235/ You can use this URL to try attacking the camera's admin panel instead.
	Available:		✖
	Device model:		DoorBird video doorbell rtspd

	IP address:		192.168.1.235
	RTSP port:		554
	Auth type:		digest
	Username:		office
	Password:		123456
	RTSP routes:

Logs

*   Trying 192.168.1.235...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x22afda0)
* Connected to 192.168.1.235 (192.168.1.235) port 554 (#0)
* Server auth using Digest with user 'office'
> DESCRIBE rtsp://office:[email protected]:554/stream1 RTSP/1.0
CSeq: 1
Accept: application/sdp

* Empty reply from server
* The CSeq of this request 1 did not match the response 0
* Connection #0 to host 192.168.1.235 left intact

[Ullaakut]

Hi @saschwan !

Thanks for reporting this issue. From the logs, it seems like the problem stems from the fact that the server does not answer to RTSP DESCRIBE requests properly.

The problem seems similar to #142 (comment) but I can't really confirm without testing it myself or getting similar info to what's in the mentioned issue.

Some cameras use outdated or specific RTSP frameworks that do not properly or do not completely implement the RTSP RFC.

VLC has lots of specific code to deal with pretty much all cases, but it's something that Cameradar can't reliably do unless it tries to actually access the RTSP streams, which would make it much more complex and much slower :/

Let me know if you want me to investigate further!

[saschwan]

Hey @Ullaakut

Thanks a lot for the response and clarifications. I do understand the issue now with RTSP 2.0 being published as RFC.

I have been using an ONVIF camera discovery tools to find the IP cameras which has been successful and reliable with tests on 10 different IP camera types, especially with the node library https://github.com/futomi/node-onvif. With a quick search, the Go library https://godoc.org/github.com/deepch/go-onvif#Device.GetStreamURI has similar methods. It could be interesting to implement such functionality into the tool to catch RTSP 1.0 devices (and even discover new stream routes).

[Ullaakut]

It's a good idea and definitely doable 👍 I'll switch this issue to a feature request for RTSP 1.0 support then if you don't mind?

[ilmari-lauhakangas]

This new lib might help: https://github.com/bluenviron/gortsplib "RTSP 1.0 client and server library for the Go programming language"