> On Dec 15, 2021, at 12:49 PM, Ross Finlayson wrote:
>
>> 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
> 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.
I fully understand that you need some kind of reference implementation on the
server side.
At the
> Simple and unsuccessful beats complicated and successful?
Of course, not.
However, for the tests I needed, the socat "tricks" proved to be simple and
successful.
I would like to stress that it is about tests, not a production quality
solution.
I just needed RTSP sources with different transpor
On Dec 15, 2021, at 2:09 AM, Laszlo Ast wrote:
>
> I successfully used stunnel
...
> socat was the simplest solution.
Simple and unsuccessful beats complicated and successful?
It sounds like you’ve got some weeks or months to wait for a non-guaranteed
solution, so unless you’re going to writ
> Did you try stunnel or nginx as the HTTP to HTTPS proxy? Those are more likely to implement the wide array of TLS
functionality your end devices require than the more limited socat.
I successfully used stunnel, and possibly tried traefik and caddy, but it was
some weeks ago.
I also considered
On Dec 14, 2021, at 4:35 PM, Laszlo Ast wrote:
>
> different tricks (socat and RTSP proxies)
Did you try stunnel or nginx as the HTTP to HTTPS proxy? Those are more likely
to implement the wide array of TLS functionality your end devices require than
the more limited socat.
__
> On Dec 15, 2021, at 12:35 PM, Laszlo Ast 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
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 adde
> It is about HTTPS, not HTTP.
Sorry, I missed this; I thought that you were referring primarily to HTTP. My
apologies.
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?
When I recently add
(For whatever reason, the mails are not delivered to my mailbox /yet?/,
even though I did not set digest mode, so the thread won't be nicely formatted.)
Huh? RTSP-over-HTTP on the client side has been implemented for more than 17
years now. This already works. Just pass a (non-zero) value fo
> On Dec 15, 2021, at 6:50 AM, Laszlo Ast wrote:
>
> Hi Ross,
>
> I made an attempt at implementing RTSP over HTTPS tunneling on the client
> side.
Huh? RTSP-over-HTTP on the client side has been implemented for more than 17
years now. This already works. Just pass a (non-zero) value for
Hi Ross,
I made an attempt at implementing RTSP over HTTPS tunneling on the client side.
I've split the changes into 3 patch sets.
I tried to use tabs and spaces that match the surrounding code. In order to
keep the tabs,
I attached the patches instead of pasting them into the mail body.
1. The
12 matches
Mail list logo
