An SRT server is the managed contribution endpoint. Configure latency and bandwidth for the real network, secure it, then use telemetry and controlled routes rather than guessing from player symptoms.
Callaba SRT Server
Every lifecycle change ends with observable media proof, and retirement does not leave hidden downstream dependencies.
See how the product worksBefore you start
A reachable UDP port and a firewall rule limited to the required sources when possible.
A real SRT encoder or test source and a receiver such as VLC or a downstream Callaba module.
Measured network RTT and expected peak bitrate.
Settings explained
These are the controls an operator needs to understand. Internal field names and implementation events are intentionally omitted.
Listener
Identity and network capacity of the SRT endpoint.
- Name and active state
Operator label and lifecycle state of this SRT server.
- Listener port
UDP port used by incoming SRT connections.
- Receiver port
Optional distinct port used by the receiver side of the configured workflow.
- Latency
SRT recovery buffer sized for the measured network path.
Start from measured RTT and test under representative packet loss.- Maximum bandwidth
Headroom SRT may use for retransmission relative to the media bitrate.
- Receive buffer
Host buffer available to the SRT receiver.
- Connection timeout
How long an unavailable peer may remain unresolved before the session is treated as failed.
Security and access
Protect media and restrict who may publish or receive.
- Passphrase
Optional SRT encryption secret shared by authorized peers.
Use a strong secret and distribute it separately from the URL.- Access mode
Require explicit Stream access objects, restrict by host, or deliberately allow broader access.
- Publisher and receiver roles
Separate clients that send media from clients that consume it.
Routing and recovery
Connect this endpoint to one or more SRT peers.
- Routing mode
Disable routing or use Callaba/public-address peer definitions.
- PUSH or PULL
PUSH sends toward a listener; PULL connects to an available source.
- Routing hosts
Ordered peer addresses used by the configured route workflow.
Observability
Use live evidence before changing transport parameters.
- Statistics interval
Frequency used for supported statistics collection or callbacks.
- Live bitrate
Shows whether media is currently arriving.
- Network RTT
Round-trip time reported by the SRT session.
- Connection and event history
Session and transport events used to diagnose disconnects.
Safe first workflow
- 01
Create the server with an unused UDP port and a clear operator name.
- 02
Measure the real path, then set latency, maximum bandwidth and timeout for that network.
- 03
Add a passphrase and explicit publisher/receiver Stream access.
- 04
Start the server and connect one real publisher.
- 05
Connect one receiver or downstream module and confirm live bitrate plus Network RTT.
- 06
Only after the single path is stable, add routing or a backup PULL source.
Workflow examples
Create, verify, edit and retire an SRT server
An operator needs to change an SRT endpoint without mistaking a saved form for a working media path.
How to build it
- 1
Create the server with its role, port, access policy and expected media settings.
- 2
Start it and wait for the endpoint state expected by the publisher or receiver.
- 3
Connect real media and verify bitrate, picture, audio and the intended downstream output.
- 4
Before editing, identify whether the field requires a stop or restart; save the change, restore the server and repeat the same media test.
- 5
Before deleting the server, remove or reassign every route, recording, Multiview tile and output that depends on it.
Secure remote contribution into production
A field encoder sends a feed over the public internet.
How to build it
- 1
Create the SRT listener and size latency from the measured path.
- 2
Set a passphrase and create a publisher Stream for the encoder.
- 3
Connect the encoder and confirm bitrate, RTT and stable session state.
- 4
Select the verified SRT source in Multiview, Recording or Restreaming.
Primary and backup SRT contribution
Production has two independently reachable feeds and needs a controlled recovery path.
How to build it
- 1
Add the independently tested primary and backup hosts to the PULL routing plan.
- 2
Verify each source alone before enabling the ordered route workflow.
- 3
Watch both source health states in Multiview or the operator interface.
- 4
For planned switching, use the preferred-route control; for reconnect recovery, observe the active session and output.
- 5
Simulate a source loss during a maintenance window and record recovery behavior.
Multilingual browser event from one multitrack SRT programme
Production provides one SRT/MPEG-TS programme with multiple finished language or commentary tracks.
How to build it
- 1
Receive the multitrack SRT source and confirm that every produced audio track is present.
- 2
Listen to the discovered tracks in SRT Server statistics and assign operator-readable language names.
- 3
Create one Web Player per audience language; set Modify Audio Tracks to Select Audio Track and map the intended source index.
- 4
Add those players to a Language list group and choose the default language.
- 5
Test switching, access rules and playback in a clean browser session.
Multilingual browser event from separate SRT feeds
Production supplies each finished language as an independent SRT feed instead of one multitrack programme.
How to build it
- 1
Receive and validate one independent SRT source for every produced language.
- 2
Create one Web Player per verified feed and name it for the audience.
- 3
Add those players to a Language list group and choose the default language.
- 4
Test switching, access rules and playback in a clean browser session.
Verify the result
- A real publisher and receiver remain connected for the planned test period.
- Live bitrate confirms media arrival and Network RTT remains within the tested latency budget.
- Unauthorized stream identities or hosts are rejected by the selected access policy.
- A backup-source test produces the documented recovery behavior.
Troubleshooting
Session connects but media breaks up
Check- Compare bitrate to available upload.
- Check RTT and packet-loss behavior.
- Review latency and maximum bandwidth.
Increase recovery headroom only from measured evidence; also correct the source bitrate or network bottleneck.
Publisher cannot connect
Check- Check UDP firewall and public address.
- Match port, mode, passphrase and Stream identity.
Test one publisher without downstream modules, then restore the verified receiver path.
The backup does not take over as expected
Check- Verify both sources independently.
- Review route order, mode and timeout.
- Observe the active session during failure.
Correct the failed source or routing definition and repeat a controlled failure test.