OpenAVC Network & Security Cut Sheet

Audience: IT administrators, network engineers, and security teams.

Scope: Network requirements, traffic profiles, security posture, and firewall rules for OpenAVC deployments. This is not an installation guide. It is a technical reference for evaluating and approving OpenAVC on a managed network. The settings, firewall commands and checklist for a locked-down system are in the Hardened Deployment Profile.

What Is OpenAVC?

OpenAVC is an open-source AV room control platform that runs on standard hardware (Windows or Linux PCs, VMs, Docker, Raspberry Pi). It controls projectors, displays, audio DSPs, video switchers, cameras, and lighting over standard IP protocols (TCP, UDP, HTTP, serial).

OpenAVC is a single application with a built-in web server. There is no external database, no application server, and no background services beyond the application itself. Configuration, automation, and device state are stored in local files on the host machine.

Deployment Scenarios

Existing PC in the room

The most common deployment. Most AV spaces already have a PC at the lectern, behind the display, or in the rack for digital signage, lecture capture, or room scheduling. OpenAVC runs on that existing PC alongside whatever else it does. It is a lightweight application, not a full operating system, and coexists with other software without conflict.

The same PC that presents content can also control the projector, switch inputs, and adjust audio. The touch panel interface can run right in a browser on that PC’s display, or on a separate tablet or touch screen in the room. If nobody needs a touch panel at all (e.g., everything is triggered automatically by schedules or sensors), OpenAVC runs quietly in the background with no visible UI.

Network impact: Minimal. The PC is already on the network. OpenAVC adds only targeted TCP connections to the specific AV devices in the room. No new hardware, no new network drops.

Dedicated controller (mini PC or Raspberry Pi)

For spaces where there is no existing PC, or where a dedicated appliance is preferred, OpenAVC runs on a small-form-factor PC (Intel NUC, Lenovo Tiny, HP Mini, etc.) or a Raspberry Pi. The Pi image can optionally drive a touch panel display directly via HDMI.

Network impact: One new device on the room’s network segment. Communicates only with AV devices on its local subnet and serves a web interface to touch panels or browsers in that room. No traffic leaves the room unless the optional cloud service is enabled.

Server or VM on the building network

OpenAVC runs on an existing server, VM, or Docker host. It controls AV equipment across multiple rooms from a central location.

Network impact: The server needs IP reachability to every AV device it controls, and devices presenting the touch panel UI need HTTP access to the server. If rooms are on isolated VLANs, firewall rules or routing must allow the server to reach those VLANs on the specific ports listed below.

Network Requirements

Listening ports (inbound to the OpenAVC host)

Port	Protocol	Purpose	Required?
8080	TCP (HTTP)	Web interface and REST API	Yes
8443	TCP (HTTPS)	Web interface and REST API over TLS	Only when HTTPS is enabled in Settings > Security
80	TCP (HTTP)	Convenience redirect so typed URLs can omit the port (`http://<server>/panel`). Pure redirect to the real HTTP/HTTPS port; serves no content.	No — off by default; enable in Settings > Network
19500	TCP (HTTP)	Device simulator, bound to localhost only	No
19872	UDP	ISC auto-discovery (multi-instance setups only)	No
5353	UDP	mDNS advertising — lets OpenAVC Panel apps auto-discover this instance on the LAN	No — on by default; disable with `discovery.advertise: false`
8189	UDP	WebRTC media for the Video Panel plugin (live camera/RTSP streams on the panel)	Only when the Video Panel plugin is installed and a panel is viewing a stream
8190	UDP	WebRTC media for the Present plugin (wireless presentation)	Only when the Present plugin is installed and someone is presenting or a display is connected
8554	TCP (RTSP)	Present plugin stream-display output — hardware decoders pull the presentation stream	Only when the Present plugin is installed and a stream display uses RTSP
8899	UDP (SRT)	Present plugin stream-display output — same stream over SRT	Only when the Present plugin is installed and a stream display uses SRT
22	TCP (SSH)	Remote console login, Raspberry Pi appliance image only	No: ships disabled; operator-enabled in Settings > Access
Device-specific	UDP (multicast)	Device push notifications — some drivers join a multicast group the device sends state-change frames to (for example, an Audio-Technica SmartMixer notifying on 239.0.0.100:17000)	Only while such a device is connected; the group and port come from the driver and are shown in its setup notes. Opened by OpenAVC on Linux; see below
Device-specific	TCP	Device push notifications (dial-back) — some drivers open a listener port that the device connects back to with state-change frames (for example, a Panasonic PTZ camera dialing the port its driver registered, 31004 by default)	Only while such a device is connected; the port comes from the driver’s device settings and is shown in its setup notes. Opened by OpenAVC on Linux; see below
Device-specific	UDP	Device push notifications (packets to a port) — some drivers open a UDP port that the device is set to send its changes to (for example, SNMP traps to port 162)	Only while such a device is connected; the port comes from the driver’s device settings and is shown in its setup notes. Opened by OpenAVC on Linux; see below
(rides 8080/8443)	TCP (HTTP)	Device push notifications (HTTP callbacks) — some devices post state changes to `/api/push/` on the existing web port; see “Device push notifications (HTTP callbacks)” below	No new port — the web port already listed; active only while such a device is connected

Port 8080 is the only port that must be accessible for a standard single-room deployment when HTTPS is off (the default). This is configurable via the OPENAVC_PORT environment variable or system.json.

Port 8443 is opened when HTTPS is enabled. When both listeners are running, the HTTP listener on 8080 returns a temporary (302/307) redirect to the HTTPS URL — so existing bookmarks and panel devices keep working without reconfiguration, and nothing is cached that would break access if HTTPS is later disabled. If you disable the redirect listener (Settings > Security), only port 8443 is open. Port 8443 is configurable via OPENAVC_TLS_PORT or tls.port in system.json.

Port 19500 is used by the device simulator during development and testing. It is only active while the simulator is running, and it listens on localhost only, so nothing outside the server can reach it and it never needs to be opened in a firewall. The Simulator UI you use in the browser is served by OpenAVC on its normal port, at /simulator/, behind the same sign-in as the Programmer.

Port 19872 is used only when multiple OpenAVC instances need to discover each other on the same LAN (inter-system communication). It can be disabled entirely.

Port 5353 carries the mDNS advertiser, which is on by default. OpenAVC announces itself as _openavc._tcp.local. so the OpenAVC Panel apps can find the instance without being given its address. It sends three announcements at startup, re-announces every 60 seconds for as long as the service runs, answers queries for its own record, and sends goodbye records when it stops. It carries no control surface. The advertiser follows Accept connections from (Settings > Network), not the adapter device traffic uses: with Any network it announces on each non-loopback IPv4 interface, with one adapter only on that adapter, and with This computer only not at all. Disable it with discovery.advertise: false in system.json if the panel apps are not used or the site suppresses mDNS.

Port 8189 is opened only when the optional Video Panel plugin is installed. That plugin displays live IP camera and RTSP streams on the touch panel, and it delivers video to the browser over WebRTC. The browser sends its media to UDP 8189 on the OpenAVC host. For a panel on the same subnet as the host this often works without any change, because consumer firewalls tend to allow same-subnet UDP. If panels are on a different VLAN or subnet, or video tiles stay black while the rest of the panel works, allow inbound UDP 8189 to the OpenAVC host from the panel devices’ subnet.

From version 0.31.0 OpenAVC adds this rule itself, where it is able to. The plugin declares the port it needs and the server opens it on the host firewall, then removes it again if the plugin is uninstalled. Three cases where it cannot, and tells you so in the system log rather than failing quietly:

Windows, server not installed as a service. Changing the firewall needs administrator rights. A service has them; a server started by hand from a terminal does not. The log names the exact netsh command to run.
Linux with no active firewall manager. The helper drives ufw or firewalld. If neither is active there is nothing to configure, and nothing is blocking you either.
Docker. Container port mapping is yours to set; nothing inside the container can open a port on the host.

On Linux the rule is applied when the service next starts, not the moment the plugin is enabled. Rules OpenAVC adds are named so you can find them; rules you added by hand are never touched. On a managed network, verify the rule exists rather than assuming it. The port is only active while the plugin is running. If the Video Panel plugin is not installed, this port is never opened.

The Video Panel plugin can also show the built-in preview stream of an AV-over-IP encoder (for example a TurtleAV Chazy encoder), which appears on the panel automatically once its controller is connected. These preview streams usually live on the AV/video network, which is commonly a separate VLAN from the control network. The OpenAVC host fetches the preview and passes it to the panel over the host’s normal web port, so no extra inbound port is needed on the panel side. What is required is that the OpenAVC host can route to the encoder’s video network. A host with a second network interface on the AV fabric is the typical arrangement. The panel browser never connects to the video network directly.

Port 8190 is opened only when the optional Present plugin (wireless presentation) is installed. Present carries video over WebRTC in both directions: a presenter’s laptop sends its screen-share media to UDP 8190 on the OpenAVC host, and the devices driving the space’s displays receive video from the same port. As with the Video Panel port, same-subnet traffic usually works without changes; if presenters or display devices are on a different VLAN or subnet — presenters on a guest wireless network is the common case — allow inbound UDP 8190 to the OpenAVC host from those networks. The signaling and the join pages ride the normal web ports (8080/8443). The port is only active while the plugin is running, and it is never opened if the plugin is not installed.

Ports 8554 and 8899 also belong to the Present plugin and serve its stream displays: a hardware IP decoder at a display pulls a continuous presentation stream from the OpenAVC host over RTSP (TCP 8554, TCP-interleaved — no UDP RTP port range) or SRT (UDP 8899). Only decoders need to reach these ports, and only the space’s own output streams can be pulled from them: each stream URL embeds a per-display secret key, reads are limited to those output paths, and nothing can be published to the host through these ports without internal credentials that never leave the machine. If a decoder sits on an AV VLAN, allow it inbound TCP 8554 or UDP 8899 to the OpenAVC host (pick the protocol the decoder uses). Like the WebRTC port, these listeners exist only while the plugin runs. A space that uses only browser displays never has a decoder pulling from them, and they can stay blocked.

Device push notifications (multicast). A few AV devices report state changes by multicasting small UDP frames to a group address instead of answering only when polled. When a driver for such a device is connected, OpenAVC joins that group (standard IGMP membership) and listens on the device’s notification port — receive-only, filtered to frames from that device’s own IP address, active only while the device is connected. Two network notes: multicast does not cross VLANs, so the device and the OpenAVC host must share one (or your routers must be configured for multicast routing); and on switches with IGMP snooping enabled, an IGMP querier must exist on the VLAN or the switch may stop forwarding the group and the notifications silently disappear. Nothing breaks if the frames are filtered — OpenAVC keeps polling the device and changes simply appear at poll speed instead of instantly. A few things arrive only this way, such as a mixer’s live level meters, and those stop.

