Callaba SRT Server brings every SRT feed into one place, so your team can see connections, watch bitrate and network health, control access, and route video to Multiview, recording, restreaming, or playback. Run it on AWS or your own Linux server.
Need the protocol details?Read how SRT servers work
Choose a step to see what an operator can verify and control in Callaba. The values below illustrate the interface; they are not live telemetry.
See the reported region and peer IP for every publisher and receiver connected to the SRT server.
203.0.113.42203.0.113.42Allow the stream IDs and peer addresses you expect, with different rules for people sending and receiving video.
When guest access is enabled deliberately, callers and listeners can create a connection with their chosen stream ID without a pre-registered allowlist entry.
Receive the feed, check its health, and control where it goes.
Connect a camera, encoder, studio, or remote venue. Callaba shows whether the feed is healthy and lets your team send it to the next job without rebuilding ingest for every destination.
Send an encoded SRT feed over the public internet.
Bring a field or studio feed back to production.
Receive the feed, check its health, and control where it goes.
Cloud or self-hostedPut the source on a browser-based operator wall.
Capture the live feed for review or reuse.
Send the same source to the outputs you choose.
The source connects once. Operators can monitor it and then reuse it across Multiview, recording, restreaming, and playback.
For SRT PULL, save a primary source and the alternate sources your team has tested. With loop and reconnect enabled, Callaba can retry and move through that list after a disconnect.
Loop and reconnect let SRT PULL retry and move through the saved route list when the current source disconnects.
To promote a different route, stop the relay, save the change, and start it again. Saving alone does not reload a relay that is already running.
Supported behavior sits beside a practical acceptance check. The installed Callaba interface and the real source, destination, and infrastructure profile remain authoritative.
| Capability | Supported behavior | Acceptance check |
|---|---|---|
| Receive live SRT feeds | Connect cameras, encoders, studios, or remote venues to Callaba. | It receives live SRT feeds, shows operators the connection and transport state, controls who can publish or receive, and sends the video to Multiview, recording, restreaming, or playback. |
| Start with caller to listener | For a straightforward ingest test, run Callaba as the SRT listener and connect the encoder as the caller. | Yes. Launch Callaba in your AWS account or install it on a Linux server you control. The same browser interface is available in both models. |
| See transport health | Watch bitrate, RTT, packet loss, connection state, region, and peer address while the feed is live. | Live transport telemetry |
| Send one feed to several jobs | Reuse the source in Multiview, recording, restreaming, or playback. | A received feed can appear in Multiview, be recorded, be restreamed, or continue to a playback output configured in Callaba. |
| Multiview | Put the source on a browser-based operator wall. | A received feed can appear in Multiview, be recorded, be restreamed, or continue to a playback output configured in Callaba. |
| Give a dropped SRT feed a route back | For SRT PULL, save a primary source and the alternate sources your team has tested. With loop and reconnect enabled, Callaba can retry and move through that list after a disconnect. | For SRT PULL, add the tested sources to routing_hosts and enable loop and reconnect so the relay can retry them after a disconnect. To promote a preferred route, use stop/save/start. Saving alone does not reload a running relay, and recovery is not guaranteed to be hitless. |
The product interface stays familiar in either model. Choose the infrastructure your team is ready to operate.
Start a Callaba instance in your AWS account and configure the SRT server from the browser.
Launch on AWSInstall Callaba on Linux when you need the media path and host under your control.
Install self-hostedLearn what an SRT server is, how caller/listener modes, UDP ports, latency, stream ID and passphrase work for live video ingest.
Written by Iurii Pakholkov
Last updated: August 4, 2026
The product overview above explains what Callaba SRT Server can do. This guide starts at the operator handoff: an endpoint has been created, and a real SRT stream now has to connect, carry usable media and reach the intended production output.
SRT stands for Secure Reliable Transport. It uses UDP, then adds selective retransmission, an adjustable recovery window, optional encryption, connection roles and transport statistics. Those controls are useful when a contribution feed must cross the public internet, a venue uplink or another network that will not stay perfectly clean.
Keep contribution and ingest separate from audience playback. The SRT endpoint accepts or initiates the controlled transport session; a player, CDN or participant room comes later. Once the feed is proven, the production system can route, record, transcode, restream or prepare an output such as HLS or WebRTC.
Quick answer: what is an SRT server?
Treat the SRT server as the first production checkpoint after the source. A common live ingest pattern has the server as Listener and the encoder as Caller, but those roles say who opens the connection—not which way the media must travel. Acceptance requires the intended session, incoming bitrate, transport state, decoded picture and audio, and the next output.
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:
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.
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.
| Term | Meaning | Example |
|---|---|---|
| SRT protocol | The UDP-based transport method used to move live media with recovery, encryption, latency control and statistics. | The connection between an encoder and Callaba. |
| SRT server | The ingest or relay endpoint that accepts SRT sessions and connects them to the rest of the workflow. | Callaba listening for a remote venue feed. |
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.
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.
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.
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.
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.
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-mainBuild the evidence in order: prove one sender, one UDP port, one Stream ID, one decoded preview and one recording. Add access rules, more sources, recovery routes and audience outputs one at a time so a new failure still has a clear owner.
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 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.
| Technology | Best role | Practical note |
|---|---|---|
| SRT | Live contribution, ingest and transport between controlled endpoints. | Use when the contribution path is important or imperfect. |
| RTMP / RTMPS | Simple publishing and social platform ingest. | Often used after SRT ingest for final push to platforms. |
| HLS | Large-scale viewer playback across browsers, TVs and mobile devices. | Browsers usually need HLS or another playback format, not raw SRT. |
| WebRTC | Interactive real-time video, calls, return feeds and sub-second participation. | Useful when the viewer or participant needs very low latency. |
| NDI | Low-latency production networking inside controlled LAN or studio environments. | Use SRT/NDI bridges when moving production signals between sites or cloud workflows. |
If the decision is specifically about publisher-to-platform transport, continue with SRT vs RTMP and test both against the same encoder and destination.
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.
| Setting | Recommended first test | Why it matters |
|---|---|---|
| Mode | Server as Listener, encoder as Caller | Simplest cloud ingest pattern. |
| UDP port | Open one documented UDP port per ingest feed | SRT traffic will not arrive through a closed firewall. |
| Latency | Start at 200–500 ms for normal internet paths | Gives SRT time to recover loss and jitter. |
| MPEG-TS / container | MPEG-TS is the common live video container over SRT | The server receives a muxed media payload, not only a transport connection. |
| Stream ID | Use a readable value such as event-main |
Helps route, identify and protect feeds. |
| Passphrase | Same value on sender and server | Encryption fails if keys do not match. |
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:
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.
Build thresholds from the path: observe RTT as a range, compare loss and retransmission deltas over the same interval, and keep encoded bitrate inside measured network headroom. Increase latency only when evidence shows recoverable packets are arriving too late; do not copy a universal percentage into every deployment.
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.
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.
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.
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.
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.
| Option | Use when | Main risk |
|---|---|---|
| Self-hosted SRT server | You need full control over network placement, compliance, routing logic or internal deployment rules. | Your team owns monitoring, scaling, updates and event-day operations. |
| Managed SRT workflow platform | You need to launch quickly and want monitoring, routing, recording or restreaming in one place. | You still need to validate ports, source settings, stream ID, passphrase and downstream routes. |
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.
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.
No. Caller and Listener describe who opens the connection. The application design determines which side sends the media.
Ordinary browser playback normally needs a browser-supported output such as HLS or WebRTC. The SRT session remains the contribution transport.
Confirm the intended session, incoming bitrate and transport health, then check decoded picture and audio in Multiview or at the destination.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Last updated: August 4, 2026