Use an SRT server as the clean ingest edge for live production.

What is an SRT server?

An SRT server is the endpoint that accepts or manages SRT connections. It can receive a live SRT stream from an encoder, relay that stream to another system, or act as a controlled handoff point between a remote source and a production platform.

In a typical live workflow, the SRT server does four practical jobs:

• 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.

This makes the SRT server the boundary between the source side and the platform side. When a remote crew says “we are sending,” the SRT server is where you check whether the signal is actually arriving, whether it is stable, and whether the media can be used downstream.

SRT server vs SRT protocol

The SRT protocol is the transport method. The SRT server is the system or software endpoint that uses that protocol to receive or send live streams.

What is an SRT live server?

An SRT live server is an SRT server used for real-time or near-real-time live video contribution. It receives a live stream while the event is happening and forwards it into a live production, recording, or distribution workflow.

Teams use SRT live servers for remote event contribution, cloud ingest from cameras and encoders, studio-to-cloud transport, partner feed handoff, backup contribution paths, remote production workflows, and multi-destination restreaming.

The word “live” matters because SRT tuning is different from file transfer. The server has to balance delay and recovery. If latency is too low for the real network path, the stream may connect but still break up during packet loss or jitter.

How an SRT server works

An SRT server receives encoded audio and video over an SRT connection. The media is already encoded before SRT carries it. In live video workflows, SRT is often used to carry a muxed MPEG-TS stream, but the exact container can depend on the sender and workflow. In practical SRT server work, you usually receive a ready media stream: video such as H.264 or H.265/HEVC, audio such as AAC, and sometimes metadata.

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 uses three connection modes. The mode decides which side starts the connection and how the session works through firewalls and NAT.

• 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

SRT uses UDP. That means the server must have the right UDP port open in the cloud security group, host firewall, router, or network policy.

• 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.

A common mistake is to check only that the encoder says “connected.” A connection is not enough. You also need to confirm that media is arriving, bitrate is stable, and the downstream system can use the stream.

SRT server setup example

This is a practical first-test setup. Replace the host, port, stream ID and passphrase with your own values.

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 is usually strongest on the contribution side of the workflow. It is the part where the live feed travels from the source to the platform.

camera or encoder → SRT server → transcoder / recorder / restream / player workflow

After the SRT server receives the stream, the platform can prepare it for restreaming, recording, transcoding, playback, routing, failover, API workflows or production monitoring.

SRT server vs RTMP, HLS, WebRTC and NDI

SRT is not a replacement for every video technology. It solves a specific part of the workflow.

For a protocol-level comparison, read SRT vs RTMP.

How to deploy an SRT server

The exact setup depends on your software, cloud provider, and workflow, but the deployment logic is usually the same.

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

Inside Callaba, an SRT server is usually used as a controlled ingest point. A remote source sends a stream to Callaba, and Callaba makes that stream available for the next workflow step.

Common Callaba workflows include:

• 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

A connected SRT session does not always mean the stream is healthy. Monitor both transport health and media health.

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

Check the connection mode, UDP port, public IP, firewall rules, stream ID, and encryption passphrase. Most failed SRT handshakes come from a wrong mode, blocked UDP traffic, wrong port, or mismatched security settings.

The stream connects but video is unstable

Look at RTT, jitter, packet loss, retransmissions, and latency settings. If the latency value is too aggressive for the network path, SRT may not have enough time to recover lost packets before they become useless.

The stream connects but there is no audio

Check the encoder first. Make sure the audio source is enabled, the right audio device is selected, the audio codec is compatible with the next workflow step, and the receiving application can read the audio track.

Before debugging the SRT server, confirm that audio exists at the source. Use local monitoring in OBS, vMix, the hardware encoder, headphones, or the device preview before blaming the network or server.

The SRT stats look good but viewers still have problems

If the SRT link is healthy but viewers see stalls or artifacts, the problem may be downstream. Check transcoding, packaging, origin, CDN, player behavior, and output format. Do not blame the SRT server until you have checked the rest of the chain.

