{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/", "item": { "id": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/", "slug": "check-axis-syslog-before-trusting-a-complete-rtsp-stream-list", "url": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/" }, "title": "Check Axis syslog before trusting a complete RTSP stream list", "summary": "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.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-29T00:10:24+00:00", "modified_at": "2026-10-29T00:10:34+00:00", "reviewed_on": "2026-10-28", "reading_minutes": 3, "word_count": 512, "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.", "primary_source": { "name": "Axis Communications — Stream status API", "url": "https://developer.axis.com/vapix/network-video/stream-status-api/", "published_on": null, "authority": "Axis Communications" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Bottom line: A successful stream-list request is a diagnostic input, not proof that every expected media session appears in the response.

\n

Source fact: documented behavior

\n

The Stream status API documentation limits this API to RTSP streams.

\n

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.

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

The following steps are DSE recommendations based on the cited source.

\n

DSE recommends reconciling the returned stream list against an explicit expected-consumer list and the device’s error evidence.

\n
    \n
  1. 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.
    2. \n
  2. 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.
    3. \n
  3. 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.
    4. \n
\n

Verification and evidence

\n

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.

\n

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.

\n

Official references

\n\n

Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.

\n", "content_text": "Bottom line: A successful stream-list request is a diagnostic input, not proof that every expected media session appears in the response.\nSource fact: documented behavior\nThe Stream status API documentation limits this API to RTSP streams.\nIf 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.\nWhat the source does not establish\nDo 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.\nApplicability questions\n\nWhich RTSP consumers are expected to be active during collection?\nAre any required media workflows outside the API’s stated protocol scope?\nCan the investigator preserve the relevant device syslog alongside the response?\nWhat independent record can confirm the suspected session or recording interval?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends reconciling the returned stream list against an explicit expected-consumer list and the device’s error evidence.\n\nPrepare 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.\nCollect 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.\nUse 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.\n\nVerification and evidence\nRetain 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.\nIn 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.\nOfficial references\n\nStream status API — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "content_markdown": "Bottom line: A successful stream-list request is a diagnostic input, not proof that every expected media session appears in the response.\n\n## Source fact: documented behavior\n\nThe [Stream status API](https://developer.axis.com/vapix/network-video/stream-status-api/) documentation limits this API to RTSP streams.\n\nIf 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.\n\n## What the source does not establish\n\nDo 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.\n\n## Applicability questions\n\n- Which RTSP consumers are expected to be active during collection?\n\n- Are any required media workflows outside the API’s stated protocol scope?\n\n- Can the investigator preserve the relevant device syslog alongside the response?\n\n- What independent record can confirm the suspected session or recording interval?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends reconciling the returned stream list against an explicit expected-consumer list and the device’s error evidence.\n\n- 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.\n\n- 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.\n\n- 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.\n\n## Verification and evidence\n\nRetain 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.\n\nIn 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.\n\n## Official references\n\n- [Stream status API](https://developer.axis.com/vapix/network-video/stream-status-api/) — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/", "url": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Check Axis syslog before trusting a complete RTSP stream list", "item": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/#article", "identifier": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/", "url": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/", "headline": "Check Axis syslog before trusting a complete RTSP stream list", "description": "The Axis Stream status API can omit a faulty stream record while returning HTTP 200.", "abstract": "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.", "articleBody": "Bottom line: A successful stream-list request is a diagnostic input, not proof that every expected media session appears in the response.\nSource fact: documented behavior\nThe Stream status API documentation limits this API to RTSP streams.\nIf 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.\nWhat the source does not establish\nDo 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.\nApplicability questions\n\nWhich RTSP consumers are expected to be active during collection?\nAre any required media workflows outside the API’s stated protocol scope?\nCan the investigator preserve the relevant device syslog alongside the response?\nWhat independent record can confirm the suspected session or recording interval?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends reconciling the returned stream list against an explicit expected-consumer list and the device’s error evidence.\n\nPrepare 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.\nCollect 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.\nUse 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.\n\nVerification and evidence\nRetain 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.\nIn 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.\nOfficial references\n\nStream status API — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "datePublished": "2026-10-29T00:10:24+00:00", "dateModified": "2026-10-29T00:10:34+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-axis-syslog-before-trusting-a-complete-rtsp-stream-list/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check Axis syslog before trusting a complete RTSP stream list" }, "articleSection": [ "Networks & Infrastructure", "Video Surveillance" ], "keywords": [ "Networks & Infrastructure", "Video Surveillance", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "Thing", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "wordCount": 512, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Axis Communications — Stream status API", "url": "https://developer.axis.com/vapix/network-video/stream-status-api/" } } ] } }