<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">> I might end up adding this functionality sometime in the future. But I’m curious: Does our existing RTSP server implementation support RTSP-over-HTTPS?
I don't think so, but I have to admit, I was mainly interested in the client side, so I haven't checked it extensively.
> 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.
> Or are you using some other RTSP server implementation to test your modified client?
I tested the code using IP cameras whenever it was possible, and different tricks (socat and RTSP proxies) when a given camera didn't support the combination of specific streaming options.
The RTSP over HTTPS case has the significance, that ONVIF profile S compliant IP cameras have to support RTP/UDP and RTP/RTSP/HTTP/TCP media transport, and most of the time, HTTPS is also supported.
On the other hand, it seems to be more difficult to find a camera with RTSPS support. In fact, I could only simulate it using socat.
To be clear: I could test HTTPS tunneling on IP cameras without any further tricks.
> Also, I don’t understand your first proposed patch (changing “fInputSocketNum” to “fOutputSocketNum” in a call to “getsockopt()”).
> The connection handler function is clearly for handling *incoming* data, so it should always be on the input socket, not the output socket (on which we never receive data).
It is quite possible that I misunderstood the getsockopt() check.
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.
Maybe it is supposed to work that way, I am admittedly not that familiar with low-level networking code.
Laszlo
</pre>
</body>
</html>