Self-hosted vs managed SRT server

You can run an SRT server yourself or use a managed platform. The better choice depends on how much operational control your team wants to own.

Callaba can be used as a cloud or self-hosted SRT workflow platform. You can launch it on AWS, install it on your own server, create SRT ingest points, and connect those streams to restreaming, recording, routing, browser preview, multiview, player delivery, and API workflows.

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

Use these if you need protocol-level SRT details, Callaba setup docs, or related workflow guides.

• SRT protocol draft
• Haivision SRT live transmit documentation
• Schema.org TechArticle
• Schema.org FAQPage
• 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?

An SRT server is a live video ingest or relay endpoint that receives, sends, or routes SRT streams. It is usually used to move a live feed from an encoder, camera, remote venue, studio, mobile device, or partner system into a controlled media workflow.

What is an SRT live server?

An SRT live server is an SRT server used for real-time live video contribution. It receives live video while an event is happening and passes the stream into recording, restreaming, transcoding, switching, routing, or playback workflows.

Is an SRT server the same as a streaming server?

Not always. An SRT server usually handles live ingest or transport between controlled endpoints. A full streaming platform may also handle transcoding, recording, viewer playback, analytics, access control, API workflows and CDN delivery.

Does an SRT server use UDP?

Yes. SRT runs over UDP. That is why the correct UDP port must be open on the server firewall, cloud security group, router, or network policy.

What port does an SRT server use?

SRT does not require one universal fixed port. The port is defined by the server configuration. In production, teams usually reserve a clear UDP port or port range for SRT ingest and document which feeds, tenants or events use each port.

Should an SRT server be listener or caller?

For most cloud ingest workflows, the SRT server is Listener and the encoder is Caller. That works well when the server has a public IP or DNS name, a known UDP port, and clear firewall rules.

Can OBS send to an SRT server?

Yes. OBS can send video to an SRT server when configured with an SRT output URL. The server receives the stream and can route it into recording, restreaming, transcoding or playback workflows.

Can vMix send to an SRT server?

Yes. vMix supports SRT workflows and can send or receive SRT streams. A common setup is vMix sending SRT to Callaba, while Callaba handles monitoring, routing, recording or restreaming.

Is SRT better than RTMP?

SRT is usually better than RTMP for contribution over unstable, lossy or long-distance networks. RTMP is still common for simple publishing and platform ingest. Many workflows use SRT for contribution and RTMP or RTMPS for final delivery to a social platform.

Can browsers play SRT directly?

In normal web workflows, browsers do not play SRT directly. An SRT server receives the stream first, then the platform converts or packages it into a viewer format such as HLS or WebRTC.

Why does my SRT stream connect but show no video?

The SRT transport connection can work while the media payload is still wrong. Check codec, container, timestamps, keyframes, audio tracks, stream mapping, downstream compatibility and whether bitrate is actually arriving at the server.

How do I make an SRT server more reliable?

Use a stable server, open the correct UDP ports, choose realistic latency, monitor RTT and retransmissions, keep enough bandwidth headroom, validate the media payload and test a backup endpoint before the event.

Does SRT usually carry MPEG-TS?

In live video workflows, SRT is often used to carry MPEG-TS with muxed audio and video, but the exact media container depends on the sender and workflow. The server should verify the payload, not only the SRT connection.

What SRT server metrics should I watch first?

Start with incoming bitrate, RTT, packet loss, retransmissions and connection state. In good conditions RTT may be around 20–60 ms. If RTT is consistently above 150 ms or packet loss is above 1–2%, increase latency, lower bitrate or improve the network path.

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: May 21, 2026

Try Callaba as your SRT server

Create an SRT listener in Callaba, send a live feed to the gateway, and monitor the stream before routing it to recording, restreaming, multiview, playback, or API workflows.

See SRT server API docs Open multiview demo SRT servers API docs