media server logo

AJA BRIDGE LIVE SRT setup: send SRT to Callaba Gateway

Jun 01, 2026
Iurii Pakholkov

Written by Iurii Pakholkov

Founder of Callaba. Building cloud video tools for SRT, RTMP, WebRTC, NDI, live routing, monitoring, recording, and production workflows.

Release: Callaba 8.4

AJA BRIDGE LIVE SRT setup is usually a direct contribution workflow: keep BRIDGE LIVE at the venue as the encoder, set it as the SRT Caller, and send the feed to a cloud SRT Listener. Use this setup when BRIDGE LIVE is at the venue and Callaba is the cloud SRT receiver for monitoring, recording, routing, multiview, or restreaming. Before the event, confirm the installed BRIDGE LIVE software exposes the expected SRT fields.

Quick answer

To use AJA BRIDGE LIVE with SRT, set BRIDGE LIVE as the SRT Caller and send the stream to a cloud SRT Listener. In this guide, Callaba works as the SRT gateway, receiver, monitor, recorder, and routing layer.

What this setup does

This workflow turns BRIDGE LIVE into the venue-side contribution encoder and Callaba into the cloud SRT receiver. BRIDGE LIVE encodes or transcodes the SDI or supported IP source, sends MPEG-TS over SRT to Callaba, and Callaba then makes the received feed available for live preview, recording, routing, restreaming, multiview, or playback outputs.

For most internet contribution jobs, make BRIDGE LIVE the SRT Caller. That keeps the inbound firewall complexity on the cloud side. BRIDGE LIVE Listener mode is documented too, but using it over the public internet usually means the venue side must accept inbound UDP with a public IP, port forwarding, and tested firewall rules.

What this model can and cannot do in this workflow

  • AJA documents BRIDGE LIVE as a bidirectional encode, decode, and transcode system, so it can be used for venue contribution and for SRT return-feed decoding to SDI when the job requires that direction.
  • The BRIDGE LIVE 12G-4 configuration is positioned for bidirectional 12G-SDI I/O up to four UHD channels; the 3G-8 configuration is positioned for bidirectional 3G-SDI I/O up to eight HD channels.
  • AJA lists dual 10 GigE network ports for IP stream workflows.
  • SRT is confirmed for this model, including encryption support in the protocol list. AJA API documentation also lists SRT mode values for Caller and Listener, Stream ID, and passphrase.
  • RTMP is documented for input and output. AJA states RTMPS is output only, so do not plan RTMPS ingest into BRIDGE LIVE unless the installed documentation says otherwise.
  • H.265/HEVC, H.264/AVC, and H.262/MPEG-2 video codecs are listed for BRIDGE LIVE. JPEG 2000 and JPEG XS are optional licensed workflows.
  • NDI is available when the optional license is present. Public AJA sources are not perfectly aligned on whether NDI is included or optional, so confirm the installed license, software version, and visible NDI settings before building the show around NDI.
  • RTSP is not listed in the current BRIDGE LIVE protocol list I would use for planning. Do not sell this job as a BRIDGE LIVE RTSP workflow unless your installed software clearly exposes RTSP settings.
  • SRT Rendezvous was not confirmed in the BRIDGE LIVE sources used here. Plan Caller or Listener mode unless AJA support or the installed UI confirms otherwise.
  • Do not confuse BRIDGE LIVE with BRIDGE LIVE IP. BRIDGE LIVE IP is the separate model for SMPTE ST 2110 environments; this page is for BRIDGE LIVE.

When not to use this setup

If BRIDGE LIVE and the production switcher are in the same rack, local SDI may be simpler than sending the program to the cloud and back. If the only target is one public platform and you do not need cloud monitoring, routing, multiview, or recording, RTMP or RTMPS output may be enough.

Use NDI only when the BRIDGE LIVE unit has the NDI license and the LAN is engineered for it. Use an RTSP bridge only if a separate, confirmed RTSP source is involved or your installed BRIDGE LIVE software actually exposes RTSP controls. For SMPTE ST 2110 I/O, use the BRIDGE LIVE IP product family rather than assuming this BRIDGE LIVE workflow covers it.

Before you start

  • Check the installed BRIDGE LIVE software version and confirm the SRT output settings are visible.
  • Confirm whether the job needs Caller or Listener mode. Caller from the venue to Callaba is the simpler internet path.
  • Choose the UDP port and open it on the Callaba side.
  • Decide whether Stream ID is required for routing or access control.
  • Prepare the passphrase if encrypted SRT is required. AJA documentation lists passphrase support for encrypted SRT connections.
  • If you plan SRT bonding redundancy, confirm the BRIDGE LIVE version and maintenance entitlement because AJA ties some newer v1.16 features to an active Annual Maintenance Option.

Create the Callaba ingest

In Callaba, create an SRT server, set it to listen on the chosen UDP port, and copy the public host, port, Stream ID, and passphrase values you want BRIDGE LIVE to use. Start with 250-500 ms SRT latency for an internet test unless your production standard requires another value. After the first lock, tune latency only after RTT, packet loss, and retransmits are stable.

Configure BRIDGE LIVE

In the BRIDGE LIVE stream or output configuration, create an SRT output from the correct SDI or supported IP source. Set the SRT mode to Caller, enter the Callaba host and UDP port, then enter the Stream ID and passphrase exactly as configured in Callaba. Select the encode profile, video codec, bitrate, frame rate, and audio mapping required by the production.

