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: YOUR_ASSIGNED_UDP_PORT
latency: MEASURED_RECOVERY_BUDGET
stream ID: YOUR_ASSIGNED_STREAM_ID
passphrase: YOUR_CONFIGURED_PASSPHRASE (when encryption is enabled)

Sender side:
srt://YOUR_CALLABA_HOST:YOUR_ASSIGNED_UDP_PORT?mode=caller&latency=YOUR_CLIENT_LATENCY_VALUE&streamid=YOUR_ASSIGNED_STREAM_ID
passphrase: configure separately if your sender requires it

Use the port and Stream ID issued or allowed by the server configuration. Set latency from measured RTT, loss and the production delay budget, and enter it in the units documented by the encoder or sender you are configuring.

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, create the SRT Server for the expected role, UDP port and access rule, then verify the publisher or receiver that actually connected. Open Show logs when the connection or route needs investigation; compare its event time with the encoder and destination rather than relying on a single connected badge.

Choose the received SRT server and the specific stream within it deliberately when adding a Multiview tile or downstream job. Multiview is the fast operator check for decoded picture and audio. Add the mixer only when the workflow needs a composed output, such as switching sources, graphics, or a program feed; it is not a requirement for ordinary SRT ingest.

After the source is proven, attach only the job the event needs—recording, restreaming, playback, or a prepared failover route—and verify it separately. A main/backup transport switch can preserve connected receiver and puller sessions, but the actual picture transition still depends on prepared feeds, buffers, network conditions and the destination.

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; an AWS launch can be useful for a regional test. In either case, the same evidence still matters: reachable UDP, a known endpoint pair, decoded media, transport history and a verified destination.

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 intended hostname, UDP port, caller/listener/rendezvous role, Stream ID and passphrase where used.
• Start the intended source and verify incoming bitrate, RTT, packet loss and retransmissions over the same interval.
• Check decoded picture and program audio, then select that exact SRT server and stream in Multiview or the downstream job and verify the real destination.
• Keep server and encoder time synchronized so Show logs, recordings and encoder evidence can be correlated.
• Test the prepared backup path before the event. Receiver and puller sessions may remain attached through a transport switch, but do not assume a hitless picture transition.

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