LiveU Solo and Solo Pro integration
Send a LiveU Solo production to Callaba through LiveU’s SRT output
The important detail is the middle of the path. A LiveU Solo or Solo Pro does not use the workflow documented here to open an SRT session directly from the unit to Callaba. The unit sends its bonded LRT contribution to the LiveU cloud. LiveU then creates an SRT Caller output, and Callaba receives that output as an SRT Listener.
The connection contract
Media path: camera → Solo or Solo Pro → LRT → LiveU cloud → SRT Caller → Callaba Listener. This architecture lets the field unit use LiveU’s bonding path while Callaba becomes the controlled receiving point for browser Multiview, recording, routing, or onward delivery.
LiveU documents SRT output as an LRT subscription feature. Its support material lists Solo firmware 7.1 or later and Solo Pro as supported devices for this workflow. Confirm the active subscription and the current state of the account before arriving on location; a correct Callaba listener cannot make an unavailable LiveU destination type appear.
The two moving markers intentionally separate the LRT and SRT legs. They do not represent measured delay or bonding state. Motion is removed for reduced-motion users.
Check the prerequisites before building the destination
Start in the LiveU Solo Portal and verify that the intended unit is online and associated with the account. Confirm its software is supported by LiveU’s current SRT guidance. For an original Solo, that guidance specifies firmware 7.1 or later; Solo Pro is also listed. Confirm that the account has the LRT subscription required for the SRT output feature.
The codec choice also depends on the device. LiveU’s destination form exposes a codec option, but its support article notes that HEVC is available only with Solo Pro. Do not select HEVC merely because the receiving platform can decode it. The encoder, LiveU service, Callaba input, recorder, player, and every onward destination must share the same media expectation.
Finally, decide which system provides each piece of evidence. The Solo Portal proves the unit and LRT contribution. The LiveU destination state proves the cloud output. Callaba proves the arriving SRT session and any explicitly configured downstream job. One green status cannot stand in for all three.
Prepare Callaba before creating the LiveU output
- Create an SRT Server in Callaba and configure it as the receiving Listener for this production. Follow the current dashboard procedure in the SRT Server user guide.
- Choose a reachable host and UDP listener port. Apply the required cloud firewall, host firewall, and network rules. Restrict the source when the LiveU egress address and event design make that practical.
- Define the publisher identity. When a Stream ID is part of the access policy, keep its exact value ready for the LiveU destination form. If encryption is required, prepare the matching passphrase without placing it in screenshots or shared notes.
- Start the listener and keep the Callaba live state visible. Create the LiveU destination against an already-running receiver so the first test has a clear result.
Map the LiveU destination fields to Callaba
LiveU’s documented destination type is SRT-OUT-Caller-Solo. The destination originates an SRT Caller session from the LiveU cloud, so Callaba must be listening. The interface can change, but the field contract remains explicit.
| LiveU destination field | Callaba value | Operator check |
|---|---|---|
| Destination type | SRT-OUT-Caller-Solo | Confirms that LiveU cloud calls a receiving listener. |
| URL | The reachable Callaba listener host and UDP port. | Use the exact event endpoint; do not substitute a demo address. |
| Stream ID | The approved Callaba publisher identity, when used. | Match spelling, punctuation and case with the listener policy. |
| Passphrase | The matching SRT encryption passphrase, when enabled. | Treat it as a secret and change both ends together. |
| Latency | The SRT latency selected for this measured path. | LiveU’s form may start at 500 ms; that is a starting control value, not a universal recommendation. |
| Codec | The codec the Callaba workflow and downstream consumers expect. | HEVC in this Solo workflow is limited by LiveU to Solo Pro. |
Save the destination, assign it to the intended Solo production, and start the output according to the current Solo Portal. Avoid changing codec, latency, Stream ID, passphrase, and network rules in one attempt. A single-variable test makes a failed handshake diagnosable.
Prove the complete field-to-cloud path
Begin with a real camera and audio source. Confirm the Solo unit is sending and that the LRT contribution is stable in LiveU. Then confirm the SRT output is active. In Callaba, require a sustained incoming session and plausible bitrate, but do not stop there. Put the feed into one configured Multiview tile or make a short recording, then watch and listen to it.
This three-layer proof avoids a common mistake: troubleshooting SRT when the unit has not reached LiveU cloud, or troubleshooting the field unit when the SRT output is running but a downstream player is misconfigured. Record timestamps for each layer so support teams can compare the same incident window.
Rehearse a reconnect. Interrupt the field contribution in a controlled test, restore it, and observe how the LiveU and Callaba states recover. Do not promise automatic program failover from this single-source recipe. A resilient production needs a separately designed alternate path and an explicit switching policy.
What Callaba can do after receipt
Once the SRT output is present, Callaba can make the feed visible in a browser Multiview, record the received program, route it into another SRT workflow, or prepare another supported output. Those are independent production choices. The LiveU cloud output remains the contribution boundary; Callaba does not recreate the mobile bonding performed upstream.
For repeat productions, the SRT Server API can provision or inspect the Callaba side after the manual workflow has been accepted. Keep API automation secondary to a clear operator runbook: an automated listener with the wrong identity or firewall rule fails faster, not better. Use the LiveU workflow hub to compare Solo, Solo Pro, Studio, and other LiveU paths.
Troubleshoot by handoff
The SRT destination type is missing
Check the LRT subscription, device eligibility, firmware, and account permissions in LiveU. This is an upstream entitlement or configuration issue, not a Callaba port problem.
The Solo is live, but Callaba sees no session
Confirm that LiveU’s SRT output—not only the LRT contribution—is active. Then check the Callaba host, UDP port, firewall, and whether the listener is running.
The SRT handshake is rejected
Compare Stream ID and passphrase exactly. Confirm that Callaba expects a publisher from this destination and that the selected encryption settings agree.
The session connects without usable video
Check the selected codec and the source arriving at LiveU. HEVC requires Solo Pro in LiveU’s documented flow. Validate a decoded Multiview or recording rather than relying on the socket state.
The picture breaks up on a mobile path
Separate the LRT leg from the SRT leg. Review LiveU’s unit and bonding telemetry first, then Callaba’s current SRT context. Do not assume all loss was introduced between LiveU cloud and Callaba.
Callaba receives video, but an output fails
Preserve the healthy contribution and troubleshoot the specific recording, restreaming, routing, or playback branch. Rebuilding the Solo destination can turn one downstream fault into a full outage.
Official product references
Field names and prerequisites were checked against LiveU’s official support pages: How can I set up an SRT destination? and Is SRT supported on LiveU Solo?. Recheck those pages and the installed device state before a production because service options and portal interfaces can change.
Receive the LiveU SRT output in one visible place
Create a controlled Callaba Listener, send the LiveU cloud output to it, and prove both the contribution and the decoded media before adding production branches.
Configure the Callaba SRT receiving workflow