Callaba
PricingSign inLaunch camera streaming
Camera operations guide

Build an RTSP camera path you can trust

Choose the right camera profile, keep credentials out of shared URLs and prove decoded video, audio, timestamps and reconnect behavior before rollout.

Start with one representative camera and one failure rehearsal.

Open the decision guide
Decision map workflow boundary
01 · SourceCamera profile

Main stream, substream, codec, frame rate and audio.

02 · NetworkProtected RTSP path

Credentials, firewall policy and transport are explicit.

03 · ControlRecord and monitor

Watch the decoded feed and verify recovery.

profilecredentialstimestampsreconnect

The camera is online. Now you need the exact RTSP feed that a recorder, gateway or production system can use without guesswork. Commission one camera all the way from discovery and decode through recovery and the final consuming job before copying its settings across the site.

Keep four boundaries visible

  1. Management and discovery: the camera's address, firmware, account, time source, and vendor or ONVIF configuration interface.
  2. Media profile: the selected video, audio, metadata, resolution, rate control, and frame cadence.
  3. RTSP/RTP session: the resource URI, authentication, presentation description, and TCP or UDP media path.
  4. Consuming job: preview, recording, restream, analysis, or browser bridge, each with its own codec and recovery requirements.

A camera may be healthy at the first two boundaries even when the UDP media path is blocked. It may also decode in a desktop player while the recorder rejects its audio format. Before changing the camera, identify the boundary that actually failed.

Discover the stream from the device contract

Begin with the current manual or API documentation for the installed firmware. Vendors define their own RTSP paths. One Axis VAPIX example uses rtsp://<servername>/axis-media/media.amp and lets a saved streamprofile select a defined set of parameters. That tells you something about Axis devices; it is not a universal camera URL.

If a device implements the relevant ONVIF Media Service, a client can enumerate its media profiles and request a stream URI for a chosen profile token. This is useful because the returned URI belongs to a configured profile. It does not guarantee that every downstream decoder will accept the profile's codecs, and an ONVIF label does not replace the vendor's firmware documentation.

Check the product's current ONVIF conformance instead of treating “ONVIF compatible” as a permanent, universal label. Profile S is being deprecated, with 31 March 2027 as the final date for new product-conformance submissions. Existing Profile S devices do not stop working on that date. For a new design, review the exact capabilities declared for the product and compare them with Profile T. Profile T can cover H.264/H.265 video, imaging settings, metadata and event features. Even so, the label does not prove that this particular codec, audio, metadata and receiver combination will pass the runbook.

Record these fields before testing

FieldEvidenceWhy it matters
Device identityModel, serial or asset ID, firmware, management addressPrevents a result from being generalized to a different hardware or firmware branch.
Profile identityVendor profile name or ONVIF profile tokenDistinguishes the main stream, substream, and any analytics or metadata profile.
Expected mediaVideo codec/profile, resolution, frame rate, bitrate mode, GOP; audio codec/rate/channelsDefines what the receiver must decode and what downstream jobs must preserve.
Session endpointHost, port if non-default, vendor path, required parametersSeparates a wrong resource from a network or credential failure.
Secret referenceVault or credential-manager identifierKeeps usernames and passwords out of tickets, screenshots, shell history, and analytics.

Build the URL without turning it into a leaked secret

A runbook can safely show a structural placeholder such as rtsp://camera.example.invalid/<vendor-path>. Keep the real credential in an approved secret store and, where possible, inject it through the receiving application. Do not publish a URL in the form rtsp://user:password@host/.... Even if the client accepts it, that string is likely to end up in history, logs, screenshots or process output.

Give the media consumer its own account instead of reusing the camera administrator. Check the authentication mode the device actually supports; RTSP endpoints do not all handle authentication the same way. Axis, for example, recommends Digest authentication for RTSP clients in its current guidance.

Camera-to-receiver validation runbook

  1. Stabilize identity and time. Update through the vendor-approved firmware process, assign the intended network identity and verify the device clock. Time errors make logs, certificates, recordings and correlation with other cameras harder to trust.
  2. Select one explicit profile. Start with the codec and resolution the consuming job requires, which may not be the highest setting. Confirm whether audio and metadata are enabled, then save the profile name or token.
  3. Retrieve the URI through a supported path. Use the vendor UI/API or the ONVIF Media Service where available. Sanitize the result before it goes into a ticket or runbook.
  4. Inspect the presentation locally. From an approved host on the camera network, verify that DESCRIBE returns the expected video and audio tracks. Use ffprobe or another supported inspector to capture the codec, dimensions, frame rate and audio details.
  5. Exercise both documented transports. FFmpeg tools support explicit -rtsp_transport udp and -rtsp_transport tcp modes. Test only the modes documented by the camera. Record which one works, the media ports where applicable, startup time and behavior under loss or congestion.
  6. Move the same profile to the real receiver. At the gateway or recorder, recheck decoded motion, audio, timestamps and source identity. A laptop-player result proves the camera profile, not the production receiver.
  7. Attach the consuming job. Create the required recording or output and inspect the artifact at its destination. Verify duration, seekability where required, audio, file segmentation or stream continuity and retention behavior.
  8. Run recovery and soak tests. Reboot the camera, interrupt the network, restart the receiver and rotate the service credential through the approved process. Run long enough to cover representative load, lighting-mode changes and the site's normal clock behavior.

Read the symptom before editing the profile

SymptomLikely boundaryNext evidence
Connection refused or timeoutAddress, route, firewall, RTSP service, or portReachability from the receiver and the camera service state
Authentication or resource errorAccount permissions, authentication mode, or vendor pathSanitized RTSP status, current vendor path, and account role
DESCRIBE succeeds; no UDP mediaNegotiated RTP ports, ACL, NAT, or asymmetric routeSETUP transport response and packet capture at both sides
TCP works; UDP does notNetwork policy, not automatically the codecAllowed port range, return path, and packet loss counters
Packets arrive; picture is black or rejectedTrack selection, codec/profile, parameter sets, decoderSDP plus inspector and decoder logs
Preview works; recording or restream failsDownstream jobDestination codec rules, timestamps, storage, and output logs
Failure appears after hoursClock drift, network contention, firmware, thermal or scheduled camera behaviorTime-correlated camera, network, receiver, and output logs

Remote access should not expose the camera

Axis's current hardening guide recommends limiting Internet exposure, isolating devices and related infrastructure on a segregated network, disabling unused services and keeping device time accurate. These are sound architecture checks for any camera estate. When the hardware comes from another vendor, use that vendor's hardening guide for the actual controls.

Prefer a private route, site-to-site VPN or an on-site gateway that pulls the camera locally instead of exposing the device directly. Restrict management more tightly than media consumption, allow only named receivers and identify the teams responsible for firmware, credentials, certificates, network policy and incident response. Being able to reach RTSP is not authorization to expose the camera UI.

Validate one camera recording in Callaba

After proving the exact camera profile, use Callaba's Recordings API to create one job with INPUT_TYPE_RTSP_URL and the verified input_stream_url. Keep the profile identity visible to operators. While the job is active, inspect POST /api/recording/getStat for bitrate, fps, out_time_ms, speed and progress. Stop the job, call POST /api/recording/getById and confirm that recordedFiles[] contains the expected file. The evidence applies only to that recording path and the camera profile you tested.

For site topology and retention responsibilities, continue with video surveillance streaming. For the protocol mechanics, return to RTSP. Camera purchasing is outside this page; use the camera selection guidance for that job.

References