YoloLiv YoloBox Ultra bonded SRT setup: send receiver output to Callaba Gateway
A YoloLiv YoloBox Ultra bonded SRT setup should put the Ultra at the venue and send its SRT destination to a cloud SRT listener. Use this setup when YoloBox Ultra is at the venue and Callaba is the cloud SRT receiver for monitoring, recording, routing, multiview, or restreaming. If you enable YoloLiv Network Bonding, treat it as a paid connectivity layer in front of the same contribution path and confirm how its cloud or receiver handoff reaches your Callaba SRT URL before the event.
Quick answer
To use YoloLiv YoloBox Ultra with SRT, set YoloBox Ultra as the SRT Caller and send the stream to a cloud SRT Listener. In this guide, Callaba works as the SRT gateway, receiver, monitor, recorder, and routing layer. YoloLiv documents an SRT destination workflow with an SRT Server URL; if the installed firmware does not show SRT settings, update first or use the confirmed RTMP(S) fallback.
YoloBox Ultra sends one SRT contribution feed. Optional YoloLiv bonding may sit on the network path. After Callaba receives the stream, preview, recording, routing, and restreaming are parallel downstream uses, not mandatory sequential setup steps.
- YoloBox UltraSRT destination / caller
- Optional bondingPaid YoloLiv network layer
- Callaba GatewaySRT listener / receiver
- Preview
- Record
- Route
- Restream
What this setup does
YoloBox Ultra acts as the field production unit: it can take HDMI, USB, IP, media, and audio sources, mix the program, encode it, and publish an SRT or RTMP(S) stream. Callaba acts as the cloud receiver and downstream workflow point. Once the contribution feed is stable, monitoring, recording, multiview, playback, routing, and restreaming can run in parallel from the same ingest.
For a bonded production, do not assume bonding is the same as SRT encryption or SRT bonding. YoloLiv Network Bonding is a separate paid connectivity service with vendor cloud/server involvement. Direct SRT to Callaba can also be used without that service when the venue uplink is good enough.
What this model can and cannot do in this workflow
For this exact model, YoloLiv lists RTMP, RTMPS, and SRT for video over Ethernet and streaming output. YoloLiv also documents adding an SRT destination with an SRT Server URL, SRT source input, and a separate YoloBox Ultra SRT listener input workflow.
- Confirmed for YoloBox Ultra: SRT output, RTMP output, RTMPS custom destination workflow, SRT input, and SRT listener input.
- Confirmed hardware context: four HDMI inputs, two USB-A 3.0 ports, USB-C, RJ-45 Ethernet, line input, mic input, HDMI output, USB-C/UVC output, and headphone/audio output.
- Confirmed media context: H.264 and H.265/HEVC video encoding are listed, with AAC two-channel audio and MP4 recording support.
- NDI input and output are documented for YoloBox Ultra, but they require paid YoloLiv NDI activation tied to the device serial number.
- RTSP, SDI, and ST 2110 are not listed for this exact model in the sources I would use for production planning.
- Public YoloLiv SRT text does not clearly expose output passphrase, Stream ID, rendezvous mode, or exact SRT library version. Confirm those fields on the installed firmware before building a locked-down event profile.
YoloBox Pro appears in some YoloLiv RTMP(S) and NDI activation material, but this guide is for YoloBox Ultra. Do not copy a Pro-only menu assumption into an Ultra event without checking the visible Ultra firmware menus.
Recommended workflow
Use SRT first when the YoloBox Ultra shows the SRT destination menu. Create a Callaba SRT server in listener mode, open the UDP port to the internet, and paste the Callaba SRT URL into the YoloBox Ultra SRT destination field.
If you need internet bonding, enable and test YoloLiv Network Bonding separately. Its job is connectivity; Callaba still needs a reachable SRT stream or a receiver/cloud output that can send to the Callaba SRT listener. If that handoff is unclear, run a direct SRT test and an RTMPS fallback test before the show.
Use RTMPS or RTMP when SRT is not available on the installed firmware or when the destination only accepts RTMP(S). Use NDI only for a local LAN workflow or an intentional NDI-to-SRT bridge, and only after the paid NDI activation is present. Do not plan an RTSP workflow from the Ultra unless you have separate exact-model confirmation.
When not to use this setup
If YoloBox Ultra and the production switcher are in the same room, HDMI output may be simpler than a cloud SRT path. If the only destination is a public platform and you do not need cloud monitoring, recording, routing, or multiview, the confirmed RTMPS workflow may be enough. If the job depends on local NDI, budget and activate the YoloLiv NDI option in advance. If an RTSP camera must enter Callaba, use a separate RTSP-to-SRT or RTSP-to-RTMP bridge because RTSP is not confirmed as a YoloBox Ultra output path.
Before you start
- Update the YoloBox Ultra and confirm that the SRT destination menu is visible.
- Choose a Callaba public address and UDP port that the venue network can reach.
- For the first SRT test, keep Stream ID and passphrase disabled unless your YoloBox firmware clearly exposes matching fields. If you use them, treat both as case-sensitive and whitespace-sensitive; a trailing space or copied newline can break the handshake.
- Start with H.264 unless your whole playback and decoder chain supports HEVC.
- For internet tests, start SRT latency around 250-500 ms and lower it only after RTT, packet loss, and retransmits are stable.
- If a handshake fails after network checks, confirm SRT version compatibility through firmware release notes, vendor support, and Callaba server build/support information.
Create the Callaba ingest
In Callaba, create an SRT server, choose the listening UDP port, and copy the listener URL. Make sure the cloud firewall or security group allows inbound UDP on that port. For the first test, I prefer a simple listener profile without encryption or Stream ID, then add restrictions after the basic video and audio path is proven.
Configure YoloBox Ultra
On YoloBox Ultra, open the destination area, add an SRT destination, and paste the Callaba SRT Server URL. Select the program output you want to send, start streaming, and watch Callaba for connection uptime and incoming bitrate. If you are testing the Ultra as an SRT receiver instead, YoloLiv documents an SRT listener input URL workflow, but that is not the default cloud contribution direction because it usually requires inbound UDP reachability at the venue.
Settings table
| Where | What to do / field to fill | First-test value | Why / check |
|---|---|---|---|
| Callaba SRT servers | Create SRT server and choose UDP listen port | Use an open high UDP port | Server should show waiting or listening before the YoloBox starts |
| Cloud firewall | Allow inbound UDP to the Callaba SRT port | Same port as the SRT server | No packets means no handshake |
| Callaba SRT options | Stream ID and passphrase | Blank for first test | Add only if matching YoloBox fields are visible and tested |
| YoloBox Ultra Destination tab | Add SRT destination and paste SRT Server URL | Callaba listener URL | Callaba should show uptime and bitrate |
| YoloBox Ultra video encoding | Choose codec and bitrate | H.264; 1080p30 about 4-6 Mb/s | Use HEVC only when downstream support is confirmed |
| YoloBox Ultra audio | Select the correct audio source and AAC output | 48 kHz AAC if available | Check Callaba audio meters and preview |
| YoloBox Ultra network | Use Ethernet, Wi-Fi, cellular dongles, or paid bonding | Wired Ethernet for the first test | Bonding should be tested as connectivity, not assumed |
| Callaba monitoring | Watch bitrate, RTT, loss, retransmits, and uptime | Stable bitrate, low loss | Confirms the contribution path is usable |
Monitoring
After the YoloBox connects, verify more than the preview picture. In Callaba, check incoming bitrate, connection uptime, RTT, packet loss, retransmits, video preview, and audio meters. If optional YoloLiv bonding is enabled, compare Callaba statistics with the bonding status so you know whether a problem is SRT, encoding, or uplink aggregation.
Failover and local ingest options
For production events, plan what happens if the main encoder, venue uplink, or primary contribution path fails. Callaba can be part of that continuity plan without changing the basic YoloLiv YoloBox Ultra ingest workflow.
Recording and playback
Use Callaba recording after the SRT ingest is stable. YoloBox Ultra also lists MP4 recording support, so a local recording can be a useful backup at the venue. Treat local recording and Callaba recording as parallel safety options, not as a required sequence. For playback or browser preview, confirm that your viewers and decoders support the chosen codec, especially if you switch from H.264 to H.265/HEVC.
Troubleshooting
| Symptom | Check in Callaba | Check on YoloBox Ultra | Likely fix |
|---|---|---|---|
| No connection | SRT server listening, public IP, UDP firewall | SRT destination URL and network status | Correct URL/port and open UDP inbound to Callaba |
| Connects then drops | RTT, packet loss, retransmits, uptime | Wi-Fi/cellular strength or bonding status | Raise SRT latency, reduce bitrate, use Ethernet or tested bonding |
| Black video | Preview and codec information | Program output and encoder codec | Start with H.264 and verify the active program source |
| No audio | Audio meters and recording audio track | Line/mic source, HDMI audio, mute state | Select the correct source and confirm AAC audio |
| Handshake fails with security enabled | Stream ID and passphrase values | Whether matching fields exist on firmware | Remove security for a test, then re-enter exact case and spacing |
| Need RTSP input to Callaba | Bridge ingest health | RTSP is not confirmed for Ultra output | Use a separate RTSP-to-SRT or RTSP-to-RTMP bridge |
Official references
Vendor references
- YoloBox Ultra technical specifications
- YoloLiv SRT setup guide for YoloBox Ultra
- YoloBox Ultra SRT listener guide
- YoloLiv RTMP(S) custom destination guide
- YoloLiv NDI guide for YoloBox Ultra
- YoloLiv NDI activation store page
- YoloLiv Network Bonding
Protocol references
Callaba resources
FAQ
Can YoloBox Ultra send SRT to Callaba?
Yes. YoloLiv documents SRT output and an SRT destination workflow for YoloBox Ultra. Use Callaba as the cloud SRT listener and paste the Callaba SRT Server URL into the YoloBox destination setup.
Can YoloBox Ultra work as an SRT receiver?
YoloLiv documents an SRT listener input function for YoloBox Ultra. I would treat that as an advanced receiving workflow because the venue side may need inbound UDP, firewall rules, port forwarding, or a tested NAT plan.
Does bonded SRT require YoloLiv Network Bonding?
No. Direct SRT to Callaba can run over normal internet. YoloLiv Network Bonding is optional and paid; use it when you need aggregated venue connectivity and have tested its cloud/receiver handoff.
Can I use RTMP or RTMPS instead?
Yes. YoloLiv documents custom RTMP(S) destinations for YoloBox Ultra. RTMPS is a practical fallback when SRT settings are unavailable or a platform only accepts RTMP(S).
Can I use NDI with this workflow?
Yes, but NDI on YoloBox Ultra requires paid serial-number activation. Use it for local LAN production or an intentional NDI-to-SRT bridge, not as an assumed cloud contribution path.
Does YoloBox Ultra support RTSP output to Callaba?
I would not plan that. The exact-model sources used here confirm SRT and RTMP(S), but do not list RTSP for this workflow. Use a separate RTSP bridge if an RTSP source must enter Callaba.
Next steps
Run a short SRT test with H.264, no Stream ID, and no passphrase first. After video, audio, RTT, packet loss, and retransmits look stable in Callaba, add the security fields your firmware exposes, save an RTMPS fallback, and do a longer soak test on the same network path you will use for the event.
Try Callaba Gateway with YoloBox Ultra SRT setup
Create an SRT server in Callaba, send the device feed to the gateway, and check the received stream. After ingest is stable, use Callaba outputs for preview, recording, restreaming, multiview, playback, routing, or API workflows as parallel downstream options.
