Callaba SRT Server

What is an SRT server?

An SRT server is software that owns one end of an SRT session. It may wait for an encoder, call another endpoint or relay a feed onward. In production terms, it is the place where a remote source becomes a session the receiving team can identify, observe and hand to another system.

A useful acceptance check separates four jobs instead of collapsing them into a single “connected” state:

• Receives the live feed: a camera encoder, OBS, vMix, FFmpeg, Larix, or another source sends video to the server.
• Protects the contribution path: SRT can recover lost packets and encrypt the transport session.
• Exposes live statistics: operators can monitor bitrate, RTT, packet loss, retransmissions, and connection state.
• Passes the stream downstream: the server can route the feed into recording, transcoding, restreaming, switching, or playback workflows.

When a remote crew says “we are sending,” answer with evidence from this boundary. Confirm that the expected peer connected, that media is still arriving, that recovery is keeping up with the path, and that the downstream decoder can use the feed. Each answer rules out a different class of failure.

SRT server vs SRT protocol

The SRT protocol defines how the endpoints establish and protect the transport session. The SRT server is one of those working endpoints, with its own port, role, access policy, media path and operational state.

What is an SRT live server?

The phrase SRT live server usually means that the endpoint is carrying an event as it happens. The feed is accepted and handed to production, recording or distribution while late packets still have a limited window in which they are useful.

That pattern appears in venue contribution, studio-to-cloud links, mobile or hardware-encoder ingest, partner handoffs, prepared backup paths and remote-production workflows. Multi-destination delivery can follow, but it should not be used as proof that the incoming contribution is healthy.

The live constraint creates the trade-off. Latency must leave enough time for a missing packet to be requested and returned, yet remain inside the production delay budget. A value copied from a studio LAN may be too short for a cellular or long-distance path even though the socket still connects.

How an SRT server works

SRT transports an already encoded payload; it does not decide the camera codec or repair an invalid media map. Many live paths carry muxed MPEG-TS with H.264 or H.265/HEVC video and AAC audio, although the actual container and tracks depend on the sender. Inspect the payload that really arrived rather than assuming the transport handshake proves codec compatibility.

1. An encoder creates the live audio and video stream.
2. The encoder sends the stream to an SRT server.
3. The SRT server receives the stream and tracks connection health.
4. If packets are lost, SRT can request retransmission while the packets are still useful.
5. The server passes the stream to the next workflow step: recorder, transcoder, restream, switcher, API workflow, or playback system.

Caller, listener, and rendezvous modes

SRT exposes three connection roles. Choose them from reachability and NAT constraints, then document the choice on both endpoints. The label determines how the session is opened; it does not, by itself, determine media direction.

• Listener: waits for an incoming SRT connection on a known UDP port. This is the common mode for a cloud ingest server or data center endpoint.
• Caller: starts the connection to a listener. This is common for field encoders, OBS, vMix, FFmpeg, mobile apps, and remote sources.
• Rendezvous: both sides initiate the connection. This can help in some NAT cases, but it should be tested carefully before production.

SRT server ports and firewall rules

Because SRT runs over UDP, every receiving boundary must allow the selected UDP port: cloud security group, host firewall, router, NAT rule or upstream policy. Opening TCP on the same port number does not open the SRT path.

• the server has a public IP or reachable network address;
• the correct UDP port is open;
• the encoder is using the correct caller/listener mode;
• the stream ID matches the server routing rule, if stream ID is used;
• the passphrase matches on both sides, if encryption is enabled;
• the receiving workflow is mapped to the correct downstream output.

Use the encoder’s “connected” badge as the start of the test. Confirm incoming bitrate and transport state on the receiving side, then open Multiview or the actual destination. A working socket cannot show that program audio exists, timestamps are usable or the downstream decoder accepts the payload.

SRT server setup example

The example below is a bring-up pattern, not a production preset. Use the host, UDP port, Stream ID, passphrase and latency issued for your own Callaba instance and measured network path.

Server side:
mode: listener
UDP port: 10080
latency: 200 ms
stream ID: event-main
passphrase: optional, same on both sides

Sender side:
srt://YOUR_CALLABA_IP:10080?mode=caller&latency=200&streamid=event-main

Where SRT servers fit in live streaming workflows

SRT most often owns the contribution leg: the controlled trip from a source to the production boundary. Viewer delivery is a separate leg with different protocols, scaling behavior and acceptance evidence.

