Callaba

Kiloview SRT Gateway Workflows with Callaba

Jun 30, 2026

Kiloview role map

Start with the hardware job, then choose the exact Kiloview guide

Kiloview’s catalogue spans field encoders, compact fixed encoders, NDI/SRT bridges, bidirectional endpoints, decoders and rack receivers. Those products do not become interchangeable because they all touch IP video. Input connector, encode or decode direction, channel density, firmware and any network service change the correct workflow.

This page is a selector. The linked model guide owns device fields; Callaba owns the SRT endpoint and the downstream monitoring, recording and routing you explicitly create.

Field
portable contribution
Fixed
local source encode
Bridge
NDI and SRT boundary
Receive
decode or rack output

Find the model family by production role

Portable and bonded contribution

P1, P2, P3 and P3 Mini belong in field workflows where battery, interfaces and changing networks are part of the design. Treat Kilolink bonding as a separate service and verify its handoff.

Compact source encoding

E1/E2 and E3 turn a local video source into an IP contribution feed. The physical input and installed unit decide the guide; do not infer one model’s ceiling from another.

N-series IP endpoints

The N family includes HDMI/USB or HDMI NDI/SRT bridges and different encode, decode or bidirectional roles. N50 adds a 12G-SDI context; N60 belongs to a 4K HDMI path. Confirm the suffix.

Decode and rack receiving

D260, RE-2 and RE-3 belong on the receive side. Output mapping, simultaneous channels and management software are part of acceptance, not an afterthought.

Separate three kinds of resilience

Marketing language often collapses bonding, packet recovery and failover into one promise. They act at different layers and fail in different ways:

Application failoverCallaba or another system chooses between distinct primary and backup sources according to an explicit rule.
SRT recoveryThe transport retransmits recoverable packet loss inside the configured latency window.
Vendor bonding serviceMultiple network links may be combined before a handoff; termination and subscription must be documented.
Physical connectivityModems, Ethernet, Wi-Fi, power and the event network remain real dependencies.

For P-series workflows, record where the bonding service terminates and what protocol reaches Callaba. Do not call a second connection automatic failover until its switching trigger and output have been rehearsed.

Write the handoff ledger before configuration

Kiloview owns

Source lock, encode/decode role, local profile, enabled network service and the output the exact device exposes.

The network owns

Reachability, Caller or Listener choice, UDP path, measured loss, latency budget and any service boundary.

Callaba owns

The configured SRT session, access rules, receiver evidence, Multiview, recording and downstream routes.

This ledger prevents a Callaba operator from troubleshooting a vendor bonding failure as if it were an SRT port, and prevents a field operator from declaring success before the feed decodes downstream.

Accept one observable path before adding outputs

  1. Identify: photograph or record the exact hardware suffix, firmware and enabled service plan.
  2. Feed: connect the real source or destination and prove video plus every required audio channel locally.
  3. Contract: choose peers from actual network reachability and agree address, port, mode, Stream ID, passphrase and latency.
  4. Observe: confirm the intended publisher, sustained bitrate, decoded motion and audio in Callaba.
  5. Prove: make a short recording, place the source in Multiview and exercise the final destination.
  6. Interrupt: remove one network path, stop the device output and stop the downstream route separately; record each result.

Troubleshoot by boundary, not by brand

If the device lacks input lock or encode bitrate, fix the source-side configuration. If it produces media but Callaba never sees a session, compare peer mode, destination, UDP reachability, Stream ID and security. If Callaba sees transport but not usable media, inspect codec and audio compatibility. If Multiview works but a recording or restream does not, preserve the accepted input and diagnose only that downstream branch.

For a decoder or rack receiver, reverse the evidence: prove the Callaba output first, then session arrival on the Kiloview side, then the mapped physical output.

Recheck the exact Kiloview model

Use Kiloview’s SRT user manual, current portable bonding encoder overview, and RE-3 product page as starting points. Then open the manual for the precise unit and firmware; a family page is not evidence of identical connectors, channel limits or controls.

Typical live workflow

Kiloview contribution through Callaba SRT Gateway

A compatible Kiloview source sends a live SRT contribution feed to Callaba, where operators can monitor the connection and route the stream to configured destinations.

Contribution source

  • Kiloview hardware or source

    A compatible camera, encoder, or field unit sends the live contribution feed.

    SRT source
Callaba SRT Gateway

Receives the SRT feed and provides routing and operational visibility.

Ingest and control

Monitoring and delivery

  • Stream monitoring

    Operators inspect the incoming stream and connection status.

  • Configured delivery

    Callaba routes the feed to the selected production or distribution destination.

Exact SRT modes, stream settings, and available outputs depend on the source device and the configured destination.

Choose where to run Callaba SRT Gateway

Continue with an AWS deployment or review the self-hosted path for your infrastructure.