Device push notifications (TCP dial-back). A few devices — Panasonic PTZ cameras are the common case — push state changes by connecting to the OpenAVC host on a TCP port the driver registers with the device. While such a device is connected, OpenAVC listens on that port (fixed per device in the driver’s settings, 31004 by default for the Panasonic cameras; several devices of the same kind can share one port). The listener is receive-only: it accepts connections only from the addresses of the devices registered to it, closes anything else immediately, and carries no control surface — inbound frames can only update that device’s displayed state, never command anything. Like UDP device control, these frames are unauthenticated by the device’s own protocol design, so the trust model is the AV/control VLAN they live on. Firewall note: allow the listener port inbound to the OpenAVC host from the device’s address or the AV VLAN only. If the port is blocked, nothing breaks — polling covers the device and changes appear at poll speed.

Device push notifications (UDP packets to a port). Some devices send each change as a UDP packet to an address and port set on the device itself; SNMP traps to UDP 162 are the common case. Set the device to send to the OpenAVC host’s address and the port in the driver’s settings. While such a device is connected, OpenAVC listens on that port (several devices can share one). The listener is receive-only: it accepts packets only from the addresses of the devices that use it, drops anything else, and carries no control surface — a packet can only update that device’s displayed state. Like UDP device control, these packets are unauthenticated by the device’s own protocol design, so the trust model is the AV/control VLAN they live on. OpenAVC takes the port for itself: if another program on the host already listens on it (an SNMP trap receiver on 162, say), OpenAVC cannot open it, its log says so, and the device works at poll speed. Firewall note: allow the port inbound to the OpenAVC host from the device’s address or the AV VLAN only. If it is blocked, nothing breaks — polling covers the device and changes appear at poll speed.

Opening the push ports on the OpenAVC host. On a Linux install with ufw or firewalld active, OpenAVC opens the multicast, dial-back and UDP listener ports itself, the same way it opens a plugin’s port: for every enabled device in the project whose driver listens for pushes, at the next start of the OpenAVC service (the system log says so when a device adds one), and it closes a port again when no device needs it. The rule allows the port from any address; to limit it to the AV VLAN, see Hardened Deployment Profile. A dial-back port set to 0 (the system picks a free one each time) cannot be opened ahead of time, so give such a device a fixed port. On Windows the installer’s program rule already covers these ports. On Docker, open them on the host yourself; with bridge networking a UDP listener port has to be published with its protocol, and with host networking an image older than 0.40.0, or a container that drops its capabilities, cannot open one below 1024 (Deployment).

Device push notifications (event streams). Some HTTP-controlled devices (Barco ClickShare, Philips Hue bridges) stream state changes over Server-Sent Events instead. For these, OpenAVC simply holds one or more ordinary outbound HTTP(S) requests open to the device’s existing API port — the same port the driver already polls, with the same authentication and TLS. No inbound port opens on the OpenAVC host, nothing crosses VLAN boundaries beyond the device connection you already allow, and no firewall change is needed. The only infrastructure note: middleboxes that aggressively time out long-lived idle HTTP connections (some proxies and stateful firewalls between VLANs) can silently kill an event stream; the driver notices, reconnects automatically, and polling covers any gap.

Device push notifications (HTTP callbacks). A third group of devices (Cisco video codecs, Sonos speakers) delivers notifications the other way around: the device connects to OpenAVC and posts small HTTP requests to a callback URL the driver registers on it. These callbacks arrive on the web port the host already listens on (8080 by default; no new port opens), on paths under /api/push/, under every Accept connections from choice: when the choice does not cover the address a device sends to, OpenAVC also listens on the web port at that address, for /api/push/ alone. Three things about this surface. First, it is receive-only and narrowly scoped: a posted body is handed to the one connected device’s driver for state parsing, only requests from the address the driver registered are accepted (the device’s own, or, for a Sonos speaker playing in a group that another room leads, that room’s speaker), and the path answers 404 whenever no matching device is connected; it exposes no data and no control operations. Second, the callbacks are unauthenticated plain HTTP: AV devices cannot carry credentials for this, and most cannot deliver to a server whose certificate they don’t trust, so treat it with the same posture as UDP device control: keep AV devices and the OpenAVC host on a trusted AV VLAN, where source-address trust is acceptable. (When HTTPS is enabled with the HTTP redirect listener left on, callbacks still work: the redirect listener serves /api/push/ directly rather than redirecting, because devices don’t follow redirects. In an HTTPS-only configuration the callback URL becomes https, and the device must be set to accept the server’s certificate; the driver’s setup notes say if and how.) Third, the device must be able to reach the host: a one-way firewall rule that only allows OpenAVC → device drops the notifications. As with every push channel, nothing breaks if callbacks are blocked: polling carries on and changes appear at poll speed.

Apart from the mDNS advertiser noted above (standard multicast DNS, no control surface), the application does not listen on any other ports by default: no SNMP agent, no embedded database port, and no proprietary discovery protocol that accepts inbound connections. The Raspberry Pi appliance image can optionally run an SSH server (port 22) for remote console access, but it ships disabled; an operator turns it on in Settings > Access when it is needed (see Raspberry Pi appliance below).

Who can access the web interface

OpenAVC separates two surfaces with different access rules:

The room panel (/panel) — the end-user touch interface — never asks for a login. Who may connect is Panel access. With Approved panels only (the default on a fresh install), a new tablet or browser is shown a waiting screen with a six-digit code until an administrator approves it once, from the Programmer or by entering the admin password on the device itself; the device is then remembered by a cookie the server issued and connects without being asked again. With Anyone on the network, any device that can reach the port connects. The screen on the OpenAVC host itself, a panel opened through OpenAVC Cloud, and any client presenting the admin credential connect without approval. An approved panel may send any device command the system knows, not only the ones on its pages, so approval is the boundary around control, and network reachability is the boundary around that. A system updated from a version before Panel access existed comes up as Anyone on the network so its panels stay connected, and the Programmer says so once; a fresh install starts as Approved panels only.
- A project can set a panel lock PIN, which covers the panel with a lock screen when it opens and after its idle timeout. The PIN is checked on the server and attempts are rate-limited, so it is not readable from the panel device and not worth guessing at. It gates the touch interface, not the network: it is there to stop stray taps on a public display, and anyone who can reach the panel’s address can still reach the panel’s own open endpoints. Treat network reachability as the access control, and the PIN as what keeps a passer-by from changing the room.
The Programmer (configuration interface) and the control/admin API require an admin credential.

Wireless presentation guest pages (Present plugin). When the optional Present plugin is installed, it adds two login-free pages on the standard web ports: the guest connect page (/present), where a presenter enters the rotating join code shown on the space’s displays, and the display pages that drive each screen, each gated by a long per-display key carried in its URL. Neither grants any access to the configuration interface or the API. Wrong join codes are rate-limited, the code rotates between presentation sessions, and a display’s key can be regenerated to revoke its link. Screen sharing additionally requires HTTPS to be enabled on the instance, because browsers only permit screen capture on a secure page. These pages exist only while the plugin is installed and running.

Secure by default. Packaged deployments (Windows installer, macOS installer, Linux install.sh, Docker, Raspberry Pi image) accept connections from any network by default so panels can reach them, but they ship with no credential and refuse admin access until one is set. The first time someone opens the Programmer, OpenAVC presents a one-time “create admin password” screen. Until that is done, the configuration interface and control API return HTTP 401; only the panel page, its approval check-in and the health/status endpoints respond, and no panel can be approved until the password exists. There is no default password and no open admin surface on a shipped box.

Code-writing endpoints are never open. The endpoints that create or edit Python drivers and scripts (which execute code on the host) always require the admin credential, even on an instance that is otherwise configured for open access.

Who can connect. Settings > Network > Accept connections from (the listen address) chooses which of the host’s networks can open the panel and the Programmer: Any network (the default on every installed system), one adapter, followed to a new address after a DHCP renewal, or This computer only (the default on a run from source). The server also listens on 127.0.0.1 under every choice, for the host’s own screen, its tray or menu bar app and remote access through OpenAVC Cloud. If the chosen adapter is unplugged or has no address, the server accepts connections from this computer only until the adapter returns, never from every network. OPENAVC_BIND in the service environment (0.0.0.0, 127.0.0.1, or one of the host’s addresses) overrides the setting and locks it (Setting values in the environment). Before OpenAVC 0.37.0, every packaged install set OPENAVC_BIND=0.0.0.0; on those versions, restrict access with the firewall (Hardened Deployment Profile). Updating to 0.37.0 or later removes that 0.0.0.0 from the Windows service, the Linux service and the macOS launch settings (on a Mac, from the next restart of OpenAVC) and keeps any other value. Docker keeps it.

Credentials. The admin password set during first-run setup is stored in system.json on the host, as a salted scrypt hash rather than the password itself, in a file readable only by the account the service runs as. It can be changed later in Settings > Access > Programmer login. Both places require at least 8 characters. For unattended provisioning, it can also be supplied up front via OPENAVC_PROGRAMMER_PASSWORD (and optionally OPENAVC_PROGRAMMER_USERNAME), with an OPENAVC_API_KEY alongside it for programmatic clients; an instance configured this way is already “claimed” and goes straight to the login screen. Provision the password too, not the key alone: the login screen only accepts a password, so a key on its own leaves the Programmer unreachable from a browser. A password or API key written into system.json by hand is converted to a hash the next time the service starts, and both keep working across that conversion.

If the admin password is lost. It cannot be read back out of system.json; it is reset instead. A file named reset-programmer-password in the data folder, present when the service starts, clears the admin username, password and API key, and the next visit to the Programmer offers the “create admin password” screen again. Writing that file takes the same rights as editing system.json: the Windows tray and the Mac menu bar write it through an administrator prompt, and on a Raspberry Pi a file named openavc-reset-password on the SD card’s boot partition is moved into place at the next start. Forgot the Programmer Password has the steps for each install. Projects, devices, panels and the cloud connection are untouched. On a Raspberry Pi the openavc operating-system login is locked again until a new admin password is set.

The Raspberry Pi appliance image hardens the operating-system login as well as the web interface:

No shipped OS password. The openavc Linux account is locked in the image — there is no openavc/openavc (or any other) default login. The kiosk display still starts automatically; auto-login does not use a password.
One credential. The admin password set during first-run setup becomes the OS console/SSH login for the openavc user too, so there is a single password to manage. Changing it in Settings > Access > Programmer login re-syncs the OS login.
SSH off by default. No SSH server runs until you enable it with the Enable SSH toggle in Settings > Access. Once on, log in as openavc with the admin password over port 22. Turn it back off from the same toggle.

This is Pi-image-specific. On a generic Linux install.sh host, OpenAVC does not touch the operating-system account or sshd — the server runs as an unprivileged service user and you manage OS login and SSH yourself.

Fronting OpenAVC with your own auth (an SSO reverse proxy, for example): set OPENAVC_ALLOW_ANONYMOUS=true to opt back into open admin access, and restrict reachability at the proxy. Have the proxy set X-Forwarded-For, and set network.trust_forwarded_for: true in system.json so per-client rate limiting sees the real client IP; a proxy that does not reach OpenAVC over loopback (on another machine, or in front of Docker) also goes in network.trusted_proxies. Without the header, every request through a proxy on the same machine arrives from the machine itself and is treated as the machine’s own screen. The proxy also has to be the only way in. The steps are in Behind a reverse proxy.

