> On Dec 15, 2021, at 12:35 PM, Laszlo Ast <a...@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/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
