Start with one camera, one mobile sender, and one receiving SRT endpoint. Make the field encoder call the endpoint, verify the picture and programme audio at the destination, then add the production job you need. That short path gives the crew a baseline they can repeat at the actual venue.
Prove the contribution path first
For the first field test, use one camera, its encoder or mobile contribution app, one 5G connection, and one Callaba SRT Server. The sender normally acts as the caller: it initiates an SRT session to the listener at the destination. Caller and listener describe the handshake role, not the direction of the video.
- Camera: provide a known video format and audio layout.
- Mobile sender: publishes that feed while calling the receiving endpoint over 5G.
- Callaba SRT Server: accepts the configured contribution.
- Monitoring or production destination: confirm decoded picture and programme audio before relying on the feed.
A connected indicator is only the first checkpoint. Confirm the camera label, moving picture, and intended audio pair; those checks catch a stale test loop and a wrong source early.
Copy the endpoint exactly
Create the receiving SRT Server, then copy its host, assigned UDP port, access model, Stream ID where required, and encryption settings. Use the values from the current server configuration. A port in an old screenshot is not an endpoint for this event.
Set the field sender to mode=caller when it must initiate the connection to the Callaba listener. For an FFmpeg-compatible sender, latency=200000 in the URL means 200 ms. Native SRT APIs and encoder interfaces may expose a different option and unit; use that product's documented field rather than copying the URL value.
srt://YOUR_CALLABA_HOST:YOUR_ASSIGNED_UDP_PORT?mode=caller&latency=200000&streamid=YOUR_ASSIGNED_STREAM_IDThis FFmpeg-compatible syntax example is not a reusable endpoint or a prescribed latency. Where the server uses separate publisher and receiver identities, follow that configured pattern. A Stream ID mismatch is one legitimate reason for a listener to refuse a session.
Name the camera and record the sender preset, SIM or carrier, location, and test time. Those details make a later venue result comparable with the preflight.
Create an SRT test endpoint for the field sender
Use this Callaba SRT demo to obtain a short-lived publisher endpoint for your own encoder or software sender. The generated demo URL uses its own host and port; it deliberately does not include a Stream ID. It is a connection test, not a 5G benchmark.
- Copy the generated publisher URL into the sender; do not reuse the syntax example in this article.
- Send your own MPEG-TS/SRT test feed from the same mobile network intended for the event.
- Use the optional public Multiview preview to view the received feed after the publisher connects; it is viewing-only.
- Record the observed bitrate, interruptions, location, and test duration in your field worksheet.
Create a temporary session, then use your own SRT sender to rehearse a connection or reconnect.
Live SRT demo
Try a live SRT connection
Create a temporary connection for one hour. Send your feed to the publisher address in Caller mode, leaving Stream ID empty. Watch it in Multiview below, or connect your receiver to the receiver address in Caller mode.
Set a field budget from the actual feed
Use a sustained send from the intended position, not a short speed test, to size the contribution. Start with the encoder's video bitrate plus audio and transport overhead. Then compare that planned rate with the lowest sustained uplink observed while the camera is working.
| Worksheet item | Write down |
|---|---|
| Planned source rate | Video bitrate + audio bitrate + the allowance used for transport overhead. |
| Lowest sustained uplink | The lowest result seen during a real contribution run at the intended position. |
| Transport behaviour | Loss bursts, round-trip-time variation, retransmission evidence where the sender exposes it. |
| Source condition | Encoder temperature, battery or modem power, and any handover or movement during the test. |
| Decision | Keep the preset, lower its rate, select another path, or add a tested backup. |
SRT latency is a transport recovery allowance, not the complete lens-to-screen delay. Camera processing, encoding, decoding, and the player contribute their own time. Adjust the buffer only after a full-path test shows what the route needs.
Verify the contribution before you build outputs around it
Once the sender calls in, open the expected received stream in Multiview and check decoded picture and programme audio. A frozen image, wrong camera, silent channel, or stale test loop requires attention even when the transport is connected.
Then test the downstream job that matters for the event: make a short recording and open the file; select the exact source in the production workspace; or check the destination output at its real player or decoder. Each is a separate checkpoint.
Let the feed run through ordinary camera movement and the place where it will be used. Change one variable at a time—bitrate, location, carrier path, or SRT buffer—so the next result is interpretable.
Keep a fallback that matches the failure
A local recording preserves the event; a second live contribution keeps a remote production supplied. For a prepared SRT main/backup pair, Callaba's SRT Main/Backup Failover preset creates the source servers, failover routing and a Multiview board. On an empty, unfiltered SRT servers list, choose it under Create From Template, select the layout and click Create this preset. Keep existing servers on a populated installation; use its configured failover route instead of deleting anything to reveal the shortcut.
Send the preferred and alternate contributions to their respective publisher addresses, and connect the downstream receiver to the failover output. In the operator's Multiview, open the FINAL MIX input menu, choose Source route, then select the backup route. Check the destination's picture and sound; select main through the same menu to return. A public viewing link cannot operate these controls, and this manual selection does not establish an automatic failure policy.
Before the event, save the known-good sender preset and write down the endpoint values without exposing the passphrase in a public call sheet. Test from the actual source network. If the stream fails at the last minute, first compare host, UDP port, caller/listener role, Stream ID, and passphrase; then verify the received media. Re-encoding, swapping codecs, and random port changes are poor first moves when the route itself has not been proven.
Next steps
Use the SRT demo when you need a short-lived endpoint for a sender test. For an event configuration, use the SRT Server guide and retain the endpoint values and field worksheet with the production notes.
