Support for RTSP over HTTP

[Sanctus-dev]

Hi, I'm looking for solutions to use YARP in contexts where supporting "RTSP over HTTP(S)" is a requirement.

Some short background to this protocol. Apple first published a semi-official specification on how to traverse RTSP/RTP data RFC2326 over firewalls using HTTP tunnels. The specification is now part of ONVIF, a specification used by many IP camera manufactures and Video Management Systems.

Basically the specification uses two long-lived GET and POST HTTP requests to stream media data and perform media control.

The underlying RTSP over HTTP specification requires to open separate communication channels for continously sending and receiving data. For sending media from RTSP server to client the communication channel is opened with a GET request and a response without content-length. For sending media to the server a POST request is used. The specification notes that a content-length must be sent. Most applications use the value 32767 from the example given in the specification. Since http/2 streams may be closed by either side when the content-length has been reached clients shall use a value large enough for the connection life time.

I was not able to get this working with YARP. It seems like the GET request gets stuck in a response-body-copying phase. Typically, there will be NO content data on the GET channel until both the GET and POST channels have been established and a "DESCRIBE" command has been posted on the POST channel.

Is it a lost cause to try to get this playing?

[MihaZupan]

If the traffic is valid HTTP, I don't see why it couldn't work.
If you have multiple destinations behind the proxy, you might have to ensure that load balancing doesn't distribute the two requests to different backend servers.
You may also have to check that the right HTTP version is being used if all peers expect a specific version.

The first spec you linked mentions

"All POST requests are required to have a content-length header by HTTP. In practice the actual value seems to be ignored by proxy servers, so it's possible to send more than this amount of data"

This is just wrong, doing so is a protocol violation, and won't work with ASP.NET/YARP. You should be able to check if something like that is happening by looking at a network trace for example.

[Sanctus-dev]

So I've been fiddling around with this for a while now and I managed to progress a little bit - much thanks to the Flush call. The client now manages to to initiate the two requests (GET/POST) and send the initial request but for some reason the server never post a reply on the GET channel. Eventually the client will timeout.

I'm trying to compare network-traces and understand what differs, One obvious difference is that the proxy enables chunked transfer encoding which makes the request payload not match exactly - I'm unsure if the server supports this. Is it possible to turn it off?

[MihaZupan]

If you suspect chunking may be a problem, you could try lying to the server and set a huge Content-Length header (e.g. 1 TB).
This will mean every request will involve an exception at some point (we never reach the end), but it may work if the server is (erroneously) expecting a raw data stream.

[Sanctus-dev]

@MihaZupan - I mostly tested by removing the content-length header on the POST request - that has been the most promising approach. If I keep or change the content-length I get errors from the proxy, e.g.
"System.InvalidOperationException: Sent 226 request content bytes, but Content-Length promised 32767"

To summarize my approach so far:

For the GET request:

• AddResponseTransform
• responseContext.HttpContext.Response.Body.FlushAsync()

For POST request:

• AddRequestTransform
• Create new MemoryStream
• Peak and copy the request body stream to the MemoryStream until end of the first RTSP-request is found (see details below)
• Flush the StreamWriter
• Set MemoryStream.Position to 0
• Set requestContext.HttpContext.Request.Body = MemoryStream

Determining the end of the a RTSP request is a bit tricky since the request-data is base64-encoded. You need to continuously decode the stream looking for double line-breaks ("\r\n\r\n").

My first goal is to get the response of the first RTSP-request back on the GET-channel.
The next goal would be to get this to work with multiple RTSP-requests.

[MihaZupan]

Any luck with collecting network traces with & without the proxy?

You only have two ways of sending the request content - Content-Length, or chunked.
If you suspect chunking is the problem, lying about the content length is the only option. The "Sent X request content bytes, but Content-Length promised Y" are the errors I was referring to that you would always see if you do so, but they may be harmless in your case.

[galvesribeiro]

I've been looking at this myself. I have a DVR which support ONVIF and exports all 32 chambers (coax) connected on it on the ONVIF response. However, the ONVIF client that I have (Ubiquiti Unifi Protect NVR) expect that each camera to have its own IP (yeah they are wrong and not 100% implementing ONVIF).

So, what I was thinking of, is to have an application with YARP which would listen to multiple hosts (DNS, IP, URL path, whatever) and redirect It to a mapped channel on this single DVR, proxying and formatting the parameters in order to make this proxying.

All we care right now is the camera feed. Will keep an eye here and report back what I've found while experimenting with YARP in this scenario.