Geo-Distributed SRT Routing: Architecture Guide

Choose regional roles before choosing regions

A useful architecture names what each deployment protects. A publisher-side region shortens the uncontrolled contribution path and gives the field team one nearby ingest address. A production-side region gives the control room a stable receiving point and can fan out to recording, Multiview or further destinations. A delivery-side region may be needed when a downstream partner accepts a direct feed near its network boundary.

Those roles can be combined when traffic and risk are modest. Splitting them makes sense when teams, networks or recovery responsibilities differ. It does not automatically make the workflow more reliable: two regional instances still share a failure domain if both depend on one encoder, one ISP, one credential, one control account or one downstream receiver.

SRT connection mode still matters across regions

SRT runs over UDP and supports Caller, Listener and Rendezvous connection modes. In the simplest regional workflow, the publicly reachable Callaba endpoint listens and the remote encoder calls it. The inter-region leg then uses one explicit Caller-to-Listener pairing. That arrangement is easy to document because one side waits on a known port and the other initiates the session.

Rendezvous can help in specific peer-to-peer network arrangements, but both peers must use it and both must be able to send and receive the necessary UDP traffic. It is not a universal cure for firewalls. Record the mode, local and remote addresses, UDP port, passphrase policy and Stream ID at every leg. Never copy a public IP from an old tutorial into a new deployment.

Four Callaba patterns for the same geographic problem

The SRT Gateway guide explains these implementation paths in more detail. Choose one owner for the inter-region leg; duplicating the same relay in several modules makes an incident harder to understand.

Build the route without inheriting obsolete addresses

1. Measure the endpoints. Record where publishers, operators and receivers actually connect. Run path tests at the hours the live event will operate.
2. Launch the regional deployments. Use the Callaba cloud quickstart for the current AWS flow. Apply distinct operational names that include region and role.
3. Create the receiving boundary. Start one SRT Listener in the publisher-side region. Copy its current address and port from the dashboard, then permit only the required UDP traffic.
4. Prove contribution. Send a representative source and confirm session state, sustained bitrate, video, audio and SRT transport statistics before adding the regional hop.
5. Create the second boundary. Start the receiving endpoint in the production-side region and build the SRT route or restream from the first deployment to it.
6. Prove the final receiver. Use the production decoder, a Multiview tile or a short recording. The route is not accepted merely because both dashboards say connected.
7. Exercise recovery. Stop the publisher, interrupt the inter-region output, and restart each regional instance separately. Record detection, reconnect and media recovery time.

Set latency from recovery needs, not distance alone

SRT latency is a packet-recovery budget. A longer and more variable path may need more time for retransmissions; an unnecessarily large setting adds delay without repairing congestion or insufficient bandwidth. Start from measured round-trip time and loss behavior, then test difficult scenes at the production bitrate. Confirm that both sides use compatible latency and encryption settings.

The end-to-end delay also includes capture, encoding, queues, decoding and any playback buffer. When a second region adds a relay, measure the complete program path rather than adding two dashboard latency values. A receiver that is geographically close can still have a poor route through its ISP, while a farther AWS region may be reached consistently.

Capacity and egress need their own budget

Every inter-region copy consumes outbound bandwidth from one deployment and inbound capacity at another. Fan-out multiplies egress even when the contribution enters only once. Calculate peak bitrate from the highest credible encoder rate, audio and container overhead, concurrent feeds, destinations and recovery reserve. Confirm current AWS regional pricing separately; static numbers in an architecture article become stale quickly.

If several outputs share one regional source, isolate whether a fault is upstream or destination-specific. When all outputs lose media and the first region has no incoming bitrate, investigate the publisher leg. When the first region remains healthy but the second has no session, investigate the inter-region route. When both are healthy but the studio is dark, preserve the route and inspect the last receiver boundary.

Security and operational ownership

• Use unique Stream IDs or managed identities for separate publishers and receivers; do not publish working addresses in screenshots.
• Use an SRT passphrase of the length supported by both peers when encryption is required, and store it as access material.
• Restrict cloud and host firewalls to the required UDP ports and source networks when their addresses are stable.
• Give every regional resource an owner, escalation contact, restart procedure and approved configuration record.
• Keep time synchronized and include the region and path name in logs so events from both sides can be compared.

After the UI workflow is accepted, an authenticated control system can create repeatable regional routes using the Create SRT route API method. Automation should reproduce a reviewed regional contract; it should not invent ports, latency or recovery behavior at runtime.

Authoritative references

• Haivision SRT open-source project — protocol overview, current library and documentation.
• SRT live transmit documentation — Caller, Listener and Rendezvous behavior and URI examples.
• SRT socket options reference — latency, encryption and connection option semantics.

Frequently asked questions

Does a geo-distributed SRT route automatically choose the nearest region?

No. You select and operate the regional endpoints. DNS, internet routing and any external traffic-management layer are separate from the SRT session. Verify the path from each actual publisher and receiver.

Should the first Callaba region be near the publisher or the viewers?

Place it near the boundary you need to stabilize first. For remote contribution that is usually the publisher. A second deployment can then provide a controlled handoff near production or delivery.

Can the inter-region route also transcode the feed?

Use Restreaming when the selected input/output combination supports the required media transformation. Use an SRT Route when the job is a protocol-preserving relay. Test the exact codec and destination before production.