mgallagher01
commented
2 years ago Our first attempt to create a value that can be used to parse the cameras into groups will use templates that contain the appropriate listen port for each proxy instance. The template name can then be used by a script on the proxy server during startup.
For example a template with a name such as "NDOT_PROX_TCP1" would have a port like "1554" defined in the template. Then on the proxy server, a startup script would define instance 1 as having listen port "1554" and start the proxy with the "-t" flag that forces RTP over TCP.
The hitch here is that somewhere the relationship between templates and instance configurations has to be documented.
To get around the high packet loss we see on the network, we can try a workaround with multiple proxy instances on the same virtual server.
The concept is to parse the list of all cameras in IRIS into a group that requires RTP over TCP and a group that works with UDP (usually on NDOT's 10.240.x.x subnet). Then we can have one server instance forcing TCP on the back end to the camera and another using UDP. The different groups of cameras will then be proxied by the appropriately configured instance.
The IRIS clients will then request video streams using the different listen ports configured for each proxy instance.
This should have two effects:
1) Cameras that fail when using UDP should stream successfully on TCP. 2) I/O load will be balanced across multiple threads, since each instance should use a separate thread (core) on the server.