Haivision StreamHub SRT setup with Callaba Gateway
More live video workflow notes and product updates.
Haivision StreamHub integration
Hand a selected StreamHub source to Callaba as an SRT output
Haivision StreamHub can receive and manage contribution feeds, then expose a selected source through an IP output profile. Callaba can receive that SRT output and give another team a browser-visible operating surface for Multiview, recording, routing, or delivery. The useful design begins by assigning responsibility for each job rather than configuring the same function twice.
The direct architecture
Select the intended source in StreamHub, create an SRT IP output profile, and assign the source to that output. In the common cloud handoff, StreamHub originates an SRT Caller session and Callaba runs the receiving Listener. StreamHub remains responsible for the upstream contribution and source selection; Callaba becomes responsible for the received SRT session and the downstream workflows explicitly created there.
Haivision’s current StreamHub documentation also describes SRT Listener output operation. Choose the connection mode from the actual firewall and routing design. Available controls can vary with the installed StreamHub release and enabled capabilities, so verify them on the production system instead of assuming a version or license requirement.
The diagram shows an operational handoff, not protocol conversion timing or measured latency. Motion is disabled when the visitor requests reduced motion.
Assign responsibility before configuring duplicate functions
A duplicated feature is not automatically redundant. If StreamHub and Callaba both record the same source, the two files can provide useful evidence only when their storage, start conditions, retention, and failure domains are documented. If both platforms expose monitoring, operators need to know which screen is authoritative for the upstream contribution and which proves the downstream handoff.
| Operational question | StreamHub evidence | Callaba evidence |
|---|---|---|
| Did the field source reach the receiver? | Source state and media available inside StreamHub. | Not authoritative until StreamHub sends the output. |
| Was the correct source assigned? | Input-to-IP-output assignment. | Identity and decoded picture of the arriving SRT session. |
| Is the SRT handoff alive? | IP output session state. | Incoming session, bitrate, and live transport context. |
| Can the downstream operator see it? | Optional StreamHub monitoring. | A configured Multiview tile or other explicit media proof. |
| Which recording is the deliverable? | Any recording created and retained in StreamHub. | Any separately configured recording of the received copy. |
| Who routes the output onward? | The team responsible for upstream selection and StreamHub outputs. | The team responsible for Callaba restreaming, player, recording, or SRT routing branches. |
Prepare the Callaba receiving side
- Create one SRT Server for the StreamHub handoff. In the Caller-to-Listener design, configure Callaba as Listener and start it before StreamHub originates the output.
- Choose the reachable host and UDP port, then apply the cloud security group, host firewall, and upstream policy required for that specific path. Opening TCP on the same port does not open SRT.
- Define a publisher identity that makes the source recognizable to the downstream operator. If the StreamHub profile supplies a Stream ID, approve the same value in Callaba. Keep event secrets and customer data out of human-readable IDs.
- Match the encryption policy on both ends when encryption is enabled. Store the passphrase outside public screenshots and rotate it according to the production’s access policy.
The current dashboard steps live in the SRT Server user guide. This integration page stays focused on the StreamHub handoff so a future interface change does not invalidate the architecture.
Create the StreamHub IP output deliberately
Use Haivision’s IP output profile workflow that matches the installed StreamHub release. Create or edit the profile, select SRT as the transport, and choose Caller or Listener according to the network contract. For the recommended Caller flow, enter the Callaba host and listener port, plus the matching Stream ID and encryption values when used.
Then assign the intended StreamHub source to the profile. This assignment is a separate decision from creating the transport. Name the output so another operator can identify the source, destination, and production role without opening every field. Avoid a generic label such as “SRT output 1” when several events or feeds share the system.
Start only this handoff for the first test. If StreamHub also feeds a decoder, recorder, or partner at the same time, a successful output elsewhere can hide a failure on the Callaba branch.
Prove the output in three stages
First, prove the source inside StreamHub. The correct incoming contribution should be visible and audible before the IP output is blamed. Confirm that the selected source is the intended program, not a thumbnail, backup feed, or stale assignment.
Second, prove the SRT handoff. StreamHub should report the profile as active and Callaba should show the expected publisher with sustained incoming bitrate. Compare the same time interval on both platforms if the session reconnects or drops.
Third, prove decoded media downstream. Create one Callaba Multiview tile or a short recording. Check motion, audio, sync, and the expected program identity. An established SRT socket is necessary, but it does not prove that the correct source was assigned or that the media can be used.
Once those three proofs are stable, attach the production branches one at a time. The Callaba SRT Server API can automate repeatable receiving resources after the manual contract has been accepted.
Design recovery around the source boundary
If StreamHub switches from a primary field source to a backup while maintaining the same IP output, Callaba may see continuity at the transport boundary even though the upstream source changed. If StreamHub stops and restarts the output, Callaba sees a session event. Document which behavior the selected configuration produces and how downstream operators learn that the source changed.
If Callaba itself needs to choose between two StreamHub outputs, provide distinct identities and visible states. Do not call two profiles automatic failover until the switching rule, trigger, and result have been rehearsed. Keep common dependencies—StreamHub node, network interface, switch, power, and cloud route—in the failure diagram.
Troubleshoot without disturbing the working side
The source exists, but the output is idle
Check that the correct input is assigned to the intended IP output profile and that the profile has been started. A healthy input does not automatically activate every output.
StreamHub calls, but Callaba sees nothing
Compare the destination host and UDP port, confirm the Callaba listener is running, and inspect every firewall. Verify that the hostname resolves from the StreamHub network.
The handshake is rejected
Compare connection roles, Stream ID, encryption selection, and passphrase. Confirm that Callaba allows the expected publisher address or identity.
The wrong program arrives
Leave the SRT transport intact and inspect the source-to-output assignment in StreamHub. Callaba can accurately receive the wrong source if it was assigned upstream.
Callaba receives video without the expected audio
Check the source and audio mapping in StreamHub, then validate the encoded media selected for the IP output. Use an audible downstream proof rather than status indicators alone.
Multiview works, but an onward destination fails
The StreamHub handoff and basic decode have passed. Preserve them and troubleshoot only the recording, restreaming, routing, or player branch that failed.
Related resources and version check
Use the Haivision SRT workflow hub to compare products and contribution paths. The Callaba SRT Server overview explains the receiving, monitoring, routing, and deployment options available after the handoff. Recheck every StreamHub control against the manual for the installed release; the official StreamHub IP output profiles documentation describes the configuration used here.
Make the StreamHub handoff visible downstream
Receive one selected StreamHub source in Callaba, prove the SRT session and decoded media, then add only the Multiview, recording, routing, or delivery branches the production needs.
Explore the Callaba SRT receiving workflow