source → SRT transport checkpoint → verified production output

After ingest passes, route the feed to the specific job the event needs: monitoring, recording, transcoding, restreaming, a prepared recovery path or a browser-supported output. Verify each destination independently instead of treating a long route list as one state.

SRT server vs RTMP, HLS, WebRTC and NDI

SRT is one transport choice, not a universal video layer. Compare protocols at the boundary they are meant to own: contribution, local production, interactive playback or scaled HTTP delivery.

If the decision is specifically about publisher-to-platform transport, continue with SRT vs RTMP and test both against the same encoder and destination.

How to deploy an SRT server

Cloud and self-hosted deployments follow the same acceptance sequence. Establish the network boundary, start one known endpoint pair, send the intended codec and bitrate, observe transport health, and prove decoded output before adding routes or automation.

1. Create a server or cloud instance with enough CPU, network capacity, and storage for your workflow.
2. Open the required UDP port in the cloud security group and host firewall.
3. Create an SRT listener that will receive the incoming stream.
4. Set stream ID and passphrase rules if you need routing and encryption.
5. Connect the encoder as SRT caller and send the stream to the listener endpoint.
6. Check live statistics such as bitrate, RTT, packet loss, retransmissions, and connection state.
7. Route the stream downstream to recording, restreaming, transcoding, or playback.

How to use an SRT server in Callaba

In Callaba, the SRT Server screen is the working contribution surface. It brings the connection role, publisher or receiver state, access policy, transport evidence and onward route into one operator workflow. Use the API after that workflow is understood and repeatable.

The same accepted input can support several distinct jobs:

• SRT encoder to Callaba, then restream to Twitch or YouTube;
• OBS to Callaba over SRT, then record the stream;
• vMix to Callaba over SRT, then route the feed to another destination;
• mobile app to Callaba over SRT, then restream to social platforms;
• remote venue to Callaba, then package for browser playback;
• SRT input to browser multiview, recorder, API routing and controlled player delivery.

What to monitor on an SRT server

Read transport evidence and decoded media together. Transport counters explain the session; picture, audio and the destination show whether the production can actually use it.

Transport signals

• Connection state: connected, disconnected, reconnecting, or failed.
• Incoming bitrate: whether media is still flowing at the expected rate.
• RTT: round-trip time between sender and receiver.
• Packet loss: how much data is being lost on the path.
• Retransmissions: how often SRT has to recover missing packets.
• Jitter: how much packet timing varies.
• Receive buffer pressure: whether the connection is running too close to its recovery limit.

Media signals

• black video, frozen video, missing audio or silent audio;
• wrong codec, frame rate, resolution or audio format;
• bad timestamps, missing keyframes or incompatible stream mapping.

Common SRT server problems

The SRT connection does not start

Put the two saved endpoint configurations side by side. Check role, reachable address, UDP port, every firewall boundary, Stream ID and passphrase. This is faster and safer than inferring the cause from one application’s status message.

The stream connects but video is unstable

Align the visible breakup with RTT, loss, retransmission and latency evidence from the same interval. If replacement packets return after the recovery window, measure again with more latency or less bitrate. If the link is already saturated, a larger window alone will not create bandwidth.

The stream connects but there is no audio

Start at the encoder: confirm the intended device, meters, channel layout and audio codec. Then inspect the received tracks and the next application’s codec support. Changing network settings cannot restore audio that was never placed in the payload.

Listen locally in OBS, vMix, the hardware encoder or a monitored device output before touching the server. Once source audio is proven, follow that same track through the receiver and destination without switching test signals mid-investigation.

The SRT stats look good but viewers still have problems

When transport remains healthy during a viewer incident, move forward through decode, transcoding, packaging, origin, CDN and player. Keep one incident timestamp across the chain so each team is examining the same event rather than a similar-looking symptom.

Self-hosted vs managed SRT server

Choose deployment by the operating boundary your team is prepared to own. Self-hosting keeps the instance, upgrades and network policy inside your infrastructure. A cloud launch can shorten the first regional test. Neither option removes capacity, monitoring or recovery work.

Callaba supports the same SRT operator workflow in a cloud launch or on a self-hosted Linux server. Prove one ingest, Multiview or destination and recording on the chosen infrastructure; then add routing, restreaming, browser delivery or API automation as separately testable steps.

