LiveU Solo bonded SRT setup: send receiver output to Callaba Gateway
Written by Iurii Pakholkov
Founder of Callaba. Building cloud video tools for SRT, RTMP, WebRTC, NDI, live routing, monitoring, recording, and production workflows.
Release: Callaba 8.4
LiveU Solo bonded SRT setup is a cloud-output workflow, not a direct SRT send from the unit. Use this setup when Solo is at the venue and Callaba is the cloud SRT receiver for monitoring, recording, routing, multiview, or restreaming. The Solo takes HDMI or SDI program video, sends a bonded LRT uplink to LiveU cloud, and LiveU cloud sends SRT Caller to a Callaba SRT Listener.
Quick answer
To use LiveU Solo with bonded SRT, create an SRT Listener in Callaba, then configure the Solo Portal SRT destination so the LiveU cloud sends SRT Caller to that listener. In this guide, Callaba works as the SRT gateway, receiver, monitor, recorder, and routing layer after the LiveU cloud output.
The Solo sends one field contribution feed to the LiveU cloud. The cloud sends SRT Caller to Callaba. Preview, recording, routing, and restreaming are parallel downstream uses after ingest, not mandatory sequential setup steps.
- Camera / switcherHDMI or SDI
- LiveU Solobonded LRT uplink
- LiveU cloudSRT Caller output
- Callaba GatewaySRT Listener
- Preview
- Record
- Route
- Restream
What this setup does
This workflow is for remote contribution where the Solo is the field transmitter and Callaba is the internet-facing SRT gateway. It is useful when a production team needs a cloud SRT receiver, live preview, confidence monitoring, recording, API control, restreaming, or routing to another destination after the bonded field path has reached LiveU cloud.
The important distinction is direction. The Solo unit does not open a direct SRT session to Callaba. In the documented Solo workflow, the unit sends LRT to LiveU cloud, and the cloud initiates an SRT Caller connection to the SRT Listener you create in Callaba.
What this model can and cannot do in this workflow
- Confirmed: SRT output is available through the LRT cloud workflow, with SRT Caller mode from LiveU cloud.
- Confirmed: the SRT destination fields include Primary URL, Stream ID, optional passphrase, latency, and codec selection.
- Confirmed: Solo SRT support requires an LRT subscription and Solo firmware 7.1 or later.
- Confirmed: base LiveU Solo specifications list H.264 AVC High Profile video and AAC-LC audio. Do not plan HEVC on base Solo.
- Confirmed: Solo PRO differs from base Solo: LiveU documents HEVC choices for Solo PRO SRT workflows, while RTMP is not the HEVC transport path.
- Confirmed: RTMP Direct can send RTMP from the Solo unit, but that mode does not provide multi-connection bonding.
- Confirmed: RTMPS is supported for Solo destinations.
- Confirmed limitation: public Solo documentation reviewed does not list RTSP, NDI, or ST 2110 for this model. Do not plan LiveU Solo as a native NDI or RTSP source.
- Hardware note: Solo accepts HDMI, and the HDMI/SDI model accepts 3G/HD/SD-SDI; only one camera or program source can be connected directly at one time.
Recommended workflow
For a LiveU Solo SRT gateway workflow, I recommend using the documented cloud output path: program video into Solo, bonded LRT to LiveU cloud, SRT Caller from LiveU cloud to Callaba. This keeps the Solo in the role it was designed for: field contribution over multiple network links.
After Callaba receives the stream, treat preview, recording, multiview, routing, restreaming, and playback as parallel downstream choices. Do not build an operational checklist that depends on preview before recording or recording before routing unless your production policy requires that sequence.
When not to use this setup
If the only target is YouTube, Facebook, Twitch, or another public platform and you do not need cloud monitoring, routing, recording, or a separate receiver, Solo RTMP or RTMPS destinations may be enough.
If you need a private direct path without LiveU cloud, the confirmed direct option for Solo is RTMP Direct, not direct SRT. Be aware that RTMP Direct gives up Solo bonding. If all devices are on the same site, local SDI or HDMI from the production switcher may be simpler than routing through a cloud gateway.
If your source is already NDI or RTSP, bridge it before the Solo with separate hardware or software, or use a different encoder that officially lists the required IP input. Do not assume Solo can ingest NDI or RTSP.
Before you start
- Confirm the exact unit: base LiveU Solo and Solo PRO have different codec expectations.
- Confirm Solo firmware 7.1 or later for Solo SRT support.
- Confirm the LRT subscription and the selected cloud zone in the Solo Portal.
- Prepare a public DNS name or IP address for Callaba, plus an allowed UDP port for SRT.
- Decide whether to use Stream ID and passphrase. Treat both as case-sensitive and whitespace-sensitive. A copied newline, trailing space, or changed capitalization can break the handshake.
- If a hard-to-diagnose SRT handshake fails, confirm Solo firmware and vendor support information for SRT compatibility, and compare it with the Callaba server build or support information.
Create Callaba ingest
In Callaba, create an SRT server for the incoming Solo cloud output. Use Listener mode, choose a UDP port, and make sure your firewall or cloud security group allows inbound UDP on that port. If you use an access rule, Stream ID, or passphrase, write the values down exactly before opening the Solo Portal.
For a first test, use a simple dedicated port such as 22000 if it is available in your environment. Start the SRT server, then watch the input state, incoming bitrate, connection uptime, RTT, packet loss, retransmits, preview, and audio meters when the Solo stream starts.
Configure LiveU Solo
In the Solo Portal, add a new SRT destination and select the SRT Caller destination type for Solo. For Primary URL, enter the Callaba public address and UDP port in the form srt://your-callaba-host:22000. Add the Stream ID and passphrase only if you configured matching values on the Callaba side.
Set SRT latency in the Solo destination. LiveU documentation gives 500 ms as a normal internet starting point; raise it if the route is unstable, and lower it only after RTT, packet loss, and retransmits are stable. For base Solo, plan H.264. Use HEVC only when the exact unit is Solo PRO and the receiving workflow supports it.
Settings table
| Where | What to do / field to fill | First-test value | Why / check |
|---|---|---|---|
| Callaba | Create SRT server and choose UDP port | 22000 if available | Callaba must be listening before LiveU cloud calls in. |
| Callaba | Stream ID or access identifier | solo-main | Must match the Solo Portal value exactly if used. |
| Callaba | Passphrase for encrypted SRT | Use one strong event passphrase, or leave empty on both sides | Passphrase mismatch prevents connection. |
| Solo Portal | Primary URL | srt://your-callaba-host:22000 | This is where LiveU cloud sends SRT Caller. |
| Solo Portal | Stream ID | solo-main | Case and whitespace must match Callaba. |
| Solo Portal | Passphrase | Same value as Callaba | Use the same value on both ends or disable it on both ends. |
| Solo Portal | Latency | 500 ms | Good first internet test; increase for unstable routes. |
| Solo Portal | Codec | H.264 for base Solo | Use HEVC only for confirmed Solo PRO workflows and compatible receivers. |
Monitoring
When the Solo starts streaming, Callaba should show an active SRT connection from the LiveU cloud path, not from the local venue IP. Check incoming bitrate first, then preview video, audio meters, packet loss, retransmits, RTT, and connection uptime. If bitrate appears but preview does not, look at codec, resolution, audio format, and player support before changing network settings.
Failover and local ingest options
For Solo jobs, failover planning should protect what happens after the cloud SRT output reaches Callaba. It does not remove the need to test the venue uplink, LRT service, and cloud destination before the event.
Recording and playback
Once Callaba receives the SRT feed, you can record the incoming program, create browser preview links, feed multiview, route to another SRT destination, or restream. Keep the first test simple: receive the stream, confirm audio and video, then enable recording and playback outputs after the ingest is stable.
Troubleshooting
| Symptom | Check in Callaba | Check on Solo / portal | Likely fix |
|---|---|---|---|
| No connection | SRT server running, UDP port open, listener port correct | Primary URL host and port | Fix firewall, DNS, or port mismatch. |
| Connection retries | Stream ID and passphrase rules | Stream ID and passphrase fields | Remove copied spaces or mismatched capitalization. |
| Connects, then drops | RTT, loss, retransmits, uptime | SRT latency and LRT cloud zone | Increase latency, choose a better zone, or reduce bitrate. |
| Video but no audio | Audio meters and player output | Input signal and embedded audio | Confirm AAC-compatible output and source audio routing. |
| No HEVC playback | Decoder/player codec support | Exact unit model and codec field | Use H.264 for base Solo or unsupported playback paths. |
| Need direct private delivery | Consider RTMP server input | RTMP Direct mode | Use RTMP Direct only if losing bonding is acceptable. |
Official references
Useful reader resources for this setup:
Vendor references
- LiveU Solo: Is SRT supported?
- LiveU Solo: How to set up an SRT destination
- LiveU Solo: LRT and Solo Connect
- LiveU Solo: RTMP Direct mode
- LiveU Solo: RTMPS support
- LiveU Solo: Video settings
- LiveU Solo datasheet
Protocol references
Callaba resources
FAQ
Is LiveU Solo an SRT Caller or SRT Listener in this setup?
For this workflow, the SRT Caller is the LiveU cloud output. Callaba should be the SRT Listener. Public Solo documentation does not confirm SRT Listener or Rendezvous operation for the Solo cloud SRT destination.
Can LiveU Solo send SRT directly to Callaba without LiveU cloud?
Do not plan that path for Solo. The documented SRT path uses LRT to LiveU cloud, then SRT Caller from the cloud to Callaba.
What is the Solo SRT receiver or Solo SRT server in this workflow?
Callaba is the SRT receiver/server side. More precisely, Callaba runs the SRT Listener and receives the SRT Caller connection from LiveU cloud.
Does LiveU Solo support RTMP or RTMPS instead?
Yes. RTMP Direct is confirmed from the unit, but it does not bond multiple connections. RTMPS is also confirmed for Solo destination workflows.
Does LiveU Solo support NDI or RTSP?
Public Solo sources used for this guide do not list NDI or RTSP for this model. Use HDMI or SDI into the Solo, or bridge NDI/RTSP before the encoder with separate equipment.
Can I use HEVC with LiveU Solo bonded SRT?
Use H.264 for base LiveU Solo. HEVC is documented for Solo PRO SRT workflows, so confirm the exact hardware, selected zone, and downstream decoder support before choosing it.
Next steps
Build the Callaba SRT Listener first, copy the exact address, port, Stream ID, and passphrase, then configure the Solo Portal SRT destination. Test with H.264, 500 ms latency, and one clean program source before adding recording, multiview, routing, or restreaming outputs.
Try Callaba Gateway with LiveU Solo bonded SRT
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.