Outbound Traffic (OpenAVC host to the network)

AV device control

OpenAVC initiates outbound TCP and UDP connections to AV equipment. The specific ports depend entirely on which devices are configured in the project. OpenAVC only communicates with devices explicitly defined in the project configuration, using the ports those devices expect. It does not scan or probe the network during normal operation.

Offline devices are retried indefinitely. When a configured device stops answering, OpenAVC keeps trying to reconnect to it, by default every 5 seconds, for as long as that device remains in the project. This is deliberate. A display that is unplugged on Friday has to come back on its own when it is plugged in again on Monday, without anyone opening the configuration interface. The traffic is one connection attempt per offline device per interval, always to that device’s own configured address and port, and never to any address that is not already in the project. Nothing is swept, ranged, or discovered by this. If your monitoring flags repeated connection attempts to a host that is powered down, this is the source. The interval is adjustable in Settings > Devices > Retry every (1 to 300 seconds), which is saved with the project; devices.reconnect_interval_seconds in system.json applies when the project does not set one. The one exception is a device whose driver declared that a command it was just sent restarts it: for that declared window only, and only for that device, attempts come about every two seconds so the device is picked up promptly when it finishes booting. The window is capped at ten minutes and ends as soon as the device answers.

The table below lists common AV control ports. This is not exhaustive. AV manufacturers use a wide range of proprietary and standard ports, and new drivers may use ports not listed here.

Pulling video from a device (RTSP, MJPEG, SRT). When the optional Video Panel plugin shows a video source on a panel — an AV-over-IP encoder, a production switcher, an IP camera — the OpenAVC host is the one that connects to that device and fetches the video. The panel never talks to the AV equipment itself. That means only the OpenAVC host needs a route to wherever the video lives, which is often a separate AV or video VLAN, and a host with a second network connection onto that fabric is the usual arrangement.

These connections are outbound only and open nothing new on the OpenAVC host — including SRT, which is how a software or hardware production switcher is normally pulled in. OpenAVC dials out to the device’s SRT port rather than listening for it, so no inbound firewall rule is needed for the ingest side. The one port that does have to be reachable inbound is the WebRTC media port above, and that is between the panel and the OpenAVC host, not the AV network.

The ports involved are whatever the device serves on: commonly TCP 554 for RTSP, the device’s own HTTP port for an MJPEG preview, and a UDP port chosen per output for SRT (vMix offers 10000 by default). On a managed network, allow the OpenAVC host outbound to those ports on the AV VLAN. If a video tile shows an error rather than a picture, this route is the first thing to check — the server log names the address it could not reach.

Port	Protocol	Device type	Example
22	TCP (SSH)	Embedded devices, AV processors	Managed switches, Biamp Tesira
23	TCP (Telnet)	Switchers, DSPs, amplifiers	Extron, Biamp, QSC, Kramer, Shure, LG
80	TCP (HTTP)	Devices with web APIs	Panasonic cameras, REST-based devices
443	TCP (HTTPS)	Devices with secure web APIs	Newer AV-over-IP devices
445	TCP (SMB)	Windows-based AV servers, NAS	File access
1400	TCP	Audio	Sonos UPnP
1515	TCP	Samsung commercial displays	Samsung MDC protocol
1688	TCP	Crestron-compatible devices	Crestron CIP
1710	TCP	Audio DSPs	Q-SYS QRC (JSON-RPC)
3088	TCP	Crestron-compatible devices	Crestron XIO
4352	TCP	Projectors	PJLink standard
5000	TCP	Switchers, DSPs	Kramer Protocol 3000 / Q-SYS QRC alt
5900	TCP	Remote desktop/preview	VNC
7142	TCP	AMX-compatible devices	AMX ICSP
8080	TCP	Devices with web APIs	Alternate HTTP management
9090	TCP	Devices with web APIs	Alternate HTTP management
10500	TCP	PTZ cameras	Sony VISCA over IP
41794	TCP	Crestron-compatible devices	Crestron CTP
49280	TCP	Audio mixers	Yamaha RCP (CL/QL/TF/Rivage/DM3)
52000	TCP	Audio DSPs	QSC Q-SYS
61000	TCP	Wireless microphones	Shure DCS
161	UDP	SNMP-managed devices	SNMP v2c status queries, and control writes on a device set up for them
9	UDP broadcast	Displays, projectors and PCs powered on over the network	Wake-on-LAN (some drivers use port 7)
5568	UDP multicast	Lighting nodes, gateways and fixtures	sACN (E1.31) lighting levels, to one group per universe (239.255.0.1 for universe 1)
5343	TCP	Network-attached control surfaces	Elgato Network Dock, Stream Deck Studio (Stream Deck plugin)

An OpenAVC instance controlling only PJLink projectors and a Biamp DSP, for example, will only generate traffic on ports 4352 and 23 (22 if the DSP is set to SSH). If your network policy requires explicit allow-listing, the exact ports in use for a given deployment can be determined from the project’s device configuration.

SNMP-controlled devices (port 161). Rack PDUs, UPSes, managed switches and environmental sensors are usually controlled over SNMP rather than a control protocol. OpenAVC reads and writes those values on UDP 161 as an ordinary outbound device connection, to the addresses in the project and no others. Three things are worth knowing before you allow it:

SNMP v2c has no encryption and no real authentication. The community string travels in cleartext in every request, so anyone who can see the traffic can read it and reuse it. Treat a write community as a credential that is exposed on the wire: keep SNMP on the control VLAN, and give OpenAVC a community that reaches only the equipment it manages.
Reading and writing are separate permissions, and most equipment ships a different community string for each. OpenAVC writes only the values an installer has declared as writable for that device, so a device added for monitoring has none to write. If you want that guaranteed by the network rather than by the configuration, withhold the write community: the device itself refuses a write attempted under a read-only community.
Version 3 is not supported. SNMPv3 adds per-user authentication and encryption; OpenAVC speaks v2c only. A device that has been locked to v3 will not answer, and will show as offline rather than as a permissions error, because an SNMP agent ignores a request it will not serve instead of refusing it.

SSH-controlled devices (TCP 22). Managed switches, some audio DSPs, video bars and headends are controlled over SSH. OpenAVC connects with the OpenSSH client on its host, signing in with a password or with OpenAVC’s own key (shown on the device’s page). Three things are worth knowing:

Host keys are checked. The first connection remembers the device’s host key, and a changed key is refused until someone re-accepts it (see SSH host key changed below).
A few older algorithms are also offered. To reach AV equipment whose SSH is older than current OpenSSH defaults, OpenAVC also offers hmac-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1 and ssh-rsa. They are added after the client’s own list, so a device that supports stronger algorithms still uses those; only a device that offers nothing newer connects with these. To hold one device to stronger algorithms, list them in its SSH options (Edit Device, under Advanced), for example MACs=hmac-sha2-256,hmac-sha2-512, which replaces the older offer for that device.
Anything weaker is allowed per device, by hand. A device that offers only algorithms outside that list does not connect; its banner names them and gives the line that allows them for that one device. SSH options accept connection settings only (algorithm lists, timeouts, keep-alives, sign-in choices). A setting that would run a program on the OpenAVC host, such as ProxyCommand, is refused.

Wake-on-LAN (UDP 9). A display, projector or PC that is powered on over the network is sent a Wake-on-LAN packet, only when a power-on command runs: to the broadcast address 255.255.255.255 and usually also straight to the device’s own address. Some drivers use port 7. A broadcast stays on the network segment it is sent on; routers do not forward it. With Reach devices through (Settings > Network) set to Every connected adapter, the broadcast is sent once on each network the OpenAVC host is connected to. Choose the AV adapter there to keep it on the AV network. It is then sent on that network only, from the adapter’s self-assigned 169.254 address on a network with no DHCP server, and not at all while that adapter has no address (unplugged, say); it is never sent on another network instead.

Lighting over sACN (UDP 5568). The sACN lighting driver sends lighting levels to a multicast group for each universe (239.255.0.1 for universe 1): on every change, and about once a second when nothing changes. Set to unicast, it sends them straight to one lighting node’s address instead. A multicast group stays on the network segment it is sent on. With Reach devices through set to Every connected adapter, the levels are sent once on each network the OpenAVC host is connected to, so they also reach a campus network or Wi-Fi the host is on. Wi-Fi sends multicast at its slowest rate, so a busy universe can slow a Wi-Fi network. Choose the lighting adapter there to keep the levels on the lighting network. They then go out on that network only (from its self-assigned 169.254 address on a network with no DHCP server), and stop while that adapter has no address (unplugged, say); they are never sent on another network instead.

Network-attached control surfaces (port 5343): when the Stream Deck plugin is configured with a network-attached deck, the server keeps an outbound TCP connection to the unit on port 5343 and may send mDNS queries (UDP multicast 224.0.0.251:5353) to find it. This protocol has no authentication or encryption — any host on the segment can drive the unit — so place these devices on the control VLAN with the AV equipment. mDNS discovery does not cross VLANs, NAT, or Docker bridge networks; the surface is added by IP address there (a static IP on the unit is recommended).

Diagnosing offline devices

When a device can’t connect, its card in the Programmer shows an “Offline” banner with a specific reason. Use it to tell a network problem from a credentials or device problem before escalating:

Banner reason	What it means	What to check
Authentication failed	The device answered, but rejected the username/password or key.	The credentials in the device’s configuration. For SSH gear, that the OpenAVC key is installed, or that password auth is enabled. Not a network problem.
Connection refused	OpenAVC reached the device’s IP, but nothing is listening on that port.	That the control service is enabled on the device (SSH/Telnet/HTTP/API server), and that the configured port matches. Not usually a firewall problem (a firewall drop normally shows as “unreachable”).
Can’t reach the device	No route to the host, a DNS failure, or a connection timeout.	The device IP, that the host is powered and on the network, VLAN/routing between the OpenAVC host and the device, and any firewall blocking the control port.
SSH host key changed	The device’s SSH host key no longer matches the one OpenAVC trusted.	Whether the device was replaced or re-imaged (expected), or whether this is unexpected (possible man-in-the-middle). Re-accept the key only once verified.
Device didn’t respond as expected, or stopped answering	The connection opened, but the device never answered in the expected protocol, or answered and then went quiet.	If it never answered: that the address, the port, the driver and the transport (e.g. SSH vs Telnet) are right for this device. If it stopped: whether the device is powered on and responsive.
Device stopped accepting data	The connection is still open, but the device has stopped reading from it — typically equipment that has locked up without dropping its network link.	The device itself rather than the network: whether it is responsive at its own front panel or web interface. It usually needs a power cycle. OpenAVC keeps retrying, so it recovers by itself once the device does.
Required client not found	A client OpenAVC shells out to is missing on the host (e.g. the OpenSSH `ssh` client).	That the client is installed and on the system PATH on the OpenAVC host.
Device only offers older SSH encryption	The device’s SSH server offers only algorithms the OpenAVC host’s SSH client does not use unless told to.	Whether newer firmware for the device supports current SSH. If not, the banner gives the line that allows the named algorithm for this device only, in its SSH options.

