# Check Axis syslog before trusting a complete RTSP stream list > The Axis Stream status API can omit a faulty stream record while returning HTTP 200. Check its RTSP-only scope and syslog evidence before treating the list as complete. - Canonical URL: https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:10:24+00:00 - Modified: 2026-10-29T00:10:34+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know The Axis Stream status API can omit a faulty stream record while returning HTTP 200. Check its RTSP-only scope and syslog evidence before treating the list as complete. ## Potentially affected Axis devices exposing the documented Stream status API interface; confirm support and the installed API/software scope before applying the proposed checks. ## DSE recommendation DSE recommends reconciling the returned stream list against an explicit expected-consumer list and the device’s error evidence. ## Article Bottom line: A successful stream-list request is a diagnostic input, not proof that every expected media session appears in the response. ## Source fact: documented behavior The [Stream status API](https://developer.axis.com/vapix/network-video/stream-status-api/) documentation limits this API to RTSP streams. If a stream’s information is faulty, the documented behavior excludes that stream from the CGI’s 200 OK response and writes an error to syslog. ## What the source does not establish Do not turn an absent list entry into proof that a client disconnected or that recording stopped. Keep the API’s protocol scope visible when reconciling sessions. Obtain independent recorder or client evidence for the recording question, and require device-specific support before using a diagnostic interface. Avoid treating a transport success code as the only acceptance criterion. ## Applicability questions - Which RTSP consumers are expected to be active during collection? - Are any required media workflows outside the API’s stated protocol scope? - Can the investigator preserve the relevant device syslog alongside the response? - What independent record can confirm the suspected session or recording interval? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends reconciling the returned stream list against an explicit expected-consumer list and the device’s error evidence. - Prepare a proposed diagnostic case with one known authorized RTSP client and a clear collection interval. Record the intended device, client and stream identity without saving credentials. Have the client owner confirm whether the session should be running during that interval. Do not begin with the assumption that an empty or short response describes every possible media path. - Collect the stream-status response and relevant device log information together. Compare expected entries with returned entries, and preserve the HTTP status separately from the list contents. If an entry is missing, investigate the documented error path before concluding that the client has gone away. Record unavailable log evidence as a gap rather than filling it with an assumed reason. - Use the recorder or client’s supported evidence to answer the operational question. For a missing-recording complaint, retrieve the relevant recording interval through the normal authorized workflow. Keep that observation separate from the device-side list result. Escalate disagreement to the appropriate integration owner with both records, instead of restarting multiple components simply to make the lists line up. ## Verification and evidence Retain the expected-consumer worksheet, sanitized API response, device and client software identity, collection times and relevant syslog entries. Preserve the basis for each conclusion: returned entry, separate client observation, retrieved recording or unresolved gap. Use an agreed clock context when comparing the records. In the proposed acceptance exercise, include both a matching session and a reconciliation gap that requires further evidence. Do not manufacture a malformed production stream to force an error. Have another reviewer follow the missing-entry decision path and confirm that HTTP success alone cannot close the investigation. No session, recording failure or device log was observed for this article. ## Official references - [Stream status API](https://developer.axis.com/vapix/network-video/stream-status-api/) — Axis Communications; official VAPIX documentation. Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings. ## Primary reference - Name: Axis Communications — Stream status API - Authority: Axis Communications - URL: https://developer.axis.com/vapix/network-video/stream-status-api/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check Axis syslog before trusting a complete RTSP stream list,” DSE Security, https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.