OME ports, nginx proxying

[naanlizard]

Hello all

I'm working on rebuilding our test setup, and part of that is that I'd like to proxy as much as possible through our nginx server in order to improve security, among other things

To that end, I see the following ports used by OME as we have it set up

1935: RTMP, not practically proxyable afaik - possible to proxy via an nginx stream host, but I don't believe we could pass the actual origin IP address, so all streams would appear to come from one IP address. Please correct me if I'm wrong, but my testing failed here

API port (trivial, I believe, but untested as of now)

WebRTC signalling, 3333 or 3334 for plain or ssl connections respectively. Can these be proxied?

WebRTC ICE candidates and TCPRelay - no idea. Is the player making a call to a resource like ome-server:3478/tcprelayrequest that I could catch with a nginx location block? Same question for the range of ports for ICE candidates - I am very unsure about how any of this part works.

:3478
:10000-10005/udp}

HLS ports - also trivial, already working

Part of my problem is that WebRTC and HLS playback both seem to request domain.tld/live - which means an nginx location block can't direct HLS to one port and WebRTC to another. I suppose I can have the player try and load /webrtc/live or something, and then fix it in the nginx block, but that seems janky and prone to cause problems.

Is it possible for OME to listen for both WebRTC and HLS requests on one port? That would be ideal for our use case, and maybe others. That is, assuming the other requests can be proxied.

Any thoughts in general are more than welcome

An aside, I found this https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt - is this something OME could implement? It seems like it would let us forward arbitrary tcp streams (e.g. rtmp) through nginx without losing the stream's source IP, which is of course important for access control in some architectures.

[basisbit]

HLS and LLHLS can go through a HTTP reverse proxy like Nginx and HAProxy. However, you can't proxy WebRTC or RTMP or SRT through a HTTP proxy. You could try using HAProxy as a bare TCP proxy, but you gain almost nothing with that. However you'd loose support for WebRTC over UDP, which is much more CPU-efficient.

[bchah]

I proxy the following through Apache:

WebRTC Signalling
Thumbnails
LLHLS
API

... and shift TCP Relay to port 10010 which is also the sole ICE candidate - so both TCP and UDP on that port.

For the proxies it's just /live -> 0.0.0.0:webrtc_signalling, /api -> 0.0.0.0:api_port and so on. I know I'm a masochist for using Apache but alas, we are PHP-bound.

Sure would be a dream to do it all over the HTTP ports. But at least we haven't had issues with end-user playback since switching to 443 TCP with all the proxies + 10010 TCP/UDP.

Interested to see what you come up with!