SharpRTSP icon indicating copy to clipboard operation
SharpRTSP copied to clipboard

RTSP Server Side implementation of RTSP over HTTP for RtspCameraExample

Open RogerHardiman opened this issue 1 year ago • 3 comments

Hi I can see SharpRTSP has code to be a client of a RTSP over HTTP Server. I want to add support for RTSP over HTTP and RTSP over HTTPS to the RTSP Server code and test with RtspCameraExample

I wanted to check if anyone has tried this already or if there are any forks worth looking at.

I've already done the research and read the Apple mini spec.

I wanted to keep this on the same port as a RTSP connection so will handle RTSP and the HTTP connection on the same port (eg 8554) I'd like to keep the rest of the RTSP Server code reading from a Stream.

So I think I need to write some code that will sit between the TCP Server Connections and the Stream Read/Write functions which are written to Read and Write RTSP messages to a stream.

My new code would need to read data from the TCP Socket, and if it is a RTSP message, just pass data straight through. If the data read from the TCP socket is a HTTP Header, I need to respond and wait for the 2nd HTTP connection with the correct GUID and then pass data read from the HTTP connection to the stream the exisitng RTSP Sharp code uses and handle Stream Writes from the existing Sharp RTSP code.

So just wanted to check if anything has been tried already.

Thanks Roger

RogerHardiman avatar Sep 20 '24 19:09 RogerHardiman

Hi,

I have think a little about adding RTSP over HTTP for the server side but I did not start to code. I think that using the same port for standard RTSP and RTSP over HTTP will make it a lot harder but it may be faisable, maybe you can try to make a dedicate RTSP over HTTP and add passthrough after for classic RTSP .

My thought was to make a new class (called something like RtspHttpListerner) to replace/wrap TcpListener and when it AcceptTcpClient, it check the different case

  • POST request : it handle the HTTP response manage a list of x-sessioncookie and return a new RtspHttpServerTransport with a reference to a concurrent dictionary where we add the response channel, and a reference to the TcpClient stream
  • GET request : it handle the HTTP response, add the TcpClient stream to the dictionary of response channel with x-sessioncookie as key.

RtspHttpServerTransport will implement IRtspTransport, it return a special stream where all the magic happen (like RtspHttpTransport). This stream need to implement :

  • Read where the base64 decode happen (not sure how to detect end of message).
  • Write will search the TCP client in the dictionary to write if do not have one (block if not found ? with a timeout ?) and simply write to the TcpClient stream.
  • Flush simply flush the TcpClient stream. (see RtspHttpTransport.HttpTransportStream to see what need to be implemented)

One subject I am not sure : can the client open new TCP connection to send a new POST for the same stream, using the same x-sessioncookie. If it is the case the RtspHttpListerner must maintain a dictionary of request channel and RtspHttpServerTransport must check this dictionary when the current channel is closed.

I think HTTPS can be added after if we have protected method to get the stream in the RtspHttpListerner, or we can ask user to use an external proxy.

Nicolas

ngraziano avatar Sep 21 '24 10:09 ngraziano

Hi. Thanks for the suggestions. I agree it would be easier to have a different port and if I get stuck, I may try that first and make a little internal socket connection from the HTTP server to the RTSP Server port to forward the Stream once the tunnel is established.

But I've started with some additions to RtspTcpTransport and a custom Stream Class so I can implement a PeekLine() function but it will probably make the existing class too messy. It is a good idea to overload the TcpClient class with some extra Stream magic - including a StreamPeak.

I had avoiding doing the TcpClient because the TLS/SSL negotiation is done deeper into SharpRTSP in a GetStream() function so I'd need to do the TLS/SSL negotiation in the TcpClient so that I could add a PeakLine to see what the first bytes of the Socket contain (RTSP or HTTP)

If get stuck I'll do it on a different port and open an internal socket to the existing RTSP code.

When I have something working I'll push it to my fork and let you know.

Many thanks Roger

RogerHardiman avatar Sep 21 '24 16:09 RogerHardiman

I had some time so I made a first version of RTSP over HTTP but for now I do not try to put it on the same port.

ngraziano avatar Aug 18 '25 14:08 ngraziano