Choose a Canon model for your SRT Gateway workflow
More live video workflow notes and product updates.
Canon firmware gate
The SRT workflow begins with proof from the installed Canon camera
Canon added SRT at different points across its remote-camera and camcorder range. The CR-N500 firmware notice is a clear example: version 1.2.0 added SRT support. A model name on a purchase order therefore does not prove that a unit in the room exposes the same controls as today’s support page.
Pass the model, region and firmware gate first. Then use Callaba to receive the documented output, inspect transport and decoded media, record evidence and route the accepted feed.
Select the Canon branch by installation and operator
CR-N500
Use for a professional indoor PTZ position where its one-inch sensor and production I/O fit the room. Confirm current firmware rather than assuming an older maintained unit has SRT.
Open the CR-N500 guideCR-N100
Use for a compact indoor PTZ workflow. Check the current IP profile, frame-frequency choice and controls visible on the installed firmware.
Open the CR-N100 guideCR-X300
Use where an outdoor-rated remote camera is required. Weather protection does not solve uplink, power, firewall or recovery; test those boundaries at the site.
Open the CR-X300 guideXF605
Use for operator-led field acquisition. Preserve local recording, power and full audio checks even when the live contribution is the primary deliverable.
Open the XF605 guideStop at the gate when the SRT menu is missing
Do not respond by opening more ports or copying a field from another Canon model. Compare the full model and regional support page, inspect the installed firmware, and read the release note that introduced or changed the feature. Update only through a planned maintenance process with a rollback and retest window.
Write one camera-to-Callaba contract
Model, suffix, firmware, source name and operator.
Codec, raster, frame rate, bitrate and complete audio map.
Caller or Listener, host, UDP port, Stream ID, latency and passphrase policy.
For many camera-to-cloud paths, the camera as Caller toward a Callaba Listener is a sensible first test because it initiates outbound UDP. Use Listener at the camera only when the server can deliberately reach that address and the model documents the role. Keep remote camera control, tally and metadata on a separately tested path.
Run a receiver-side acceptance test
- Capture the model and firmware screen without exposing credentials. Confirm that the intended SRT controls match the model guide.
- Prove the local picture, camera movement, presets, embedded audio and any local recording before enabling network output.
- Create the matching Callaba endpoint and open only the required UDP path. Align role, port, Stream ID, encryption and latency.
- Operate representative movement while checking incoming bitrate, RTT, packet loss, decoded motion, audio and sync in Callaba.
- Make and play back a Callaba recording. Then interrupt the uplink and measure reconnect before adding routing or automatic failover.
Turn accepted feeds into an operator workflow
Once the camera has passed, Callaba can place multiple Canon sources in browser Multiview, retain receiver-side evidence, record selected programs and route them onward. Use AWS when a public endpoint near the production region is needed; use self-hosted Callaba when the receive boundary belongs inside controlled Linux infrastructure.
The Callaba workflow should follow the camera decision, not replace it. The model guides own device-specific fields, while the Callaba SRT Server page explains the monitored receiving, routing and recording environment.
Official Canon references
Review Canon’s CR-N500 firmware 1.2.0 notice, current CR-N500 support page, CR-N100 support page, CR-X300 product material, and XF605 support page. Confirm the regional model and latest reviewed manual before airtime.