For a BRIDGE LIVE SRT receiver or return-feed job, reverse the direction: Callaba sends SRT output and BRIDGE LIVE receives and decodes to SDI. That is a different operational design, so test it separately from contribution ingest.

Settings table

WhereWhat to do / field to fillFirst-test valueWhy / check
Callaba SRT serverCreate the server and choose the UDP listen portUse a fixed open UDP portBRIDGE LIVE Caller needs a reachable Listener.
Callaba SRT serverStream IDUse a short exact value, or leave blank only if your routing allows itMatch BRIDGE LIVE exactly; it is case-sensitive and whitespace-sensitive.
Callaba SRT serverPassphrase / encryptionUse the agreed passphrase when encryption is requiredMatch BRIDGE LIVE exactly; avoid copied spaces or newlines.
BRIDGE LIVE SRT outputSRT modeCallerAJA documents Caller and Listener. Caller is normally simpler from a venue network.
BRIDGE LIVE SRT outputSRT destination URL, host, and portsrt://your-callaba-host:portUse the public Callaba address and the same UDP port.
BRIDGE LIVE SRT outputStream ID fieldSame value as CallabaA mismatch can look like a network failure.
BRIDGE LIVE SRT outputPassphrase fieldSame value as CallabaAJA documents passphrase support for encrypted SRT.
BRIDGE LIVE encode/transcode profileVideo codec and bitrateH.264, 1080p30 at 4-6 Mb/sUse HEVC only when the full monitoring and playback chain supports it.

Monitoring

In Callaba, confirm connection uptime, incoming bitrate, preview video, audio meters, RTT, packet loss, and retransmits. On BRIDGE LIVE, check that the output session is running and that the source format, audio mapping, and encoder profile match the program. A stable SRT connection with no usable preview usually points to codec, PID, audio mapping, or profile mismatch rather than the UDP path.

Failover and local ingest options

For production events, plan what happens if the main encoder, venue uplink, or primary contribution path fails. Callaba can be part of that continuity plan without changing the basic AJA BRIDGE LIVE ingest workflow.

Callaba multiview and failover interface
Preview, multiview and failover Use the demo to check how incoming feeds, multiview monitoring and backup switching look in Callaba before building the live workflow. Open multiview demo

Recording and playback

Once the incoming SRT feed is stable, recording and playback are downstream choices in Callaba. You can record the received contribution, create a player for browser review, route it to another destination, or restream it. These are parallel uses of the same ingested source; recording does not need to sit between preview and routing.

Troubleshooting

SymptomCheck in CallabaCheck on BRIDGE LIVELikely fix
No connectionServer is running, UDP port is open, no firewall blockSRT mode is Caller and destination host/port are correctFix DNS/IP, port, or firewall. Avoid Listener mode at the venue unless inbound UDP is tested.
Connects then dropsRTT, packet loss, retransmits, uptimeUplink capacity and encoder bitrateRaise SRT latency, reduce bitrate, or fix packet loss.
Handshake fails with correct networkStream ID and passphrase valuesSame fields, including capitalization and no trailing spacesPaste values into a plain-text editor first, then re-enter them on both sides.
Video but no audioAudio meters and stream analysisAudio mapping and codec in the encode profileMap the correct embedded SDI audio channels and use a supported audio format.
NDI workflow missingWhether Callaba receives an SRT/RTMP/NDI bridge feedInstalled NDI license and software versionConfirm the optional NDI license or use direct SRT/RTMP output instead.
Hard-to-diagnose SRT errorsCallaba build/support informationBRIDGE LIVE software version and AJA release notes, including SRT library notesConfirm compatible SRT versions and update according to AJA guidance.

Official references

Useful references for planning this exact workflow:

Vendor references

Protocol references

Callaba resources

FAQ

Can AJA BRIDGE LIVE send SRT directly to Callaba?

Yes. AJA documents SRT for BRIDGE LIVE, and the practical setup is BRIDGE LIVE as Caller to a Callaba SRT Listener.

Should BRIDGE LIVE be the SRT Caller or Listener?

Use Caller for the normal cloud workflow. Listener can work in controlled networks, but the venue side must accept inbound UDP with firewall and NAT rules.

Does BRIDGE LIVE support Stream ID and passphrase?

Yes. AJA documentation lists Stream ID and passphrase for SRT. Keep both values identical on both sides, including case and whitespace.

Can I use RTMP or RTMPS instead?

Yes, with limits. AJA documents RTMP input and output, while RTMPS is documented as output only. For Callaba ingest, RTMPS output can be a fallback when SRT is not the chosen path.

Is RTSP supported on BRIDGE LIVE?

I would not plan RTSP for this model from the current AJA protocol list. Use RTSP only if your installed BRIDGE LIVE software or an external source clearly provides it.

What if the SRT menu is missing on the unit?

Confirm the installed software version against AJA support resources before the event. If SRT settings are still absent, use a confirmed RTMP/RTMPS path or a deliberate bridge workflow rather than guessing hidden SRT support.

Next steps

Build the path in this order: confirm BRIDGE LIVE firmware and SRT fields, create the Callaba SRT Listener, enter the exact host, port, Stream ID, and passphrase on BRIDGE LIVE, then test with preview, audio meters, bitrate, RTT, packet loss, and recording before handing the feed to production.

Try Callaba Gateway with AJA BRIDGE LIVE SRT

Create an SRT server in Callaba, send the device feed to the gateway, and check the received stream. After ingest is stable, use Callaba outputs for preview, recording, restreaming, multiview, playback, routing, or API workflows as parallel downstream options.