AJA BRIDGE LIVE SRT setup: send SRT to Callaba Gateway
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.
BRIDGE LIVE sends one SRT contribution feed into Callaba Gateway. After ingest, Callaba can preview, record, route, restream, and feed multiview in parallel rather than as mandatory sequential setup steps.
- AJA BRIDGE LIVESRT Caller at venue
- Callaba GatewaySRT Listener in cloud
- Preview
- Record
- Route
- Restream
- Multiview
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.
Recommended workflow
Create an SRT Listener in Callaba first, then configure BRIDGE LIVE to call that listener. Use a fixed UDP port, a Stream ID if your routing policy needs it, and a passphrase when encryption is required. Keep the Stream ID and passphrase exactly identical on both sides; capitalization, trailing spaces, and copied newlines can break the SRT handshake.
Use H.264 for the first test unless the downstream decoder and player path are known to support HEVC. Practical first-test rates are 4-6 Mb/s for 1080p30 and 6-8 Mb/s for 1080p60, adjusted to the uplink. If BRIDGE LIVE exposes GOP or keyframe controls in the chosen encode profile, a 2-second keyframe interval is a reasonable first test for monitoring and restreaming.
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
| Where | What to do / field to fill | First-test value | Why / check |
|---|---|---|---|
| Callaba SRT server | Create the server and choose the UDP listen port | Use a fixed open UDP port | BRIDGE LIVE Caller needs a reachable Listener. |
| Callaba SRT server | Stream ID | Use a short exact value, or leave blank only if your routing allows it | Match BRIDGE LIVE exactly; it is case-sensitive and whitespace-sensitive. |
| Callaba SRT server | Passphrase / encryption | Use the agreed passphrase when encryption is required | Match BRIDGE LIVE exactly; avoid copied spaces or newlines. |
| BRIDGE LIVE SRT output | SRT mode | Caller | AJA documents Caller and Listener. Caller is normally simpler from a venue network. |
| BRIDGE LIVE SRT output | SRT destination URL, host, and port | srt://your-callaba-host:port | Use the public Callaba address and the same UDP port. |
| BRIDGE LIVE SRT output | Stream ID field | Same value as Callaba | A mismatch can look like a network failure. |
| BRIDGE LIVE SRT output | Passphrase field | Same value as Callaba | AJA documents passphrase support for encrypted SRT. |
| BRIDGE LIVE encode/transcode profile | Video codec and bitrate | H.264, 1080p30 at 4-6 Mb/s | Use 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.
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
| Symptom | Check in Callaba | Check on BRIDGE LIVE | Likely fix |
|---|---|---|---|
| No connection | Server is running, UDP port is open, no firewall block | SRT mode is Caller and destination host/port are correct | Fix DNS/IP, port, or firewall. Avoid Listener mode at the venue unless inbound UDP is tested. |
| Connects then drops | RTT, packet loss, retransmits, uptime | Uplink capacity and encoder bitrate | Raise SRT latency, reduce bitrate, or fix packet loss. |
| Handshake fails with correct network | Stream ID and passphrase values | Same fields, including capitalization and no trailing spaces | Paste values into a plain-text editor first, then re-enter them on both sides. |
| Video but no audio | Audio meters and stream analysis | Audio mapping and codec in the encode profile | Map the correct embedded SDI audio channels and use a supported audio format. |
| NDI workflow missing | Whether Callaba receives an SRT/RTMP/NDI bridge feed | Installed NDI license and software version | Confirm the optional NDI license or use direct SRT/RTMP output instead. |
| Hard-to-diagnose SRT errors | Callaba build/support information | BRIDGE LIVE software version and AJA release notes, including SRT library notes | Confirm compatible SRT versions and update according to AJA guidance. |
Official references
Useful references for planning this exact workflow:
Vendor references
- AJA BRIDGE LIVE product page and technical specifications
- AJA BRIDGE LIVE manual v1.16r2
- AJA BRIDGE LIVE RTMP/RTMPS support FAQ
- AJA BRIDGE LIVE v1.16 release notes
- AJA BRIDGE LIVE Family v1.18.2 release notes
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.