Event-day checklist for an SRT server

• Confirm the server IP or hostname.
• Confirm the UDP port is open.
• Confirm caller/listener/rendezvous mode on both sides.
• Confirm stream ID, if used.
• Confirm encryption passphrase, if used.
• Confirm expected bitrate, codec, frame rate, resolution, and audio format.
• Start the stream and verify incoming bitrate.
• Check RTT, packet loss, retransmissions, and jitter.
• Check actual video and audio, not only connection state.
• Confirm the downstream route: recording, restreaming, transcoding, or playback.
• Confirm time synchronization: server and encoder should use NTP or another consistent time source so logs and recordings can be correlated during troubleshooting.
• Test the backup path before the event starts.

Official references and related reading

Keep the protocol specification beside the runbook, and use the current Callaba guides for interface and API details that can change independently of the transport standard.

• SRT protocol draft
• Haivision SRT live transmit documentation
• What is SRT protocol?
• How to start SRT streaming in OBS Studio
• How to receive SRT stream in OBS Studio
• Sending and receiving SRT stream via vMix
• Find the perfect latency for your SRT setup
• SRT servers API docs

FAQ

What is an SRT server?

It is one working endpoint in an SRT session. The server can wait for, initiate or relay a contribution connection, then expose that feed to a controlled production workflow.

What is an SRT live server?

It is an SRT endpoint carrying contribution while the event is happening. The accepted feed can continue to switching, monitoring, recording, transcoding, routing, restreaming or a viewer-delivery workflow.

Is an SRT server the same as a streaming server?

No. An SRT server usually owns a contribution or relay session. A broader streaming platform may add access control, transcoding, recording, analytics, API operations, viewer playback and CDN delivery around that transport.

Does an SRT server use UDP?

Yes. SRT runs over UDP, so the chosen UDP port must be permitted through the cloud rule, host firewall, router and any other receiving network boundary.

What port does an SRT server use?

There is no universal SRT port. Choose the UDP port in the endpoint configuration, reserve it in the relevant network policies, and document which event, feed or tenant owns it.

Should an SRT server be listener or caller?

A common cloud-ingest pattern uses Callaba as Listener and the encoder as Caller because the server has a reachable address and known UDP port. Use another role when the real NAT and firewall design requires it; role does not fix media direction.

Can OBS send to an SRT server?

Yes. Configure OBS with the SRT endpoint and matching role, port and security values. After it connects, verify the received bitrate, decoded picture and audio before routing the feed onward.

Can vMix send to an SRT server?

Yes. vMix can send or receive SRT. One common design sends the vMix program to Callaba for monitoring, recording, routing or restreaming, with both endpoint roles and the returned media checked during rehearsal.

Is SRT better than RTMP?

For lossy or long-distance contribution, SRT offers recovery and a tunable latency window that RTMP does not provide in the same way. RTMP or RTMPS remains common for publisher-to-platform delivery, so many systems use SRT upstream and RTMP downstream.

Can browsers play SRT directly?

Ordinary browser playback does not consume a raw SRT URL. Receive the contribution first, then prepare a browser-supported output such as HLS or WebRTC.

Why does my SRT stream connect but show no video?

The transport handshake can succeed even when no usable video is present. Check incoming bitrate, container, codec, timestamps, keyframes, track mapping and the destination decoder with the same live sample.

How do I make an SRT server more reliable?

Use the intended UDP path, leave measured bandwidth headroom, size latency from RTT and loss behavior, inspect the media payload, monitor deltas and rehearse a genuinely usable alternate endpoint before the event.

Does SRT usually carry MPEG-TS?

Often, yes: many live SRT workflows carry muxed audio and video in MPEG-TS. SRT itself is content-agnostic, so confirm the container and tracks produced by the actual sender.

What SRT server metrics should I watch first?

Start with connection state, incoming bitrate, RTT, retransmission and loss deltas over a known interval. Read them beside decoded picture and audio, then set alert levels from the intended codec, bitrate, region and network rather than a universal percentage.

Where to go next

• What is SRT protocol?
• SRT vs RTMP
• How to start SRT streaming in OBS Studio
• How to receive SRT stream in OBS Studio
• Sending and receiving SRT stream via vMix
• Find the perfect latency for your SRT setup
• SRT servers API docs

Last updated: August 4, 2026