For a network reason (connection refused, can’t reach the device, no response, stopped accepting data), OpenAVC retries automatically and does not stop. Attempts start about a second apart and settle to one every 5 seconds, so a device that is repaired, powered back on, or plugged back in comes back by itself within seconds. While a device is inside a declared restart window (see above) the interval is about two seconds instead. Reasons that retrying can’t fix — authentication failed, SSH host key changed, an untrusted TLS certificate, invalid connection settings, or a missing client — stop the retry loop early instead, and the banner says so. Fix the cause and press Reconnect. The same reason is also published as the device.<id>.offline_reason state key for automation and monitoring.

Device discovery (on-demand only)

OpenAVC includes a network discovery feature to help AV integrators find devices during initial setup. Discovery is never automatic. It runs only when a scan is explicitly started — by an integrator in the Programmer interface, or by an authenticated request to the discovery API (including from the cloud console). Each scan stage is budgeted from the work in front of it — the number of addresses to sweep, then how many hosts responded — and the scan as a whole is capped at 120 s (Quick), 300 s (Standard), or 600 s (Thorough). Those caps are upper bounds rather than typical durations: a /24 completes in under a minute at Quick and Standard depth and in about a minute at Thorough, which listens longest for device announcements, and a full /20 (about 4,000 addresses) in roughly two minutes. A stage that cannot cover its work in the time available scans less and reports what it skipped; it does not extend the scan.

During a discovery scan, OpenAVC will:

Ping sweep the local subnet(s) using ICMP echo requests. The server prefers an unprivileged ICMP datagram socket where the OS allows it, uses a raw ICMP socket where one is available (the packaged Linux service and Docker image are granted the CAP_NET_RAW capability for this), and falls back to the system ping command otherwise. Firewalls on the AV VLAN must permit ICMP echo request/reply for discovery to see hosts; a host that drops echo is still port-scanned when the ARP table or the mDNS / SSDP listeners find it.
TCP port scan each responding host, on a list of about 55 TCP ports assembled at scan time. It is the sum of three things: a five-port baseline (22, 23, 80, 443, 8080) for banner reading and web management, every port declared by the drivers installed on this instance, and every port declared by the community driver catalog. The third source is worth noting, because it is not what most people assume: the catalog contributes the ports of drivers you have not installed, so the list does not narrow to the equipment in your project, and it grows as the catalog grows. Thorough depth adds eight generic alternate web, RTSP and management ports (554, 3000, 4000, 5060, 8443, 8888, 9000, 10000), for about 63 in total.
SNMP query (v2c, community string public, read-only) on port 161
mDNS / DNS-SD query on multicast group 224.0.0.251:5353. Alongside the service types that installed drivers declare, the scan sends the standard DNS-SD meta-query (_services._dns-sd._udp.local.), which asks the segment to name every service type advertised on it rather than only the AV ones.
SSDP M-SEARCH on multicast group 239.255.255.250:1900
AMX DDP listen on multicast group 239.255.250.250:9131 (passive — receive only)
NetBIOS name query on UDP 137 to live hosts (Standard / Thorough scan only)
Driver-declared TCP probes on open AV ports. Each installed driver may declare its own probe; common probes for AV equipment include identification queries against switchers, DSPs, displays, mixers, and cameras (Extron, Biamp Tesira, QSC Q-SYS, Samsung MDC, Yamaha RCP, Sony VISCA, etc.). The exact wire format and port depend on which drivers are installed; the Programmer IDE’s Driver Builder shows them per driver. A port gets one probe at a time, after one connection that sends nothing and reads what the port says. A port that answers with a login prompt is sent only the probes that look for that prompt, never another manufacturer’s query.
Driver-declared UDP probes if any installed driver declares one. These are sent to each scanned subnet’s directed-broadcast address, or straight to the device when a single address is scanned. Examples include PJLink Class 2 SRCH (UDP 4352) when the pjlink_class1 driver is installed and Crestron CIP discovery (UDP 41794) when the utility/crestron_cip driver is installed, along with other vendor-specific broadcasts shipped by individual drivers.

All discovery traffic is confined to the local subnet(s) of the host’s connected network interfaces (an interface with no link is skipped), or of the one adapter chosen under Reach devices through in Settings > Network. It does not scan remote subnets, public IP ranges, or addresses outside the host’s directly-connected networks. Virtual and VPN adapters are left out, except a Windows virtual machine’s own network adapter (on Hyper-V or Azure) and a Hyper-V External switch, which are scanned.

Driver-declared probes, UDP sends and TCP connections alike, are rate-limited to 10 per second across the whole scan. With an adapter chosen under Reach devices through, everything a scan sends (ping, the port scan, SNMP, NetBIOS and the probes) leaves through it. Each probe is sent once per scan, with no retries.

Devices already in the project are left alone. A scan reads where each connected device in the project is connected when it starts, and neither the port scan nor any probe opens those ports.

The three multicast groups above are joined per interface. With an adapter chosen under Reach devices through, they are joined and queried on that adapter only. With Every connected adapter, the default, they are joined on every non-loopback IPv4 interface the host has, so a machine with a foot on two segments (an AV VLAN and the campus LAN, say) queries both. Choosing the AV adapter is what confines them.

A scan also makes one outbound HTTPS request to raw.githubusercontent.com to refresh the community driver catalog, which is what supplies most of the port numbers in step 2. If outbound HTTPS is blocked the scan still runs, using the cached catalog, or the baseline and installed-driver ports if nothing is cached.

Discovery scan intensity

How hard a scan hits the network is set by two controls in Discovery Settings: the scan depth, and the Gentle mode toggle.

	Quick	Standard	Thorough	With Gentle mode
Time cap	120 s	300 s	600 s	unchanged
Concurrent pings	50	50	50	10
Hosts port-scanned at once	24	16	12	3
TCP ports per host	~55	~55	~63	unchanged
NetBIOS sweep	no	yes	yes	unchanged
SNMP ENTITY-MIB detail	no	yes	yes	unchanged

Within a single host, port connections are started 20 ms apart, so one host under scan produces about 50 TCP SYNs per second. Multiplied by the concurrent-host figure above, peak SYN rate is roughly 1200/s at Quick depth, 800/s at Standard, 600/s at Thorough, and about 150/s with Gentle mode on.

Gentle mode lowers the rate, not the scope. The time caps are unchanged, so a gentle scan of a large range may not get all the way through it; when that happens the scan reports what it skipped rather than running longer.

How a discovery scan looks to network monitoring

Stated plainly, because it is better read here than met for the first time in an alert: several discovery steps match detection signatures that intrusion-detection systems and network access control platforms ship enabled. The traffic is benign, but reconnaissance is what discovery is, and that tooling matches on behavior rather than intent.

The steps most likely to raise an alert, in order:

The TCP port scan. Many ports across many hosts is a horizontal scan, and it is the most widely deployed signature there is.
The NetBIOS sweep. Querying UDP 137 across a subnet is the pattern the Windows network worms used, and it is watched closely for that reason. It runs at Standard and Thorough depth only.
The SNMP query. Sending the default community string public to every live host reads as credential testing at scale. Some sites also prohibit SNMP v2c outright, because it is unauthenticated and sent in the clear.
The ping sweep. Host enumeration, and the mildest of the four, but a full /20 is still several thousand echo requests.

The multicast and broadcast steps rarely trigger security alerts. mDNS and SSDP are what printers, phones and laptops on the same segment already do continuously. Where those steps cause trouble it is usually plumbing or policy rather than security: many sites suppress multicast between segments, and directed broadcast, which the driver-declared UDP probes depend on, is commonly disabled on campus and enterprise routers.

If a scan needs approval, the practical request is a scoped exception for one host on the AV VLAN during commissioning. To make that request smaller:

Name a specific subnet or range in Discovery Settings instead of letting the scan use every subnet it detects.
Use Quick depth, which drops the NetBIOS sweep entirely.
Turn SNMP off if the site has no SNMP-managed AV equipment.
Turn on Gentle mode.
Choose the AV adapter under Reach devices through in Settings > Network, so no scan traffic leaves the AV VLAN.

There is no setting that disables the ping sweep or the port scan on their own; between them, they are what a scan is. Where a site will not permit them at all, discovery can be skipped entirely: devices are added by IP address in the Programmer, which needs no scanning and is a normal way to build a project.

Device audit (on-demand only)

A device audit tests one device and its driver, and runs only when someone starts it in the Programmer. It is aimed at one address, and everything it sends goes to that address, except a reverse DNS lookup to your DNS server, its mDNS and SSDP queries, any multicast query an installed driver’s own discovery code sends, and one HTTPS request to raw.githubusercontent.com for the driver catalog. With an adapter chosen under Reach devices through in Settings > Network, it all leaves through that adapter.

Its network check sends, to the one device:

A ping, a reverse DNS lookup, and a NetBIOS name query (UDP 137).
A TCP connection to each port on the Thorough discovery list, started 50 ms apart. The Extended option adds every port from 1 to 1024.
On each open port, a connection that sends nothing and listens for a few seconds; on web ports, and on a port the device names in an SSDP or mDNS announcement, GET / (and a GET of the page it redirects to, only when that page is on the same address and port) and a TLS handshake for the certificate.
SNMP v2c reads (UDP 161), community public and any the integrator enters. The Extended option reads every value the device offers, up to a limit.
mDNS and SSDP queries on their multicast groups, and listening for mDNS, SSDP and AMX DDP announcements until the audit ends. Only the audited device’s announcements are kept.
The driver-declared TCP and UDP identification probes of the community catalog, sent to the device’s address only. Each sends its driver’s own query, one at a time on a port. A port that answers with a login prompt is sent only the probes that look for that prompt.
The identification checks of installed drivers that come with their own discovery code. One of those can send its own multicast query (a camera driver’s WS-Discovery), which reaches every device of that kind on the segment.

The driver test that follows connects to the device the way a configured device does, including a TCP connection to ports 443, 80 and 8080 to find its web page. During its power and cable tests, the device is pinged once a second.

To network monitoring this is a port scan of one host. It does not sweep the subnet.

Internet access (optional)

OpenAVC does not require internet access for normal operation. All device control, automation, and UI serving works entirely offline.

The following features require outbound internet access if enabled:

Destination	Port	Protocol	Purpose	Can be disabled?
`api.github.com`	443	HTTPS	Check for software updates	Yes (`updates.check_enabled: false`)
`github.com`, `raw.githubusercontent.com`	443	HTTPS	Download updates, community drivers and plugins, and the driver catalog a discovery scan refreshes	Yes (manual install alternative; a scan falls back to its cached catalog)
`cdn.jsdelivr.net`	443	HTTPS	IR code database search (only while searching in the IR Codes editor)	Yes (feature is only used on demand)
`cloud.openavc.com`	443	WSS	Cloud management platform (see below)	Yes (disabled by default)
`cloud.openavc.com`	443	HTTPS	Problem reports and device audit reports, only when someone presses Send to OpenAVC; the browser of the person pressing it may send it instead	Nothing is sent unless someone presses Send; with the host blocked, Download still works

