Haivision Makito X4 SRT setup with Callaba Gateway, multiview, recording and playback

Choose the SRT mode from the network boundary

Haivision’s Makito X4 documentation supports Caller, Listener, and Rendezvous operation. Those modes describe how the endpoints establish the connection; they do not change which direction the encoded media travels. For a Makito encoder sending video to Callaba, the media still moves from Makito to Callaba even if a different connection mode is selected.

Caller-to-Listener is the clearest baseline because the public listening surface stays on the receiving infrastructure rather than the field appliance. It is not inherently secure by itself. Restrict the listener, use a defined publisher identity, and match the encryption policy.

Use the Makito features that make this integration specific

The Makito X4 is more than a generic SRT sender. Haivision documents Stream Publishing ID for access control and routing context, encryption options including authenticated encryption in supported configurations, live SRT link statistics, and path-redundancy capabilities. These features should be part of the design rather than buried below generic steps.

Stream Publishing ID gives the receiver a stable identity for the contribution. Decide its format before deployment—for example, by event and source role—and approve the exact value in Callaba. Do not use credentials or personally identifying details in a visible identifier.

Encryption protects the media session when both endpoints use compatible settings and the same secret. Available algorithms and authenticated modes can depend on installed firmware and configuration. Verify the exact option on the production Makito and the receiving contract; do not copy a label from a newer manual into an older appliance.

Path redundancy is useful only when paths are actually independent. Two sessions that share the same camera, encoder, switch, power source, ISP, or cloud rule still contain common failure points. Haivision documents active-active and active-backup concepts in its SRT feature set; the show design must still define what Callaba receives and who or what selects the program source.

Build and prove the direct Caller workflow

1. Record the exact product state. Note Makito X4 Encoder model, installed firmware, enabled licenses, input type, and the Haivision manual used for the build. Interface labels and supported security options can differ across releases.
2. Prove the baseband source. Confirm input lock, intended audio, raster and frame rate before creating the transport. Choose AVC/H.264 or HEVC according to the complete downstream chain rather than encoder capability alone.
3. Prepare Callaba. Create and start an SRT Listener, select a reachable host and UDP port, and apply firewall restrictions. The current interface procedure belongs to the Callaba SRT Server user guide.
4. Define identity and encryption. Enter the agreed Stream Publishing ID and matching passphrase/security settings on both ends. Keep secrets out of tickets, screenshots, and public production documents.
5. Configure the Makito output. Select SRT Caller and enter the Callaba listener destination. Preserve the approved media profile while validating transport; changing codec, role, identity, and latency together produces an ambiguous failure.
6. Start and observe both ends. Confirm the Makito reports an established SRT session and Callaba shows the expected publisher with a sustained incoming bitrate.
7. Prove decoded media. Add one Multiview tile or make a short Callaba recording. Inspect motion, audio selection, sync, and the expected codec. A connected socket alone is not an acceptance test.

Read both sides of the link

Makito’s SRT statistics describe the sender and transport from the appliance’s perspective. Callaba’s live SRT context describes the receiving session. Compare the same time window when investigating a fault. If Makito reports source continuity while Callaba loses the session, focus on the network and receiver boundary. If both report a healthy session but the Multiview picture is wrong, investigate media configuration or the selected downstream branch.

Do not rely on universal “good” RTT, loss, or latency numbers. An acceptable value depends on distance, jitter, recovery policy, encoder delay, and the production’s end-to-end budget. Establish a baseline on the real route, then alert on meaningful deviation from that tested envelope.

Plan redundancy as an operating procedure

Begin with one proven path. Then add the alternate path with a separate identity and a receiver state the operator can distinguish at a glance. Interrupt each path during rehearsal. Confirm what happens to the SRT session, the decoded media, the recording, and each downstream output. If recovery requires an operator action, document the action and the condition that triggers it. If another system makes the decision, identify that system instead of calling the design “automatic” without evidence.

Troubleshoot the failing layer

Related procedures and verification

Use the Haivision SRT workflow hub to compare models and architectures. Review the Callaba SRT Server page for receiving-product capabilities. Teams that need repeatable provisioning can use the SRT Server API documentation after the operator workflow is stable.

Recheck Haivision product facts and SRT options against the manual that matches the installed device. The official Makito X4 Encoder SRT configuration documentation describes the connection modes and controls used here.