gortsplib
gortsplib copied to clipboard
bluenviron
Add RTSP-over-HTTP support
This PR adds support for Apple's lesser-known RTSP-over-HTTP for #323 and #433.
It's also written keeping in mind that some cameras also do RTSP over websocket (for whatever insane reason) so in the future we can still add ws:// protocol support via a websocket tunnel too.
The specification is here.
PR is currently a draft as I'd like to test this on a few more cameras/servers but happy to receive comments or thoughts as it is now.
Nice work. I spotted one potential problem as I made the same mistake myself when I wrote some RTSP over HTTP code on a C# project (I work on SharpRTSP)
Your code replies with HTTP/1.1
reqStr := fmt.Sprintf("%s %s HTTP/1.1\r\n", method, url)
The Apple Spec says the reply is HTTP/1.0 and I had one commercial VMS vendor check specifically for HTTP/1.0 and reject my implementation.
However that VMS vendor then went on to remove the strict HTTP/1.0 specific check from their code and I don't think ffmpeg or ONVIF Device Manager cared when it said HTTP/1.1
So you don't have to change it, but just wanted to mention the problems I had last year.
Also the link to the spec in this PR only rendered Page 1 and Page 6 for me in Edge. Other pages were blank.
Wikipedia's RTSP-over-HTTP chapter (which I wrote) points to a working copy here... https://web.archive.org/web/20240215060448/https://opensource.apple.com/source/QuickTimeStreamingServer/QuickTimeStreamingServer-412.42/Documentation/RTSP_Over_HTTP.pdf
Minor update on this PR, it turns out finding a good RTSP-over-HTTP server itself is not trivial. The one RTSP-over-HTTP camera I was using is turning out to not be so reliable. If anyone has any suggestions on that front, would love to test against a more reliable server.
One thing that came into my mind when developing the SRTP feature, that might also be of help here: in case of HTTP and WS, i think it's better not to add an additional transport protocol (TransportHTTP) but rather an additional internal flag,.
RTSP should be characterized by a set of independent parameters, like:
- scheme (either RTSP or RTSPS)
- protocol (either TCP, UDP or UDP-multicast)
- is secure (whether SRTP/SRTCP are in use)
- is http-tunnelled
- is websocket-tunnelled
We can still prevent some invalid configurations (like UDP + HTTP-tunnelled) but other than that, this should cover any current and future setup.
