LiveU Solo Pro 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
For a LiveU Solo Pro bonded SRT setup, the practical path is not the field unit sending SRT straight to Callaba. Use this setup when Solo Pro is at the venue and Callaba is the cloud SRT receiver for monitoring, recording, routing, multiview, or restreaming. Solo Pro contributes through LiveU LRT to the LiveU cloud, and the cloud output calls a Callaba SRT Listener.
Quick answer
To use LiveU Solo Pro with SRT, create an SRT Listener in Callaba and configure the Solo portal destination as SRT-OUT-Caller-Solo. The SRT caller is the LiveU cloud output leg; Callaba works as the SRT gateway, receiver, monitor, recorder, and routing layer.
The venue source enters Solo Pro, Solo Pro contributes through LiveU LRT to the LiveU cloud, and the LiveU cloud sends SRT Caller output to Callaba. Callaba preview, recording, routing, and restreaming are parallel downstream uses after ingest.
- HDMI or SDIOne camera source
- Solo ProLRT bonded uplink
- LiveU cloudSRT Caller output
- Callaba GatewaySRT Listener
- Preview
- Record
- Route
- Restream
What this setup does
This workflow gives production teams a cloud receiver for a Solo Pro remote contribution feed. The venue operator connects a camera or switcher to Solo Pro, starts the bonded LiveU workflow, and sends the cloud-side SRT output to Callaba. In Callaba, the same received feed can be watched, recorded, routed to another SRT destination, restreamed to RTMP/RTMPS, or placed into multiview.
The important role clarification: searched phrases such as Solo Pro SRT output, Solo Pro SRT receiver, Solo Pro SRT to cloud, and LiveU Solo Pro SRT gateway all point to the same architecture. Solo Pro is the field transmitter. Callaba is the SRT receiver/listener. The LiveU cloud is the layer that makes the SRT caller connection to Callaba.
What this model can and cannot do in this workflow
- Confirmed contribution path: Solo Pro sends LRT from the unit to the LiveU cloud; SRT Caller is on the LiveU cloud output leg.
- Confirmed SRT fields: SRT URL, Stream ID, optional passphrase, latency, codec selection, and SRT-OUT-Caller-Solo destination type.
- Callaba role: configure Callaba as the SRT Listener on a public UDP port reachable from the LiveU cloud.
- Inputs: Solo Pro is available in HDMI and SDI/HDMI variants. The brochure lists HDMI 2.0 and 12G/3G/HD/SD-SDI, but the user guide tells operators to use one direct camera source at a time.
- Codecs: H.264 is the safe first test. HEVC/H.265 is available for Solo Pro SRT/LRT workflows, but LiveU states HEVC is not used in RTMP. Confirm HEVC support in every downstream decoder or player.
- 4K: LiveU documents 4K support for Generic and SRT-OUT-Caller destination types when the input is really 4K.
- RTMP/RTMPS: RTMP and RTMPS are valid alternatives, but RTMP Direct trades away bonding because it sends RTMP from the unit without the bonded LRT path.
- Not confirmed for this model: RTSP, NDI, SRT Listener, SRT Rendezvous, ST 2110, and local decoder-style SDI/HDMI output.
Close variant note: LiveU documentation distinguishes Solo Pro HDMI and Solo Pro SDI / SDI-HDMI hardware variants. Use the variant that matches the physical camera or switcher output; do not connect HDMI and SDI sources as two simultaneous camera inputs on the same Solo Pro.
Recommended workflow
For remote production, I recommend the bonded path: camera or switcher into Solo Pro, LRT from Solo Pro to the LiveU cloud, SRT Caller from the LiveU cloud to Callaba, then Callaba downstream outputs as needed. This keeps the resilient venue uplink and gives the production team cloud-side inspection before the feed is sent further.
If the only goal is to hit one public platform and you do not need cloud monitoring, recording, or routing, a platform RTMP/RTMPS destination may be simpler. If the job needs a clean handoff to production, Callaba gives you a controllable receive point and a place to confirm bitrate, packet loss behavior, uptime, preview, and audio before distribution.
When not to use this setup
- If the camera and switcher are in the same room, a local SDI or HDMI cable from the camera/switcher may be simpler than a cloud contribution path.
- Do not plan Solo Pro as a native NDI source. NDI is not officially confirmed for this model in the reviewed Solo Pro materials.
- Do not use RTMP Direct when bonded cellular resilience is the reason you chose Solo Pro. LiveU states RTMP Direct cannot bond multiple connections.
- If your downstream destination cannot decode HEVC, choose H.264 even if HEVC is available in the Solo Pro SRT destination.
Before you start
Prepare a Callaba instance with a public hostname or IP address and an open UDP port for SRT. In the Solo portal, make sure the unit is registered, has the required LRT service for bonded/SRT use, and is on firmware suitable for your event. For SDI four-channel audio over SRT, use current firmware and rehearse the channel mapping before the production day.
Also confirm the SRT implementation compatibility if a handshake fails in a way that does not match normal firewall or passphrase errors. Public LiveU docs do not publish an exact SRT library version, so use firmware release notes or vendor support for the Solo side and Callaba release/support information for the gateway side.
Create the Callaba ingest
In Callaba, create an SRT server for the Solo Pro contribution. Set it to listen on a dedicated UDP port, for example 22000 for a first lab test, and open that port in the cloud firewall or security group. If you use Stream ID and passphrase, copy the exact values into your run sheet.
Success looks like a waiting listener in Callaba before the Solo stream starts. If Callaba never sees a connection attempt, check the public IP/hostname, UDP firewall rule, and whether the Solo destination is pointed at the exact same port.
Configure Solo Pro
In the Solo portal, add a destination and choose SRT-OUT-Caller-Solo. In the Primary URL, enter the Callaba address in the form srt://your-callaba-host:22000. Add the Stream ID if your Callaba server expects one. Add the passphrase only if the Callaba side uses the same passphrase.
For the first test, use H.264 and the default 500 ms SRT latency unless your measured network round trip is high. After video and audio are stable, test HEVC only if the complete downstream path supports it. Stream ID and passphrase are case-sensitive and whitespace-sensitive; a trailing space, copied newline, or changed capitalization can break the connection.
Settings table
| Where | What to do / field to fill | First-test value | Why / check |
|---|---|---|---|
| Callaba | Create SRT server and choose UDP port | 22000 or another dedicated open UDP port | Port must be reachable from the LiveU cloud. |
| Callaba | Enable Listener receive behavior for that SRT server | Listener waiting before Solo starts | The LiveU cloud makes the caller connection. |
| Solo portal | Destination type | SRT-OUT-Caller-Solo | This is the documented Solo SRT destination type. |
| Solo portal | Primary URL | srt://your-callaba-host:22000 | Use the Callaba public hostname/IP and UDP port. |
| Solo portal | Stream ID | Match Callaba exactly, or leave unused if not required | Check spelling, capitalization, and hidden whitespace. |
| Solo portal | Passphrase | Match Callaba exactly when encryption is used | Both sides must use the same passphrase. |
| Solo portal | Latency | 500 ms for a first internet test | Raise it if RTT, loss, or retransmits are unstable. |
| Solo portal | Codec and profile | H.264 first; HEVC only after downstream validation | Use constant mux rate profiles for hardware decoders unless a software destination needs No Nulls. |
Monitoring
When the stream starts, check Callaba for connection uptime, incoming bitrate, preview, audio meters, RTT, packet loss, and retransmits. At the same time, check the Solo portal for input detection, active network links, streaming state, and whether the destination keeps retrying or stays connected.
If the feed is for a live production, I like to run a rehearsal with the same camera format, audio channel plan, codec, SRT profile, and venue network mix. A test with H.264 can confirm the path; a second test with HEVC can confirm codec compatibility if you plan to use it on air.
Recording and playback
After Callaba receives the SRT feed, recording and playback are downstream choices, not setup prerequisites. You can record the received contribution, create a web player for review, route the source to another SRT endpoint, restream to an RTMP/RTMPS destination, or add it to multiview in parallel. Keep the ingest test separate from the downstream distribution test so failures are easier to isolate.
Troubleshooting
| Symptom | Check in Callaba | Check on Solo Pro / portal | Likely fix |
|---|---|---|---|
| No connection | SRT server is listening; UDP port is open; no firewall block | Destination type is SRT-OUT-Caller-Solo; Primary URL has correct host and port | Fix DNS/IP, security group, or port. Confirm the LiveU cloud can reach the Callaba port. |
| Connects then drops | RTT, packet loss, retransmits, uptime resets | Cellular/Wi-Fi/Ethernet health and LRT status | Raise SRT latency, reduce bitrate/profile, improve uplinks, or change network mix. |
| Black preview or no audio | Preview, codec detection, audio meters | Camera input format, one HDMI/SDI source only, audio channel settings | Start with H.264, confirm supported resolution, and test SDI audio mapping on the installed firmware. |
| HEVC fails downstream | Receiver/player codec support and recording playback behavior | Codec selector set to HEVC only for SRT destination | Use H.264 or update the downstream decoder/player to support HEVC. |
| Handshake fails with encryption | Passphrase and Stream ID exactly match the listener | Copied values in the destination page | Remove trailing spaces/newlines, match capitalization, and confirm compatible SRT versions. |
Official references
Useful sources for operators planning this workflow:
Vendor references
- LiveU Solo Pro product page
- LiveU Solo Pro brochure
- LiveU Solo Pro User Guide Rev A02
- LiveU Solo SRT destination setup
- LiveU Solo SRT support FAQ
- LiveU Solo Pro HEVC streaming guide
- LiveU RTMP Direct mode FAQ
- Solo Pro 10.6.5 release notes
Protocol references
Callaba resources
FAQ
Can LiveU Solo Pro send SRT to Callaba?
Yes, but through the LiveU cloud output leg. Configure Callaba as an SRT Listener and configure the Solo portal destination as SRT-OUT-Caller-Solo.
Is Solo Pro the SRT receiver or SRT server in this setup?
No. In this workflow, Callaba is the SRT receiver/listener. The LiveU cloud calls out to Callaba.
Can I use SRT Listener or Rendezvous mode on Solo Pro?
The reviewed Solo Pro documentation confirms SRT Caller output from the LiveU cloud. It does not confirm Solo Pro Listener or Rendezvous output modes for this workflow.
Should I use H.264 or HEVC?
Use H.264 for the first test. Use HEVC only after you confirm the Callaba-side workflow and every downstream decoder, player, or platform supports it.
Can I use RTMP Direct instead?
You can use RTMP Direct for some simple cases, but LiveU states it cannot bond multiple connections. Do not use it when bonded cellular resilience is required.
Does Solo Pro support NDI or RTSP into Callaba?
NDI and RTSP are not officially confirmed for this model in the reviewed Solo Pro sources. Use the SRT cloud-output path or confirmed RTMP/RTMPS destinations instead.
Next steps
Build the ingest first: Callaba SRT Listener, open UDP port, Solo portal SRT-OUT-Caller-Solo destination, H.264, and 500 ms latency. Once the connection is stable, add recording, multiview, restreaming, API automation, or routing as parallel downstream tasks. Before the event, confirm firmware, SRT caller/listener direction, Stream ID, passphrase, codec, profile, audio mapping, and destination firewall rules.
Try Callaba Gateway with LiveU Solo Pro 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.