{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/", "item": { "id": "https://update.dsesecurity.com/updates/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/", "slug": "verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames", "url": "https://update.dsesecurity.com/updates/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames.md", "json": "https://update.dsesecurity.com/api/v1/posts/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/" }, "title": "Verify Axis RTP timestamps before mapping metadata to video frames", "summary": "Check Axis Onvif Replay Extension capability, default configuration and per-stream selection separately before relying on RTP timestamps for frame-to-metadata mapping.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "video-evidence", "label": "Video evidence & analytics", "alt": "Multiple synchronized camera views converging into a verifiable evidence frame.", "card_url": "https://update.dsesecurity.com/assets/editorial/video-evidence-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/video-evidence-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/video-evidence-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "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-29T17:41:19+00:00", "modified_at": "2026-10-29T17:41:38+00:00", "reviewed_on": "2026-10-29", "reading_minutes": 3, "word_count": 550, "potentially_affected": "Axis products exposing the documented Onvif Replay Extension interface; confirm actual device, hardware and software applicability before applying the proposed checks.", "dse_recommendation": "DSE recommends accepting the extension on an observed stream before using it as an input to frame-to-metadata mapping.", "primary_source": { "name": "Axis Communications — Onvif Replay Extension", "url": "https://developer.axis.com/vapix/network-video/onvif-replay-extension/", "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: Inspect the actual RTP extension before relying on timestamps for a frame-to-metadata association. Separate support, default enablement and the requested stream option so a working picture does not become the only acceptance evidence.

\n

Source fact: documented behavior

\n

Axis’s Onvif Replay Extension describes an RTP header extension carrying an NTP timestamp for video or audio streams, including a use case that maps timestamped metadata objects to video frames.

\n

The documented support property is Properties.API.RTP.OnvifReplayExt, while Network.RTP.OnvifReplayExt controls default enablement.

\n

The stream examples use onvifreplayext=1 to enable the extension and onvifreplayext=0 to disable it, including when it was enabled by default.

\n

What the source does not establish

\n

Do not infer clock accuracy, end-to-end synchronization quality or correct metadata association solely from an enabled property. Confirm the stream consumer’s support and the actual packet evidence. Keep this extension check separate from RTSP session survival, transport protection and approval of the broader video-management integration.

\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 accepting the extension on an observed stream before using it as an input to frame-to-metadata mapping.

\n
    \n
  1. Read the capability and default-setting properties through the documented workflow. Preserve both values with the camera/software identity. Capture the consumer’s sanitized stream request and identify whether it sets the extension option or relies on the default. Do not copy the documentation’s embedded example credentials into the test configuration; use the approved authentication and transport arrangement for the environment.
    2. \n
  2. In an authorized isolated test, collect a bounded packet sample for the intended stream and inspect it for the RTP header extension. Prepare comparison cases with the documented enable and disable options where supported. Keep the same relevant stream conditions and distinguish packet observation from a player’s visible picture. If the expected extension is absent, resolve the property, request and consumer-path evidence before proceeding.
    3. \n
  3. For the mapping exercise, choose a permitted identifiable event or object with corresponding metadata and video evidence. Have the integration owner explain how the timestamp is interpreted and associated with frames. Compare that result against the independent observation and the approved timing requirement. Retain uncertain or ambiguous associations as unresolved instead of reporting precise synchronization from the presence of a timestamp alone.
    4. \n
\n

Verification and evidence

\n

Retain the property responses, sanitized stream requests, bounded packet evidence and the method used to identify the extension. Keep the mapping inputs and resulting association together, including any unresolved clock or consumer dependency. Limit access to captures that reveal protected network details.

\n

Ask another reviewer to distinguish three conclusions: the device reports support, the chosen stream carries the extension, and the application’s association meets its requirement. Require separate evidence for each. These are proposed verification steps; no packet sample, synchronization measurement or successful metadata mapping is claimed by this article.

\n

Official references

\n\n

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

\n", "content_text": "Bottom line: Inspect the actual RTP extension before relying on timestamps for a frame-to-metadata association. Separate support, default enablement and the requested stream option so a working picture does not become the only acceptance evidence.\nSource fact: documented behavior\nAxis’s Onvif Replay Extension describes an RTP header extension carrying an NTP timestamp for video or audio streams, including a use case that maps timestamped metadata objects to video frames.\nThe documented support property is Properties.API.RTP.OnvifReplayExt, while Network.RTP.OnvifReplayExt controls default enablement.\nThe stream examples use onvifreplayext=1 to enable the extension and onvifreplayext=0 to disable it, including when it was enabled by default.\nWhat the source does not establish\nDo not infer clock accuracy, end-to-end synchronization quality or correct metadata association solely from an enabled property. Confirm the stream consumer’s support and the actual packet evidence. Keep this extension check separate from RTSP session survival, transport protection and approval of the broader video-management integration.\nApplicability questions\n\nDoes the exact device report the extension support property?\nWhat default enablement does it report, and what does the consumer explicitly request?\nWhich RTP stream and metadata object will the mapping exercise compare?\nWho can collect and inspect an authorized packet sample without exposing credentials?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends accepting the extension on an observed stream before using it as an input to frame-to-metadata mapping.\n\nRead the capability and default-setting properties through the documented workflow. Preserve both values with the camera/software identity. Capture the consumer’s sanitized stream request and identify whether it sets the extension option or relies on the default. Do not copy the documentation’s embedded example credentials into the test configuration; use the approved authentication and transport arrangement for the environment.\nIn an authorized isolated test, collect a bounded packet sample for the intended stream and inspect it for the RTP header extension. Prepare comparison cases with the documented enable and disable options where supported. Keep the same relevant stream conditions and distinguish packet observation from a player’s visible picture. If the expected extension is absent, resolve the property, request and consumer-path evidence before proceeding.\nFor the mapping exercise, choose a permitted identifiable event or object with corresponding metadata and video evidence. Have the integration owner explain how the timestamp is interpreted and associated with frames. Compare that result against the independent observation and the approved timing requirement. Retain uncertain or ambiguous associations as unresolved instead of reporting precise synchronization from the presence of a timestamp alone.\n\nVerification and evidence\nRetain the property responses, sanitized stream requests, bounded packet evidence and the method used to identify the extension. Keep the mapping inputs and resulting association together, including any unresolved clock or consumer dependency. Limit access to captures that reveal protected network details.\nAsk another reviewer to distinguish three conclusions: the device reports support, the chosen stream carries the extension, and the application’s association meets its requirement. Require separate evidence for each. These are proposed verification steps; no packet sample, synchronization measurement or successful metadata mapping is claimed by this article.\nOfficial references\n\nOnvif Replay Extension — Axis Communications; official VAPIX documentation.\n\nSource review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "content_markdown": "Bottom line: Inspect the actual RTP extension before relying on timestamps for a frame-to-metadata association. Separate support, default enablement and the requested stream option so a working picture does not become the only acceptance evidence.\n\n## Source fact: documented behavior\n\nAxis’s [Onvif Replay Extension](https://developer.axis.com/vapix/network-video/onvif-replay-extension/) describes an RTP header extension carrying an NTP timestamp for video or audio streams, including a use case that maps timestamped metadata objects to video frames.\n\nThe documented support property is Properties.API.RTP.OnvifReplayExt, while Network.RTP.OnvifReplayExt controls default enablement.\n\nThe stream examples use onvifreplayext=1 to enable the extension and onvifreplayext=0 to disable it, including when it was enabled by default.\n\n## What the source does not establish\n\nDo not infer clock accuracy, end-to-end synchronization quality or correct metadata association solely from an enabled property. Confirm the stream consumer’s support and the actual packet evidence. Keep this extension check separate from RTSP session survival, transport protection and approval of the broader video-management integration.\n\n## Applicability questions\n\n- Does the exact device report the extension support property?\n\n- What default enablement does it report, and what does the consumer explicitly request?\n\n- Which RTP stream and metadata object will the mapping exercise compare?\n\n- Who can collect and inspect an authorized packet sample without exposing credentials?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends accepting the extension on an observed stream before using it as an input to frame-to-metadata mapping.\n\n- Read the capability and default-setting properties through the documented workflow. Preserve both values with the camera/software identity. Capture the consumer’s sanitized stream request and identify whether it sets the extension option or relies on the default. Do not copy the documentation’s embedded example credentials into the test configuration; use the approved authentication and transport arrangement for the environment.\n\n- In an authorized isolated test, collect a bounded packet sample for the intended stream and inspect it for the RTP header extension. Prepare comparison cases with the documented enable and disable options where supported. Keep the same relevant stream conditions and distinguish packet observation from a player’s visible picture. If the expected extension is absent, resolve the property, request and consumer-path evidence before proceeding.\n\n- For the mapping exercise, choose a permitted identifiable event or object with corresponding metadata and video evidence. Have the integration owner explain how the timestamp is interpreted and associated with frames. Compare that result against the independent observation and the approved timing requirement. Retain uncertain or ambiguous associations as unresolved instead of reporting precise synchronization from the presence of a timestamp alone.\n\n## Verification and evidence\n\nRetain the property responses, sanitized stream requests, bounded packet evidence and the method used to identify the extension. Keep the mapping inputs and resulting association together, including any unresolved clock or consumer dependency. Limit access to captures that reveal protected network details.\n\nAsk another reviewer to distinguish three conclusions: the device reports support, the chosen stream carries the extension, and the application’s association meets its requirement. Require separate evidence for each. These are proposed verification steps; no packet sample, synchronization measurement or successful metadata mapping is claimed by this article.\n\n## Official references\n\n- [Onvif Replay Extension](https://developer.axis.com/vapix/network-video/onvif-replay-extension/) — Axis Communications; official VAPIX documentation.\n\nSource review completed October 29, 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/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/", "url": "https://update.dsesecurity.com/updates/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Verify Axis RTP timestamps before mapping metadata to video frames", "item": "https://update.dsesecurity.com/updates/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/#article", "identifier": "https://update.dsesecurity.com/updates/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/", "url": "https://update.dsesecurity.com/updates/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/", "headline": "Verify Axis RTP timestamps before mapping metadata to video frames", "description": "Check Axis Onvif Replay Extension capability, default configuration and per-stream selection separately before relying on RTP timestamps…", "abstract": "Check Axis Onvif Replay Extension capability, default configuration and per-stream selection separately before relying on RTP timestamps for frame-to-metadata mapping.", "articleBody": "Bottom line: Inspect the actual RTP extension before relying on timestamps for a frame-to-metadata association. Separate support, default enablement and the requested stream option so a working picture does not become the only acceptance evidence.\nSource fact: documented behavior\nAxis’s Onvif Replay Extension describes an RTP header extension carrying an NTP timestamp for video or audio streams, including a use case that maps timestamped metadata objects to video frames.\nThe documented support property is Properties.API.RTP.OnvifReplayExt, while Network.RTP.OnvifReplayExt controls default enablement.\nThe stream examples use onvifreplayext=1 to enable the extension and onvifreplayext=0 to disable it, including when it was enabled by default.\nWhat the source does not establish\nDo not infer clock accuracy, end-to-end synchronization quality or correct metadata association solely from an enabled property. Confirm the stream consumer’s support and the actual packet evidence. Keep this extension check separate from RTSP session survival, transport protection and approval of the broader video-management integration.\nApplicability questions\n\nDoes the exact device report the extension support property?\nWhat default enablement does it report, and what does the consumer explicitly request?\nWhich RTP stream and metadata object will the mapping exercise compare?\nWho can collect and inspect an authorized packet sample without exposing credentials?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends accepting the extension on an observed stream before using it as an input to frame-to-metadata mapping.\n\nRead the capability and default-setting properties through the documented workflow. Preserve both values with the camera/software identity. Capture the consumer’s sanitized stream request and identify whether it sets the extension option or relies on the default. Do not copy the documentation’s embedded example credentials into the test configuration; use the approved authentication and transport arrangement for the environment.\nIn an authorized isolated test, collect a bounded packet sample for the intended stream and inspect it for the RTP header extension. Prepare comparison cases with the documented enable and disable options where supported. Keep the same relevant stream conditions and distinguish packet observation from a player’s visible picture. If the expected extension is absent, resolve the property, request and consumer-path evidence before proceeding.\nFor the mapping exercise, choose a permitted identifiable event or object with corresponding metadata and video evidence. Have the integration owner explain how the timestamp is interpreted and associated with frames. Compare that result against the independent observation and the approved timing requirement. Retain uncertain or ambiguous associations as unresolved instead of reporting precise synchronization from the presence of a timestamp alone.\n\nVerification and evidence\nRetain the property responses, sanitized stream requests, bounded packet evidence and the method used to identify the extension. Keep the mapping inputs and resulting association together, including any unresolved clock or consumer dependency. Limit access to captures that reveal protected network details.\nAsk another reviewer to distinguish three conclusions: the device reports support, the chosen stream carries the extension, and the application’s association meets its requirement. Require separate evidence for each. These are proposed verification steps; no packet sample, synchronization measurement or successful metadata mapping is claimed by this article.\nOfficial references\n\nOnvif Replay Extension — Axis Communications; official VAPIX documentation.\n\nSource review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "datePublished": "2026-10-29T17:41:19+00:00", "dateModified": "2026-10-29T17:41:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/" }, "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/verify-axis-rtp-timestamps-before-mapping-metadata-to-video-frames/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/video-evidence-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/video-evidence-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Verify Axis RTP timestamps before mapping metadata to video frames" }, "articleSection": [ "IT", "Video Surveillance" ], "keywords": [ "IT", "Video Surveillance", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "wordCount": 550, "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 — Onvif Replay Extension", "url": "https://developer.axis.com/vapix/network-video/onvif-replay-extension/" } } ] } }