Privacy and data handling

This page is here to explain what RTSP.RUN actually does in day-to-day operation and what should be treated as a separate requirement before rollout.

This is not a zero-data or enterprise-governance claim page. The goal is to make the operating model explicit before a team starts assuming guarantees the product does not make.

Decision points worth clarifying early

  • RTSP.RUN is built for live playback and website embed.
  • It is not a system for recording, archiving, or analytics.
  • In the current flow, it only makes sense for publicly reachable RTSP/RTSPS streams.
Back to the player Put a camera on a website

What you can safely treat as in scope

  • Validation that a public RTSP stream can play in the browser.
  • Sharing the player or using generated embed code on a website.
  • Diagnosing common problems with RTSP URLs and public stream reachability.

What should lead to a different product decision

  • It is not a VMS, NVR, or CCTV management platform.
  • It is not designed for recording, retention, or analytics.
  • It is not suitable for closed internal camera networks in the default public mode.

What exists in the product flow during normal operation

  • Submitted contact forms are stored in the local inquiry store so product and business questions can be answered.
  • Basic product events such as stream-start attempts, embed opens, and contact submissions are stored in local marketing metrics.
  • Metadata about active and recent streams exists in application memory for playback, admin visibility, and troubleshooting.

What this page does not promise as an archive or governance layer

  • RTSP.RUN is not presented as a recording or archive platform for camera footage.
  • The public product flow is not sold as analytics, retention, or long-term surveillance storage.
  • If you need contractual data-processing, retention, or audit guarantees, treat that as a separate suitability question before rollout.