Audio Devices Overview

GCXONE supports audio in two independent ways:

• Genesis Audio — a standalone speaker/intercom you add to a site as its own device. It works the same way no matter which camera brand or VMS the site runs.
• Camera-embedded audio — the microphone and/or speaker already built into a camera or NVR, where the hardware has one. No separate device is added — it's a property of the camera itself.

Which one a customer should use, and whether the camera's own audio will actually work, depends heavily on their camera brand and on whether GCXONE is talking to the site over the cloud or over Local Mode. That's the part that isn't obvious, and it's the point of this page.

The business logic, in plain terms

Think of it as two separate questions for any given site:

1. Does the customer need to hear/speak through a camera that's already there, or are we adding a purpose-built speaker?

If it's a purpose-built speaker (an intercom at a gate, a warning speaker on a perimeter), you always add a Genesis Audio device — regardless of what NVR or VMS the site runs. Genesis Audio doesn't go through the camera's own video system at all; it's routed over its own SIP/Twilio connection directly from GCXONE. That's why it works identically everywhere: it doesn't depend on the camera vendor.

If the ask is "can the operator talk through the camera that's already mounted there," the answer depends on the brand — see the table below.

2. Is the operator watching over the cloud (GCXONE web app, from anywhere), or is this a Local Mode / on-prem setup (operator on the same network as the NVR)?

These are two different technical paths and a brand can support one without the other:

• Cloud path — audio is relayed through GCXONE's own cloud, the same way the video stream is, so an operator anywhere in the world can use it. This is the path most customers actually need, since remote monitoring is the whole point of GCXONE.
• Local Mode path — GCXONE talks directly to the on-prem NVR's own SDK when the operator's client is on-site or on a VPN to it, bypassing the cloud entirely. Two-way audio through the camera can work here even when it doesn't work over the cloud for that same brand.

The practical rule today: a camera's own embedded audio reliably works over the cloud only on ADPRO. On every other mainstream brand (Hikvision, Dahua, Avigilon, Milestone, Uniview, and others), the camera's own speaker/mic is either not available over the cloud at all, or still in development — even though the same camera's audio often works fine locally, over Local Mode, using the vendor's own SDK. This is the main reason to recommend a Genesis Audio speaker instead of relying on a camera's built-in one: it's the only audio path that is fully supported over the cloud regardless of brand.

What actually works today, by brand

Reading this in practice:

• Genesis Audio speaker → always the safe answer. It's independent of the camera brand by design, so it's the thing to recommend whenever a customer needs reliable two-way audio and isn't only using Local Mode on ADPRO hardware.
• "Not available" isn't a bug to chase — for most brands, a camera's own embedded audio over the cloud was simply never built. Don't spend a support ticket trying to make a Hikvision camera talk over the cloud; it isn't there yet on any brand except ADPRO.
• "In development" is a real state, not a misconfiguration. If a customer's camera brand shows "in development" and audio doesn't work, that is expected — it isn't a setup problem on the customer's side.
• Local Mode unlocks camera audio on most major brands even where the cloud path doesn't exist yet — worth knowing if a customer specifically asks about two-way audio through their existing Hikvision/Dahua/Avigilon/Milestone/Uniview cameras and is willing to run Local Mode.

How to configure each one

Genesis Audio (works the same on every brand above)

1. In Configuration → Devices, click Add, and set the device Type to GENESIS Audio. Give it a name and click Discover, then Save.
2. Open the device's SIP URL to get its Username, Password and SIP Domain — this is what you use to register the physical speaker (e.g. an Axis Horn Speaker) against the device on the speaker's own web client.
3. Assign the Genesis Audio permission to any operator role that needs to place calls.
4. Local Mode is not required to place a Genesis Audio call. It is required if you want to test the speaker's own default audio outside of a Genesis Audio call.

Full steps: Genesis Audio Config Guide · Speaker (SIP registration)

Camera-embedded audio (only where the table above says "Works")

There's no separate device to add — it's a setting on the camera's own record:

1. An admin confirms the Audio setting is turned on for that camera's device record in GCXONE. This is a platform-side setting, separate from whatever the camera's own firmware reports — see the mismatch warning below.
2. In the Video Viewer, the operator uses the Audio (Listen) icon on that camera's tile to hear its microphone, and Speaker (Talk) to talk through it, where the brand supports Talk.
3. The operator's browser will prompt for microphone permission — get this granted before a shift starts, not mid-incident, since the permission prompt causes a delay if it comes up during a live call.

Operator workflow: Audio & Communication

When audio "isn't working," check the platform setting against the camera itself

Every camera has a platform-side Audio on/off setting, separate from whatever the camera's own firmware is actually configured to do. These two facts can quietly drift apart — most often after an integrator changes audio settings directly on the camera without anyone updating the matching setting in GCXONE. The result: GCXONE refuses to open the microphone even though the camera itself is ready, or GCXONE thinks audio is available on a camera whose hardware audio was later disabled or removed.

So the first troubleshooting step for "audio doesn't work on this specific camera" is always to check both sides — what GCXONE's device record says, and what the camera itself reports — not just one of them. Agreement between the two is what makes audio actually available; neither one on its own guarantees it.

Genesis Audio and Conference Mode

When an operator starts an audio call from the Video Viewer:

• If a site has more than one active Genesis Audio device, the call automatically becomes a Conference Mode call, connecting every active Genesis Audio speaker at that site plus the operator into one call — no manual setup needed.
• If there's no active Genesis Audio device at the site, the call falls back to the camera's own audio instead, wherever the brand table above says that's available.

Full detail: Audio Routing & Conference Mode

Where each piece lives

Technical reference

The plain-language summary above is built from three separate capability flags the integration catalog tracks per device brand, plus one per-camera setting. Useful if you're diagnosing a specific integration rather than advising a customer in general terms.

ADPRO specifics

ADPRO (Honeywell) is the only brand at full on all three catalog flags at once. What's confirmed from its integration record:

• Ports: RTSP on 554, a control channel on 2000, and a dedicated audio port on 3000 — audio has its own port, separate from video and control. src/lib/agent/reachability.ts labels port 3000 literally as ADPRO audio in its connectivity-probe tooling.
• Protocol: "ADPRO SDK (for both Cloud and Local), TCP Receiver (events)" — GCXONE talks to the vendor SDK directly for both the cloud and Local Mode audio paths, with a separate TCP push channel for events.
• Event integration: devices are configured to push events via TCP to a Genesis-side ADPRO receiver, rather than GCXONE polling the device.

What is not documented anywhere in this codebase, and shouldn't be guessed: the catalog's requirements, limitations and supported-events fields are empty for ADPRO; the published ADPRO setup guide only covers adding the device and never mentions audio or port 3000; and there's no ADPRO-specific capability-probing code the way there is for Hikvision (isSupportAudio over ISAPI) or Dahua (AudioEnable over its config API). The on-wire audio protocol over port 3000 would need to be confirmed against Honeywell's own ADPRO SDK documentation before being written up as fact.