TVU MediaHub to Callaba: monitored SRT handoff workflows
More live video workflow notes and product updates.
Cloud-router handoff decision hub
TVU MediaHub is a cloud routing and conversion service rather than a camera or field encoder. The meaningful Callaba integration is therefore a boundary between two operational systems: MediaHub selects, processes and emits a feed; Callaba receives that chosen output for independent proof, recording, routing or recovery.
Written by Iurii Pakholkov, founder of Callaba. Materially reviewed on July 17, 2026 against the official sources listed below.
Choose the correct monitored SRT handoff workflows
| Path | Operational role | When to choose it |
|---|---|---|
| Production handoff | A selected MediaHub program output becomes a monitored Callaba input. | Use when a cloud production feed needs an independently operated delivery boundary. |
| Partner delivery | MediaHub creates the agreed SRT output; Callaba verifies and routes it to the next partner. | Document which organization owns each endpoint and escalation path. |
| Recovery and archive | Callaba records or prepares an alternate downstream route after receiving MediaHub. | Do not imply that this replaces MediaHub redundancy; it is a separate operational layer. |
Keep the source, handoff and Callaba roles explicit
Source-side responsibility
TVU MediaHub owns source aggregation, cloud signal routing, supported transformations and the selected SRT output.
Transport handoff
The handoff is a named program feed with an agreed codec, format, SRT mode, encryption, ownership window and failure escalation path.
Callaba responsibility
Callaba owns independent arrival proof, transport monitoring, recording, playback, protocol routing and receiver-side recovery actions.
Design a MediaHub-to-Callaba operational handoff
- 1. Name the exact MediaHub input and output that represent the program path. Avoid labels such as source one that become ambiguous during a live incident.
- 2. Confirm the formats and SRT options available in the active TVU account. Product matrices describe capability, while entitlements and service configuration determine the visible controls.
- 3. Create the matching Callaba endpoint and agree who owns caller/listener reachability, credential rotation and the start/stop window.
- 4. Verify preview and transport health at both systems, then interrupt the upstream path deliberately to observe alerts, route state and recovery responsibilities.
- 5. Test recording and the required partner output separately. A successful MediaHub preview does not prove that the Callaba archive or final destination is healthy.
After preflight, use the SRT Gateway hub for architecture choices, the SRT Server guide for receiver concepts, Multiview for browser operations, and the SRT API documentation for automation. These shared resources do not replace the model-specific guide linked in the decision table.
Official references reviewed
Capabilities and menu fields can change with hardware revisions, firmware and account entitlements. Recheck the exact model before a production event.
- TVU MediaHub product page — Official cloud routing, preview, recording and redundancy positioning.
- TVU MediaHub datasheet — Official input/output protocol matrix including SRT.
- TVU product user guides — Current MediaHub quick-start and operational references.
Frequently asked questions
How does TVU MediaHub hand off an SRT feed to Callaba?
Select the required program or input in MediaHub, create an SRT output with the agreed codec and role, and point it at the matching Callaba receiver. Then verify the feed independently in both systems.
Is Callaba the source or destination?
In this hub Callaba is the destination for a MediaHub output. Callaba can create later routes, recordings and playback outputs, but that does not change ownership of the original MediaHub handoff.
Which side should use caller and listener mode?
Use the combination exposed by the MediaHub output and allowed by the network. The caller initiates to the listener. Record the decision explicitly because changing it reverses reachability and firewall responsibilities.
Can Callaba monitor and record the output at the same time?
Yes, the received input can feed monitoring and recording workflows in parallel, subject to the deployed Callaba configuration and resources. Validate the recording artifact rather than relying only on live preview.
When should this feed become a recovery path?
Use it as a recovery path only when operators have a defined trigger, a tested alternate destination and clear ownership. Merely creating a second output does not create automatic failover.
Move from device choice to a tested receiving path
Open the exact-model guide, validate one contribution feed in Callaba, then add recording, monitoring and downstream routes only after the ingest contract is stable.