Reports. Report a problem on a device’s page, and the Device Audit’s last step, offer Send to OpenAVC. One press sends one zip file to https://cloud.openavc.com/api/v1/reports, paired or not: the device’s settings with passwords hidden, its address, its recent messages and log lines, and its driver file, as the problem report and device audit pages describe. The OpenAVC host sends it first, through a proxy only when one is set in the service’s environment (HTTPS_PROXY). When that fails to connect, the browser of the person who pressed Send posts the same file, using its own proxy settings and certificate store. A paired system signs its request so the cloud can tell which system sent it. Nothing is sent on a schedule, on an error, or without that press.

If your network policy blocks outbound HTTPS, all local functionality is unaffected. Update checks will fail silently, and the cloud agent (if enabled) will retry with exponential backoff up to a 5-minute interval, then remain dormant until connectivity is restored.

Behind a proxy or a firewall that inspects encrypted traffic

Certificates. Every connection in the table above checks the server’s certificate against the operating system’s certificate store, then against the public certificate authorities OpenAVC ships with. A firewall that inspects encrypted traffic re-signs each site with your organization’s own certificate authority. When that authority is already installed in the computer’s store (Group Policy, MDM and most managed images do this), OpenAVC needs no setting. Otherwise, install it where the OpenAVC service reads it:

Install type	Where the certificate authority goes
Windows	Local Computer > Trusted Root Certification Authorities (the service runs as Local System, so a certificate installed for one user does not reach it)
macOS	The System keychain, trusted for SSL
Linux, Raspberry Pi	Copy the PEM file to `/usr/local/share/ca-certificates/<name>.crt`, run `sudo update-ca-certificates`, then `sudo systemctl restart openavc`
Docker	Mount the PEM file into the container and set `SSL_CERT_FILE` to its path (for example `SSL_CERT_FILE: /certs/inspection-ca.pem` under `environment:`). A file named in `SSL_CERT_FILE` (or a directory in `SSL_CERT_DIR`) is trusted in addition to the store on every install type.

When the authority is missing, Browse Drivers, Updates and installs say that the connection “was answered with a certificate this computer does not trust”. Device connections are not affected: AV equipment is checked against its own driver settings, as before.

Outbound proxy. Where the network reaches the internet only through a proxy, set HTTPS_PROXY (and HTTP_PROXY, usually the same value) in the OpenAVC service’s own environment, for example http://proxy.example.edu:8080, or http://user:password@proxy.example.edu:8080 for a proxy that asks for a sign-in. Automatic proxy configuration (a PAC file or WPAD) is not read, so name the proxy itself. An installed OpenAVC runs as a service with no signed-in user, so a proxy set in a person’s Windows or browser settings does not reach it.

What goes through the proxy: OpenAVC’s own internet connections in the table above, plus a driver for an internet service. Equipment at a private, loopback or link-local address, or with a .local or single-label name, is always reached directly, whatever the proxy settings say. A device addressed by a DNS name on your own network (display1.av.example.edu) needs that domain in NO_PROXY (for example NO_PROXY=.av.example.edu).

Install type	How to set it
Windows	In an administrator PowerShell, add the variable to the ones the service already has, then restart it (an update keeps a variable you add): `$key = 'HKLM:\SYSTEM\CurrentControlSet\Services\OpenAVC\Parameters'`, then `Set-ItemProperty $key AppEnvironmentExtra ((Get-ItemProperty $key).AppEnvironmentExtra + 'HTTPS_PROXY=http://proxy.example.edu:8080') -Type MultiString`, then `Restart-Service OpenAVC`. Do not use `nssm set OpenAVC AppEnvironmentExtra` with a single value: it replaces every variable the installer set.
Linux, Raspberry Pi	`sudo systemctl edit openavc`, add `[Service]` with `Environment=HTTPS_PROXY=http://proxy.example.edu:8080` and `Environment=HTTP_PROXY=http://proxy.example.edu:8080`, save, then `sudo systemctl restart openavc`. Updates keep the file, and an update’s own downloads use the same settings. Run the installer itself with the variables exported in your shell.
Docker	Under the service’s `environment:` in `docker-compose.yml`: `HTTPS_PROXY`, `HTTP_PROXY` and, for named equipment, `NO_PROXY`.
macOS	The proxy in System Settings > Network applies, because the app runs as the signed-in user.
Run by hand (`python -m openavc.main`)	The shell’s variables apply, and on Windows and macOS the signed-in user’s system proxy setting too.

Integrity of downloaded code

Community drivers and plugins are code. A Python driver is imported and run by the server, and a plugin runs in the server process with the capabilities its manifest declares. Installing one is a decision to trust it, the same as installing any software.

What OpenAVC checks when you install one:

Source. Downloads are pinned to the two official catalog repositories (open-avc/openavc-drivers, open-avc/openavc-plugins) over HTTPS. A URL pointing anywhere else is refused, including elsewhere on GitHub.
Contents. Both catalogs publish a SHA-256 for every file an install fetches. OpenAVC hashes what it received and compares before writing anything to disk. A file that doesn’t match, or that the catalog doesn’t publish, is refused and nothing is installed. For plugins, which install as a directory, a file listed in the catalog but not delivered is refused as well.

What that does not cover, stated plainly so you can weigh it: the hashes are published by the same repositories the files come from, so they are a check on the download, not proof of who wrote it. They would not detect a change made in the catalog repository itself, and no automated check can tell you that reviewed code is safe code. Community drivers and plugins are reviewed by maintainers before they are published; treat that review, and your own reading of a driver or plugin, as the real control. Platform updates are a separate chain with a stronger guarantee (see the release-signing section of the update documentation).

Installing from a file rather than the catalog (Upload Driver, or dropping a file into the driver folder) bypasses both checks by design, because you chose the file.

Inter-System Communication (ISC)

When deploying multiple OpenAVC instances (e.g., one per room), ISC allows them to share state and coordinate. ISC is off by default. It is enabled per project, so an instance sends and receives no ISC traffic at all until someone turns it on, and it can also be disabled instance-wide.

Parameter	Value
Discovery protocol	UDP broadcast on port 19872
Discovery range	Local broadcast domain only (255.255.255.255)
Peer communication	WebSocket on each instance’s HTTP port (path: `/isc/ws`)
Authentication	Optional shared key (configurable per project)
Beacon interval	Every 5 seconds
Auto-discovery scope	Same subnet/VLAN only
Cross-subnet support	Manual peer addressing (no broadcast required)
Inbound message limit	300 messages per minute per peer (the budget persists across reconnects)
Remote command limit	At most 8 peer-requested device commands execute at once (all peers combined)

The beacon follows Accept connections from (Settings > Network). With Any network, it is sent once on each network the host is connected to, from the host’s address on that network, so a peer on any of them can connect back. With one adapter chosen, it is sent only to that adapter’s own subnet, and with This computer only it is not sent.

To disable ISC entirely, set isc.enabled: false in system.json. No UDP traffic will be sent or received on port 19872.

For cross-VLAN multi-instance setups, disable auto-discovery and configure peer addresses manually. This requires only TCP access to each instance’s HTTP port (default 8080), with no UDP broadcast traffic.

Security model. ISC authenticates peers with a shared key, not with TLS. Every message is signed with an HMAC over a per-connection challenge, and the handshake is mutual: each instance proves it holds the isc.auth_key to the other before either acts on the other’s shared state or remote commands, so a peer that lacks the key cannot join the mesh, read shared state, or issue a remote command. When the instances also run HTTPS, the ISC link is encrypted, but its TLS is encryption-only. Peers use each other’s self-signed LAN certificates without certificate-authority verification (private-LAN instances have no public CA to validate against), so the certificate does not identify the peer. The shared key does. The practical consequence is the standard AV-VLAN posture: keep multi-instance hosts on a trusted control network and set a distinct, strong isc.auth_key. The shared key stops any outsider, but it is the whole of the trust model, so the segment it runs on must be trusted. The key is kept on the system it was entered on, not in the project, so a backup, an export, a template or a copy of the project in the cloud holds a placeholder in its place; the Inter-System page shows it only when Show is pressed, which needs the Programmer sign-in. It is shown as *** in the server’s logs, in problem reports and in device audit reports.

Authentication and Access Control

Web interface and API

Admin access is secure by default on every shipped deployment. An installed instance (Windows, macOS, Linux, Docker, Raspberry Pi) refuses the Programmer and the mutating/admin API until an admin password is set on first open, returning HTTP 401 until then, while the room panel page and the health/status endpoints stay reachable (a panel connects only once approved). See Who can access the web interface above for the full model. (A from-source developer checkout is the one exception: it stays open on localhost for frictionless development. Force either posture explicitly with OPENAVC_ALLOW_ANONYMOUS.)

The admin credential is one of the following, set during first-run setup or provisioned ahead of time. You do not need to set both:

Method	Configuration	When to use
HTTP Basic (username + password)	`OPENAVC_PROGRAMMER_USERNAME` and `OPENAVC_PROGRAMMER_PASSWORD` env vars, or `auth.programmer_username` and `auth.programmer_password` in `system.json`	The standard admin login, and what the first-run setup screen creates. The browser prompts for both username and password. This is for humans logging in via a browser.
API key (token)	`OPENAVC_API_KEY` env var or `auth.api_key` in `system.json`	Set this if you have third-party integrations (control scripts, middleware, or external software) that connect to the REST API or WebSocket. Provide the key via the `X-API-Key` header. Not needed unless you are building custom integrations. Set a programmer password alongside it: a key on its own cannot open the Programmer in a browser. Settings > Access generates one on request; copy it before saving, because it is stored as a salted hash and cannot be read back. A key written into `system.json` by hand still works and is converted on the next start.

| Panel approval (cookie) | Issued by the server when a panel is approved; held by the device’s browser or the OpenAVC Panel app | Not a credential a person holds or types. Each approved panel gets a random 256-bit secret, stored on the host as a salted hash in panel_devices.json and sent back by the device as an HttpOnly cookie on every panel request. It admits the panel’s own connection and nothing else: it opens no configuration endpoint and cannot be used from the Programmer. Revoke it from the Dashboard. |

The username/password is for humans (browser login), the API key is for machines (HTTP headers). If both are set, either credential is accepted.

An API key is not a substitute for the password. It is only accepted in the X-API-Key header, which a browser cannot send when you open a page, so a system with a key and no password serves integrations normally and cannot be opened in any browser. Settings refuses to save a key unless a password is set as well. A key supplied through OPENAVC_API_KEY or written into system.json by hand is not stopped that way; the server writes a warning to the log at startup instead.

