When using SRT, are multiple interface IP addresses supported?

[streamingsystems]

We have a use-case whereby we would like to have 2 SRS servers sitting on different hypervisors in our network with a keepalived VRRP VIP failing over between the two for use as an SRT ingestion router. When SRS fails on the primary, it was our hope that restarting srs would kick srs on the secondary server into accepting connections over UDP on the VIP as well as it's primary address.

What we are seeing in practice is that when more than 1 public IP address is associated with the interface we're using as the internet facing interface, only the primary interface IP appears usable for SRT UDP ingestion.

Is this by design, i.e. would a VRRP VIP be supported as an SRS/SRT endpoint with no specific IP called out on the SRT listen section in the config?

We are building with version 5.0-208, which is the latest release in v5.

[winlinvip]

Fault-tolerant backup actually consists of two strategies: one is a hot backup, and the other is a cold backup.

Hot Backup

Hot backup involves forwarding traffic to two different Real SRS Servers behind a single VIP (Virtual IP).

In fact, within Kubernetes (K8s), a VIP is equivalent to a Service, and the two SRS Servers correspond to two Pods.

Regarding stream pushing, for instance, when a client pushes a stream to the Service's VIP, the Service randomly selects one Pod to handle it, and this process should work without issues.

When an issue arises with an SRS, the Service will remove the problematic Pod. Consequently, when a client pushes a stream to this VIP, it will automatically be routed to the next available Pod, and this should also function well.

However, there can be issues when playing SRT streams. For instance, if a client pushes a stream to PodA, and when attempting to play this SRT stream, it might be routed to PodB instead, resulting in the player being unable to retrieve the stream and causing a black screen.

Cold Standby

Cold standby refers to a scenario where the VIP (Virtual IP) always forwards to a primary SRS Real Server initially, and then, in the event of an issue, it redirects to a backup SRS Server.

Under this approach, the current SRS is operational. However, the issue lies with the VIP (Virtual IP) or the Kubernetes Service, which needs to have the capability to support this functionality.

My impression is that load balancers like HAP can support this method, but I'm not sure, you need to do some test and verification.

TRANS_BY_GPT4

[winlinvip]

I would like to propose a more suitable solution, which is the SRT Proxy. In fact, it integrates the above-mentioned cold standby and hot standby solutions.

Alternatively, to put it simply, the SRT Proxy can be regarded as a VIP or LB that supports hot standby. We have previously discussed the Proxy solution in detail, please refer to #3634.

We have also implemented a validation demo for SRT Proxy, confirming that SRT can be proxied. For reference, see #3869.

This year, we should be able to implement this Proxy, but currently, there is no specific timeline established.

TRANS_BY_GPT4