[Live-devel] RTSP over HTTPS tunneling

[Ross Finlayson]

> On Dec 15, 2021, at 12:35 PM, Laszlo Ast <ast at netavis.hu> wrote:
> 
> > When I recently added RTSP-over-TLS support to our RTSP server implementation, it wasn’t intended to also support RTSP-over-HTTPS.  But perhaps this is working by (happy) accident?
> No, that is RTSPS that you mention, which adds TLS to the RTSP part (which can also incorporate RTP/RTCP in the same single TCP connection if interleaved packets are used).
> But it does not use the specific HTTP tunneling mechanism, that always requires 2 connections.

That’s what I thought.  I may add support for client-side RTSP-over-HTTPS sometime in the future, but (in order to test this properly) I won’t do so until I also implement this in our RTSP server.  This will have to wait until sometime in the new year (as I plan on adding support for server-side SRTP first).


> It seemed to me from the comments, and from the man page of connect(), that on a nonblocking socket after calling connect() and select(), one is advised to check SO_ERROR.
> In case of HTTP tunneling, the connection handler is entered twice: first for the GET connection, and later for the POST connection.
> The second time it happens when select() indicates that fOutputSocketNum became ready, and it is not about sent or received data, it is about the connect() call.
> Without the patch, we call the connection handler after the POST connection is opened on fOutputSocketNum, but we still check getsockopt() on fInputSocketNum.

OK, thanks for the clarification.  I’ll look into this.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/