If a programmer password is set without a username, any username entered at the browser prompt is accepted as long as the password matches. Setting a username as well is recommended.

In all cases:

The Panel page (end-user touch interface) is reachable without credentials; a panel connects once it is approved, or from the host’s own screen, through OpenAVC Cloud, or when Panel access is set to Anyone on the network
The Programmer (configuration interface) requires the admin credential
All configuration-changing API endpoints require the credential
The code-writing endpoints (Python drivers, scripts) require a set credential even on a checkout otherwise configured for open access — an unclaimed instance refuses them outright
Username and password comparisons both use constant-time algorithms to prevent timing attacks

Browser sessions never retain the password. When someone signs in to the Programmer, the browser exchanges the password for a short-lived random session token (POST /api/auth/session) and keeps only that token, scoped to the browser tab. The password itself is sent once, over the login request, and is not stored client-side in any form. Session tokens are held in server memory only (never written to disk), expire after 12 hours of inactivity (each authenticated request extends them), and are all invalidated immediately when the admin password changes or the server restarts. Signing out revokes the token server-side. Basic and API-key authentication are unaffected; they remain available for scripted and third-party clients on every protected endpoint.

Opening an instance is a full-trust decision. Setting OPENAVC_ALLOW_ANONYMOUS=true (or auth.allow_anonymous: true) removes the credential gate entirely: everyone who can reach the instance has complete admin control. That is not limited to reading configuration. An anonymous caller on an open instance can set or overwrite the admin password (locking out the owner, and the change survives a restart), change who can connect, or turn TLS off, because those are ordinary configuration writes and there is no credential to tell the owner apart from a stranger. Open an instance only where reachability is already restricted out of band (This computer only under Accept connections from, or an authenticating reverse proxy in front of it), and treat the network it listens on as fully trusted. The shipped default never opens the box this way: packaged installs are claimed on first run (see Who can access the web interface), so this posture applies only when an operator deliberately turns anonymous access on.

TLS/HTTPS

OpenAVC defaults to plain HTTP because most deployments live on an isolated AV VLAN. HTTPS is available as a built-in opt-in via Settings > Security in the Programmer IDE, or by setting OPENAVC_TLS_ENABLED=true (or tls.enabled: true in system.json) and restarting the server.

When enabled, the server runs the HTTPS listener on port 8443 with an enforced TLS 1.2 floor — only TLS 1.2 and 1.3 are negotiated, and TLS 1.0/1.1 are refused — using RSA-2048 server keys and a modern ECDHE (GCM / CHACHA20) cipher suite. It keeps a tiny HTTP listener on port 8080 that redirects to the HTTPS URL (temporary 302/307, so no browser caches a permanent redirect that would outlive a later decision to turn HTTPS back off) so existing clients keep working.

Three cert modes are supported:

Auto-generated self-signed cert. Built-in CA and server cert under {data_dir}/tls/, 10-year validity, SANs covering the OS hostname, its .local mDNS form, and every local IPv4. The CA is downloadable at GET /api/certificate for install on panel devices.
User-provided cert. Point tls.cert_file / tls.key_file at PEM files signed by your internal CA. No browser warnings if the CA is already trusted by your fleet.
Cloud-issued trusted cert. Systems paired with OpenAVC Cloud can serve a publicly trusted certificate with no client-side setup at all. Details in the next section.

A reverse proxy in front of OpenAVC (nginx, Caddy, Apache, HAProxy) is still fully supported — leave OpenAVC’s TLS off and let the proxy terminate.

Trusted certificates (cloud-issued, optional)

Systems paired with OpenAVC Cloud can serve a publicly trusted HTTPS certificate instead of the self-signed one. Browsers on the LAN then get a normal padlock, with no warnings to click through and no CA to roll out to guest or BYOD devices. It is a one-click opt-in under Settings > Security, and one click turns it back off.

How it works:

The cloud assigns the system a random hostname label under the public zone i.openavc.net and obtains a wildcard certificate for it from Let’s Encrypt, using a DNS challenge handled entirely by the cloud. The OpenAVC host needs no inbound connectivity and no new outbound rules; issuance and renewal ride the existing cloud connection (cloud.openavc.com, port 443).
The private key is generated on the OpenAVC host and never leaves it. The cloud receives a certificate signing request and returns the signed certificate.
Addresses encode the system’s LAN IP in the hostname: https://192-168-1-20.<label>.i.openavc.net:8443/ resolves to 192.168.1.20. While the feature is active, the HTTP listener on port 8080 sends clients to the certified URL automatically, so users still just type the plain IP address.
Whether the certified hostname resolves can only be determined on the client device, so browser navigations get a brief in-page reachability check before being forwarded: if the certified origin answers, the browser lands on the padlocked page; if the name cannot be resolved or reached (blocked resolver, no internet), the browser lands on the bare-IP HTTPS URL with the standard self-signed warning instead of a dead error page. The check adds no delay when the name resolves, and at most a few seconds when it does not. Non-browser clients (API integrations, scripts, monitoring) always receive a plain 302/307 redirect.
Renewal is automatic. The renewed certificate is served immediately, with no restart and no dropped connections.
Bare-IP HTTPS (https://<ip>:8443/) continues to serve the self-signed certificate, so devices that already trust the local CA keep working unchanged.

Notes for network administrators:

Client devices resolve the certified hostname through normal public DNS, and the answer points at a private (RFC 1918) address. Only the name lookup leaves the network; the actual traffic to the OpenAVC host stays on the LAN.
DNS rebind protection. Some routers and firewalls refuse public DNS names that resolve to private addresses. The symptom: browsers on the LAN land on the bare-IP HTTPS URL with the self-signed certificate warning instead of the padlocked certified page (the reachability check above falls back automatically, so nothing breaks — but the padlock is lost). To get the certified page, add an exception for the zone. On dnsmasq-based routers (including OpenWrt): rebind-domain-ok=/i.openavc.net/. On Unbound-based firewalls (OPNsense, pfSense): private-domain: "i.openavc.net". On an AVM FRITZ!Box: add i.openavc.net to the DNS rebind protection exceptions. For other equipment, search its documentation for “DNS rebind” exceptions.
Like every publicly trusted certificate, issuance is recorded in public Certificate Transparency logs. The logged name contains only the random system label (for example *.a3f9c2e81b4d0f37.i.openavc.net). Your internal IP addresses, hostnames, and organization name do not appear in the certificate.
If the site loses internet access, devices that have already resolved the name keep working for the DNS TTL (24 hours). Browsers on new devices fall back to the bare-IP URL automatically (standard self-signed warning); control of the AV equipment is never affected.
Turning the feature off reverts the redirect immediately and revokes the hostname on the cloud side; clients with cached DNS answers lose resolution as their cache expires.

Rate limiting

Rate limiting is enabled by default on the HTTP REST API for remote clients. Requests from localhost (127.0.0.1, ::1) are exempt, since the primary use case is a single user on the same machine. Remote clients are subject to the limits below. A touch panel’s control traffic runs over WebSocket and is not subject to these tiers, though the images, custom controls and theme it loads over HTTP are (see the exempt row below). These tiers also do not apply to the command pipeline between the server and AV hardware — commands are sent to devices the instant they are received. The WebSocket channel has its own guards: each connection is limited to 200 messages per second, and the server accepts at most 100 simultaneous WebSocket connections.

Tier	Limit	Applies to
Open	120 requests/min per IP	Status, health-check, setup-state, and CA-certificate download endpoints, and the panel approval check-in (a panel waiting for approval asks every 3 seconds). These are the ones that answer without a credential.
Standard	60 requests/min per IP	General API operations (including library/catalog reads)
Control	120 requests/min per IP	Commissioning operations: anything that changes a device, driver, or discovery scan, plus project save. That covers device commands and tests, raw sends, IR emit, device settings and lifecycle, driver install/upload/edit, and inter-system commands. These all require authentication; the higher budget keeps normal setup work (command bursts, volume ramps) from being throttled.
Strict	10 requests/min per IP	Security-sensitive operations: sign-in, cloud pairing, backup restore, panel lock PIN attempts, and approving a panel with the admin password typed on the panel
Media	3000 requests/min per IP	Video streams served by a plugin, such as a camera or a switcher output shown on a panel. A single video tile asks for a small file several times a second, far more often than anything else, so it gets a budget of its own. A plugin receives this only for the specific routes that carry video.
Exempt	no limit	Inbound device push (`/api/push/`), and the files a touch panel loads to draw itself: project images and audio, a project’s custom controls, and plugin panel files. These are reads of static files that require no credential. A wall panel loading a large layout can request several dozen in a few seconds, and a throttled response there would leave part of the panel blank. Uploading, replacing or deleting any of these files is a separate authenticated operation and is limited normally.

If a space uses remote viewing through OpenAVC Cloud, note that everything arriving over the cloud connection is counted together rather than per viewer. Around seventeen people watching video remotely at the same time will reach the media limit. Panels in the space are unaffected, because their video never travels through the cloud.

Failed authentication attempts are throttled at the strict (10/min) rate on every endpoint, not just strict-tier ones, so credential probing is capped wherever it is aimed. Successful control traffic is tracked separately: volume ramps, rapid command sequences, and multi-room control from the touch panel are unaffected by the brute-force limit.

Data Storage and Privacy

What is stored locally

Data	Location	Sensitive?
Project configuration (devices, macros, UI layouts)	`project.avc` (JSON)	Low to medium. Contains device IP addresses and connection parameters. Logins are not in it: each holds a placeholder that names the saved login. Until a device’s driver or a plugin is installed, some of its logins can stay in the project. On 0.40.0, so does a stream key, password or PIN typed into a macro step or a control’s action.
Saved logins	`device_logins.json`, with its key in `device_logins.key`	High. Device and plugin logins, the inter-system key, and (after 0.40.0) any stream key, password or PIN saved in a macro step or a control’s action, encrypted with the key beside it. On Linux and macOS both files are readable only by the account the service runs as; on Windows the data folder is restricted as for `system.json`.
System configuration	`system.json`	Medium. The admin password and API key are stored as salted hashes, not as typed. The cloud key is stored as-is, because the instance has to present it. On Linux and macOS the file is readable only by the account the service runs as. On Windows the installer restricts the whole data folder to the service and administrators at every install and update; see Protect the data folder.
Persistent variables	`state.json`	Low. Key-value pairs for automation state.
Approved panels	`panel_devices.json`	Medium. One record per approved panel: its name, the kind of device, its address, when it was approved and by whom, and a salted hash of its secret, never the secret itself. Readable only by the account the service runs as; carried by the pre-update backup. Devices still waiting, and denied ones, are held in memory only.
Application logs	`logs/` directory	Low. Standard application logs at INFO level. Device protocol traffic (which can include device credentials) is never written to disk — it is held in a fixed-size in-memory buffer, visible only in the live log view behind an authenticated Programmer login. Configurable rotation (default: 50 MB, 5 files).
Cloud pairing data	`cloud.json`	High. Contains system key for cloud authentication. Protect with filesystem permissions.

What is NOT stored

No user credentials for the web interface are stored in a database (the password is a single config value)
No personal data, user accounts, or usage analytics
No device credentials outside the saved logins file, apart from those of a driver or plugin not yet installed and, on 0.40.0, a stream key, password or PIN typed into a macro step or a control’s action. A device or plugin login is never sent to a touch panel or the Programmer.
No data is written outside the application’s data directory

Filesystem permissions

On Linux the service runs as its own unprivileged openavc account, and in Docker as an unprivileged user. The Windows service runs as Local System and the macOS service as root. On Windows the installer restricts the data directory to the service and administrators, leaving one status folder that every local account can read: it holds the ports the server listens on and the reason it last failed to start, for the tray app. The application reads and writes only within its own data directory:

Platform	Default data path
Windows	`C:\ProgramData\OpenAVC\`
Linux	`/var/lib/openavc/`
Docker	`/data/` (mounted volume)
Development	`./data/` (relative to repo)

Cloud Platform (Optional)

The OpenAVC Cloud platform provides remote monitoring, fleet management, and AI-assisted configuration for organizations managing multiple AV spaces. Cloud connectivity is entirely optional and disabled by default. All local functionality works without it.

Connection details

Parameter	Value
Endpoint	`wss://cloud.openavc.com/agent/v1`
Protocol	WebSocket over TLS 1.2+
Direction	Outbound only. The device initiates the connection. No inbound ports required.
Port	443 (standard HTTPS)
Certificate validation	Required. Standard CA-signed certificate, checked against the operating system’s certificate store (see Behind a proxy or a firewall that inspects encrypted traffic).
Proxy	`HTTPS_PROXY` in the service’s environment, when the network requires one.
Keepalive	Server-initiated ping/pong over the WebSocket
Reconnection	Exponential backoff: 5s, 10s, 20s, 40s … up to 5 minutes

Authentication

The cloud connection uses a multi-step challenge-response handshake. After pairing, the system’s secret key never crosses the network.

Device sends a hello message identifying itself (system ID, software version, OS, hardware, deployment type)
Cloud responds with a random 32-byte challenge nonce
Device computes an HMAC-SHA256 proof using a locally-derived authentication key (HKDF-SHA256 from the system key) and sends it back
Cloud derives the same key from its stored, encrypted copy of the system key and verifies the proof
On success, cloud issues a session with a unique signing key

All subsequent messages are signed with HMAC-SHA256 using the session-specific signing key. Messages with invalid or missing signatures are rejected.

Key derivation: HKDF-SHA256 (RFC 5869), stdlib-only implementation (no external crypto libraries) Message signing: HMAC-SHA256 with constant-time verification System key: 64 bytes, cryptographically random, made by the cloud when the system is paired and sent to it once, over TLS, in the answer to the pairing request. The cloud stores its SHA-256 hash and an encrypted copy, which it needs to check each handshake.

What data is sent to the cloud

When cloud is enabled, the agent streams a small amount of telemetry automatically:

Data	Frequency	Content
Heartbeat	Every 30 seconds	CPU %, memory %, disk %, uptime, device count, connected device count, error count, WebSocket client count, temperature (if a sensor is available)
State changes	Batched (2 s for active device state; slower tiers for lower-priority keys)	Device, variable, system, UI, and plugin state key-value changes (e.g., `device.projector1.power: "on"`). Internal cloud/ISC keys are excluded. An address that carries a login, such as a camera stream address with Login in Stream Address turned on, is sent with its password shown as `***`.
Alerts	As they occur (throttled)	Alert ID, severity, category, and message, plus the rule and device that fired it and the state key/value that tripped the threshold (an address’s password shown as `***`, as above)

This telemetry is runtime state and metrics only. It never contains the project file, device connection settings, or any credential.

Project copies. The cloud also asks a paired system for its project file: once a day for Project Backups, before each change pushed from the portal, when someone presses Back up now, captures a template or uses the AI assistant, and during a support session the customer grants. The AI assistant can also read the device and command list and recent log lines. The project file holds device names, IP addresses and connection settings. On OpenAVC 0.40.0 and later it holds no device logins: they stay in an encrypted file on the system, and the copy holds a placeholder in place of each one. A system on an earlier version includes them. One exception on 0.40.0: a stream key, password or PIN typed into a macro step or a control’s action is saved in the project, so the copy includes it. The cloud stores every copy encrypted and deletes older ones on a schedule (OpenAVC Cloud Security and Data Handling). If your policy is that device configuration must never leave the site, do not pair the instance with the cloud.

Never sent, under any circumstance: the system’s cloud key or derived signing keys, the web-interface admin password or API key, device logins saved on the system (OpenAVC 0.40.0 and later), and data from other systems on the network.

What the cloud can do

When an instance is paired, the cloud console can send it the following:

Command	Description
Device command	Execute a device command already defined in the local project (e.g., “turn on projector”)
Diagnostic	Run a network diagnostic from the device’s perspective: ping, TCP port check, DNS lookup, or a port scan of a host. A port a connected project device is using is reported open and in use by that device, without connecting to it
Software update	Trigger a software update check and install. Only a release signed by OpenAVC is installed: a file whose signature does not check out is refused before it runs (System Updates)
Panel software update	Appliance hardware only: download a newer release of the panel’s own software over HTTPS, checked against its checksum, to where the panel installs it from. The panel installs it itself, and only a release signed with the panel’s own key and newer than the one it has
Restart	Restart the OpenAVC service
Configuration push	Replace or update the project file on the device (a backup is taken first, then the engine reloads)
Alert rules	Push alert rule definitions to be evaluated locally
Remote access tunnel	Open a proxied connection to the local web interface (see below)
AI-assisted management	Run the same management actions an administrator has in the Programmer — read project state, change state and send device commands, start a discovery scan, install drivers and plugins, and create or edit drivers and scripts, which run on the host. It never reads a device login saved on the system and cannot enter or change one: logins are entered on the device’s page in the Programmer

This is an administrator-equivalent management plane. When you pair an instance, the cloud can do what a local administrator can do at the Programmer, reached remotely — including pushing configuration and scripts that execute on the host. It does not exceed local-admin scope: there is no general shell beyond these defined actions, and no command in the table above reconfigures the host operating system or its network settings. The remote access tunnel is the one entry that needs reading differently, because what travels through it is a person’s own browser session rather than a cloud command. Its scope is set out below. Because this is full administrative control, pairing is opt-in and off by default (see Disabling cloud entirely, below), each instance pairs to a single account, and every message is mutually authenticated (see the handshake under Authentication above). If your security model does not allow an external management plane with this authority over the host, leave cloud disabled — every capability here exists only on a paired instance.

Remote access tunnels

The cloud platform can open a remote access tunnel to the device’s web interface. This works by proxying HTTP traffic through a secondary WebSocket connection, similar to how tools like ngrok or Cloudflare Tunnel work.

The device initiates the tunnel connection (outbound to cloud on port 443)
No inbound ports are opened on the device or the network
Tunnel connections are authenticated with a per-tunnel token
Tunnels are closed when the remote session ends or when the device disconnects
One upload through a tunnel can be at most 12 MB. A larger file is refused with a message saying to upload it from a computer on the system’s own network

What a tunnel grants. The tunnel is a transport, not a set of permissions. A request arriving through it is treated as a remote request in every respect: it must present the Programmer credential, it is rate-limited, and its failed logins count toward the brute-force lockout. The proxy delivers traffic to the device’s own loopback interface, and that fact earns the caller nothing. Surfaces the device reserves for its own screen, host network configuration and the network identifiers on the setup page, are reached only with the Programmer credential when the request comes through a tunnel. The one thing a tunnel does grant is the room panel: Remote Panel needs no panel approval, because the cloud has already decided who may open it, and the instance issues no panel cookie to a tunnelled request.

So the reach of a tunnel is the reach of the Programmer credential, no more and no less: whoever holds it can do through the tunnel exactly what they could do from a browser on the same LAN. On deployments that expose host network settings (Linux and Raspberry Pi with NetworkManager) that does include changing the device’s IP, WiFi, and hostname, which is the one capability the cloud command list above does not carry. If you want no remote path to those settings at all, the controls are the same ones that govern the rest of this plane: leave cloud disabled, or keep the instance paired but treat the Programmer credential as the boundary it is.

The one exception, and how to see it. A tunnel opened under an OpenAVC support session does not ask for the Programmer credential. Nobody at OpenAVC has your password and we will never ask you to send it, so a support session carries its own authorization instead: a per-tunnel secret the device itself generates, valid only while that tunnel is open.

Such a session exists only when someone on your account creates it. It is granted from your own cloud portal, on one named system, on a specific support request, for one, four or twenty-four hours. There is no standing grant, no account-wide grant, and no way for OpenAVC to open one without that action. While it is live you can see it, and you can end it at once; ending it closes any session already open rather than waiting for the clock. Every action taken under it is recorded against the named staff member and shown back to you in the portal. It expires on its own, and a further visit needs a further grant.

Within the session, staff reach what the Programmer reaches. They do not reach the surfaces the device reserves for its own screen: host network configuration still requires the Programmer credential, exactly as it does for any other tunnelled request.

If your security model does not permit this at all, the control is the same as for the rest of the management plane: leave cloud disabled, or stay paired and never grant a support session. Nothing in the product creates one on your behalf.

The second exception: password-free programming. An organization can choose, in the cloud portal, to let its own signed-in people open the Programmer for its own systems without typing each system’s password. It is off unless someone turns it on, and on an integrator-managed organization both the integrator and the organization have to turn it on before it does anything. Turning either switch off ends the sessions already running on it.

It works the same way a support session does: the device generates a per-tunnel secret, valid only while that tunnel is open, and accepts it in place of the Programmer credential. The same limit applies. Host network configuration is not reachable in such a session — changing this device’s own address, WiFi or hostname asks for the device’s password from any remote session, or is done on the device’s own screen.

If you do not want this available at all, leave it switched off. Nothing turns it on by default and nothing suggests it during setup.

Disabling cloud entirely

Cloud is disabled by default. To confirm it is disabled, verify that cloud.enabled is false in system.json (or that the OPENAVC_CLOUD_ENABLED environment variable is not set to true). When disabled, no cloud-related code runs and no outbound connections to cloud.openavc.com are made, apart from a report someone sends with Send to OpenAVC (see Internet access).

Firewall Rule Summary

Minimum (single room, no internet)

Rule	Direction	Source	Destination	Port	Protocol
Web UI access	Inbound	Touch panels / browsers	OpenAVC host	8080/tcp	HTTP
Web UI access (TLS)	Inbound	Touch panels / browsers	OpenAVC host	8443/tcp	HTTPS (only when enabled)
Short-URL redirect	Inbound	Browsers	OpenAVC host	80/tcp	HTTP redirect only (only when enabled)
AV device control	Outbound	OpenAVC host	AV device IPs	Per device (see table above)	TCP

Typical (with updates and discovery)

Add to the minimum rules:

Rule	Direction	Source	Destination	Port	Protocol
ICMP (discovery)	Outbound	OpenAVC host	Local subnet	ICMP	Echo request
TCP port scan (discovery)	Outbound	OpenAVC host	Responding hosts on local subnet	~55 ports per host	TCP SYN. The baseline 22, 23, 80, 443, 8080 plus every port declared by the installed drivers and by the community driver catalog; Thorough depth adds eight more
NetBIOS (discovery)	Outbound	OpenAVC host	Local subnet	137/udp	NetBIOS name query (Standard / Thorough only)
SNMP (discovery)	Outbound	OpenAVC host	Local subnet	161/udp	SNMP v2c
mDNS (discovery)	Outbound + Inbound	OpenAVC host	224.0.0.251	5353/udp	mDNS
SSDP (discovery)	Outbound + Inbound	OpenAVC host	239.255.255.250	1900/udp	SSDP
AMX DDP (discovery)	Inbound	239.255.250.250	OpenAVC host	9131/udp	Passive listen
Camera WS-Discovery	Outbound + Inbound	OpenAVC host	Subnet broadcast	3702/udp	Opens when an installed camera driver declares a `udp_probe:` on this port
PJLink Class 2 SRCH	Outbound + Inbound	OpenAVC host	Subnet broadcast	4352/udp	Opens when the `pjlink_class1` driver is installed
PJLink Class 1 INFO	Outbound	OpenAVC host	Class 2 responders	4352/tcp	Per-responder follow-up from the PJLink driver
Crestron CIP probe	Outbound + Inbound	OpenAVC host	Subnet broadcast	41794/udp	Opens when the `utility/crestron_cip` driver is installed
Driver-declared UDP probes	Outbound + Inbound	OpenAVC host	Subnet broadcast	Vendor-specific	If installed drivers declare a `udp_probe:` or sibling `_discovery.py` Python companion
Driver-declared TCP probes	Outbound	OpenAVC host	Live hosts with port open	Vendor-specific	If installed drivers declare a `tcp_probe:`
Device push notifications (multicast)	Inbound	Device multicast group	OpenAVC host	Device-specific /udp	Only for drivers that declare a multicast push channel (e.g. 239.0.0.100:17000); receive-only while the device is connected
Device push notifications (dial-back)	Inbound	Device IPs	OpenAVC host	Device-specific /tcp	Only for drivers that declare a TCP dial-back push channel (e.g. Panasonic PTZ cameras, port 31004); receive-only, connections accepted from registered device addresses only
Device push notifications (event stream)	Outbound	OpenAVC host	Device	Device’s API port	Drivers that declare an SSE push channel hold the device’s existing HTTP(S) control connection open — no new port, no inbound listener
Device push notifications (HTTP callback)	Inbound	AV device IPs	OpenAVC host	8080/tcp (the web port)	Drivers that declare an HTTP-listener push channel register a callback URL on the device; the device posts to `/api/push/` on the existing web port — no new port, accepted only from the device’s own address
Update checks	Outbound	OpenAVC host	api.github.com	443/tcp	HTTPS
Driver catalog refresh (discovery)	Outbound	OpenAVC host	raw.githubusercontent.com	443/tcp	HTTPS, once per scan; falls back to the cached catalog when blocked
Problem and audit reports	Outbound	OpenAVC host, or the browser of the person sending	cloud.openavc.com	443/tcp	HTTPS, only when someone presses Send to OpenAVC

With media plugins (Video Panel / Present)

Add for the optional media plugins actually installed:

Rule	Direction	Source	Destination	Port	Protocol
Video Panel WebRTC media	Inbound	Panel devices	OpenAVC host	8189/udp	WebRTC (Video Panel plugin)
Present WebRTC media	Inbound	Presenter laptops + display devices	OpenAVC host	8190/udp	WebRTC (Present plugin)
Present stream display (RTSP)	Inbound	Hardware decoders	OpenAVC host	8554/tcp	RTSP, TCP-interleaved (Present plugin)
Present stream display (SRT)	Inbound	Hardware decoders	OpenAVC host	8899/udp	SRT (Present plugin)

With cloud platform

Add to the typical rules:

Rule	Direction	Source	Destination	Port	Protocol
Cloud connection	Outbound	OpenAVC host	cloud.openavc.com	443/tcp	WSS

Multi-instance (ISC)

Add if running multiple OpenAVC instances that need to coordinate:

Rule	Direction	Source	Destination	Port	Protocol
ISC discovery	Both	OpenAVC hosts	Broadcast (255.255.255.255)	19872/udp	UDP
ISC peer WebSocket	Both	OpenAVC hosts	Other OpenAVC hosts	8080/tcp	HTTP (WS)

VLAN and Network Segmentation Recommendations

OpenAVC is designed to work well on segmented networks. A common and recommended topology for managed environments:

AV Control VLAN - Contains the OpenAVC host and all AV equipment (projectors, DSPs, switchers, cameras). This VLAN can be fully isolated from the corporate network. If OpenAVC and all controlled devices are on this VLAN, no cross-VLAN rules are needed for device control.

User/Presentation VLAN - If users need to access the touch panel UI from devices on a different VLAN (tablets, room PCs), allow inbound TCP on the OpenAVC host’s HTTP port (8080 by default) from that VLAN.

Internet/WAN - Only required for update checks and cloud connectivity. Can be fully blocked if these features are not needed.

To restrict the web ports to these VLANs at the host itself, use the per-platform commands in the Hardened Deployment Profile.

OpenAVC does not use UPnP port mapping, NAT traversal, or any technique that modifies network infrastructure. It operates strictly as a client or server on the ports listed in this document.

Security Posture Summary

Aspect	Default	Notes
Inbound ports	HTTP 8080 (+ UDP 5353 for panel auto-discovery)	Configurable. Adds 8443 when HTTPS is enabled.
Who can connect	Installed systems: any network; source run: this computer only	Settings > Network > Accept connections from: any network, one adapter, or this computer only.
Admin authentication	Secure by default	Shipped deployments refuse the Programmer and admin API until an admin password is set. A source checkout is open on localhost for development.
Panel access	Approved panels only on a fresh install; a system updated from a version without the setting stays Anyone on the network until switched	A new tablet or browser waits until an administrator approves it once; the host’s own screen and Remote Panel through OpenAVC Cloud need no approval. Can be set either way in Settings > Access.
TLS	Off, opt-in built-in	Enable via Settings > Security. TLS 1.2/1.3 only (1.0/1.1 refused). Auto-generated self-signed cert, supply your own, or a cloud-issued publicly trusted cert for paired systems. Reverse-proxy TLS also supported.
Outbound internet	Not required	Only for optional updates, cloud, and reports someone sends
Cloud connectivity	Disabled by default	Opt-in. When paired, it is an administrator-equivalent management plane (see Cloud Platform above).
OpenAVC staff access	None, ever, until granted	Nobody at OpenAVC can reach a paired system by default. Access comes only from a support session your own account creates: one named system, one support request, one to twenty-four hours, visible while live, revocable instantly, and every action recorded against the named staff member in your portal. See Remote access tunnels.
Privileged access	None on Linux and Docker	Linux runs the service as the unprivileged `openavc` account, Docker as an unprivileged user. The Windows service runs as Local System and the macOS service as root; on Windows the installer restricts the data folder to the service and administrators.
External dependencies at runtime	None	No external database, message broker, or third-party service required
Discovery scans	On-demand only	Never automatic. Started by an integrator (or an authenticated cloud request). A scan performs a ping sweep, a ~55-port TCP scan of responding hosts, SNMP and NetBIOS queries, multicast queries and directed-broadcast probes. See Discovery scan intensity and How a discovery scan looks to network monitoring.
Device audits	On-demand only	Started by an integrator in the Programmer, aimed at one device: a port scan of that host, its web pages, SNMP, the drivers’ identification probes, then a driver test against it. See Device audit.
Background multicast/broadcast	mDNS advertising only	mDNS on 5353, on by default, re-announcing every 60 s (disable with `discovery.advertise: false`). ISC UDP broadcast on 19872 is off unless ISC is enabled in the project.
Data exfiltration risk	Low	No data leaves the site unless cloud is explicitly paired, or someone presses Send to OpenAVC on one report about one device. When paired: automatic telemetry, a daily project copy and on-demand pulls, all itemized above. Device logins stay on the system (OpenAVC 0.40.0 and later).

Quick-Start: Evaluating OpenAVC on Your Network

You can evaluate OpenAVC on a spare Windows or Linux machine in a few minutes, with no AV hardware. Install it by whichever method suits you — Windows installer, Linux install.sh, Docker, or from source — following the Getting Started guide, then open http://localhost:8080/programmer.

Two things matter for a network review:

Zero traffic until you connect devices. A fresh install generates no network traffic of its own. You can explore the full interface and test against the built-in device simulator entirely offline.
Reachability is explicit. A from-source run accepts connections from this computer only. The packaged installers accept them from any network so panels can reach the host (Settings > Network > Accept connections from narrows it), and require you to set an admin password the first time you open the Programmer.

To point it at real equipment, add devices by IP in the Programmer; OpenAVC then opens outbound connections to just those devices (no inbound change needed, since device control is outbound).

Frequently Asked Questions

Does it need Active Directory or LDAP integration? No. OpenAVC uses a simple password for the configuration interface and optional API keys for automation. There is no user database or directory integration.

Does it phone home? Not by default. Update checks (to GitHub’s public API) can be enabled or disabled. Cloud connectivity is a separate opt-in feature that is off by default.

Does it need a database server? No. All data is stored in JSON files on the local filesystem. There is no PostgreSQL, MySQL, Redis, or any external data store.

Does it modify the host system? Minimally. The Windows installer creates a Windows service (via NSSM), restricts the data folder (C:\ProgramData\OpenAVC) to the service and administrators, and adds one program-scoped Windows Firewall rule for the OpenAVC server executable — inbound traffic is accepted only on ports the server is actually listening on (the HTTP port, plus HTTPS and the port-80 short-URL listener when those features are enabled). The rule allows every address until you limit it to your networks, as described in the Hardened Deployment Profile; from OpenAVC 0.37.0, updates keep the addresses you set. The server adds one more rule, named like OpenAVC plugin UDP 8189, for a plugin that needs a port of its own, such as the Video Panel. The server removes it when no running plugin needs the port, and uninstalling OpenAVC removes any that are left. The Linux install script creates a systemd service and an openavc user, and a root helper syncs ufw/firewalld (when active) with the configured listener ports at each service start — ports it opened are closed again when the feature is disabled, and rules added by an administrator are never touched. Docker and from-source installations make no system modifications. In all cases, application data is confined to a single data directory.

What if we block all outbound internet? OpenAVC will work normally. Update checks will fail silently and cloud features (if configured) will be dormant. All AV control, automation, and UI functionality is fully local.

Is the source code available for review? Yes. OpenAVC is MIT-licensed open source. The full source code, including the cloud agent that handles remote connectivity, is available at github.com/open-avc/openavc.

Document version: 1.10. For the latest version, see docs.openavc.com.