Two-Way Audio

Talk to whoever is standing in front of your camera, straight from the Shinobi dashboard. Your microphone goes to the camera's speaker — useful for answering a doorbell or telling someone to get off the driveway.

What You Need

• A camera with a built-in speaker that supports one of the methods below. A camera that only has a microphone cannot be talked to.
• A microphone on the device you are viewing from.
• Permission to control the monitor. Talking uses the same permission as PTZ, so an account that cannot move the camera cannot talk through it either.
• Browsers only allow microphone access on a secure page, so use HTTPS (localhost is also treated as secure).

Setting It Up

• Edit the Monitor and find Two-Way Audio.
• Pick the method your camera supports. It is Disabled by default.
• Fill in anything the provider asks for — most need nothing extra, UniFi Protect is the exception.
• Save the Monitor.

Most methods reuse the camera username and password you already entered for the video stream, so there is usually nothing more to fill in.

Talking

Once it is enabled, a Talk option appears in that monitor's menu in the Live Grid. Click it to start talking and click it again to stop. Your browser will ask for microphone permission the first time.

You will not hear yourself through the dashboard — that is deliberate, so you do not get an echo.

ONVIF Profile T

The standard method, and the one to try first if your camera is not listed below. It sends audio back over the same RTSP connection the video uses, so it usually needs no extra settings at all.

Firmware varies wildly here, so a few advanced settings exist to work around stubborn cameras:

• Transport — TCP by default, which works through NAT, Docker bridges and firewalls. Only switch to UDP if your camera demands it; if UDP fails, TCP is used anyway.
• RTP Frame Size — defaults to 1024 (about 128ms), which is the most widely compatible. Set 160 for strict 20ms packets if your camera prefers them.
• Zero Timestamps — not valid RTP, but some firmware (notably Reolink doorbells) will only play audio this way. Leave it off unless the camera stays silent otherwise.
• RTSP Path and RTSP Port — only needed if the backchannel lives somewhere other than your video stream, or if the monitor pulls video over JPEG/MJPEG and so has no RTSP URL to borrow.

Amcrest / Dahua

For Amcrest and Dahua cameras and doorbells. Shinobi posts audio to the camera's audio.cgi over HTTP.

• Reuses the camera's existing username and password.
• Uses the HTTP port, which defaults to 80. Set Two-Way Audio HTTP Port if yours differs.
• Sends G.711 A-law audio at 8kHz.

Hikvision (ISAPI)

For Hikvision cameras, and Hikvision video doorbells too — they share the same interface.

• Reuses the camera's existing username and password.
• Uses the HTTP port, defaulting to 80.
• Shinobi asks the camera which audio channel to use and which codec it wants, then matches it — so there is nothing to configure by hand.
• If the camera reports no two-way audio channel, it does not support this feature.

DoorBird

For DoorBird video doorbells.

• Reuses the camera's existing username and password.
• Uses the HTTP port, defaulting to 80.
• Sends G.711 mu-law audio at 8kHz.

UniFi Protect

This one is different from the rest. Shinobi talks to your Protect NVR (UDM, UNVR or CloudKey Gen2) rather than to the camera directly, so it needs different details:

• Two-Way Audio Host — the NVR's address, not the camera's.
• UniFi Protect Username and Password — a login for the NVR itself. This is not the camera's RTSP password.
• UniFi Protect Camera ID — the camera's id within Protect.
• The port defaults to 443, since Protect uses HTTPS.

Do not know the camera id? Leave it blank and try to talk. The error message lists every camera on the NVR along with its id, so you can copy the right one.

If It Does Not Work

• No Talk option in the menu — Two-Way Audio is still set to Disabled on that Monitor, or your account lacks control permission.
• Browser never asks for the microphone — you are on plain HTTP. Use HTTPS.
• Connects but the camera is silent (ONVIF) — try Zero Timestamps, especially on a Reolink doorbell.
• Audio stutters or cuts out (ONVIF) — try an RTP Frame Size of 160.
• Authentication failures — check the camera's HTTP port. These methods use the web port (usually 80), which is often not the RTSP port.
• UniFi Protect errors — confirm you used the NVR address and an NVR login, not the camera's.

Recording or transmitting audio is regulated in some places. Check what is allowed in your area before using this feature.

How It Works (Technical)

Audio takes this path from your microphone to the camera:

browser mic
  -> WebAudio Int16 PCM
  -> socket.io ('talkChunk' binary)
  -> ffmpeg (transcode to the codec the camera wants)
  -> provider adapter
  -> camera speaker

• The browser captures the mic as raw mono PCM and streams it over the socket.io connection the dashboard already has open (talkStart / talkChunk / talkStop).
• The server transcodes that PCM with ffmpeg into whatever the chosen provider needs — G.711 A-law or mu-law for the RTSP and CGI providers, AAC in ADTS frames for UniFi Protect.
• Every provider exposes the same small interface, so the session manager does not care which camera brand is on the other end: connect(...) returns startBackchannel() and close(), and startBackchannel() returns writeAudio(buffer) plus the audio format it expects.
• The provider is chosen per Monitor from details.two_way_audio.
• Permission is checked with the same rule PTZ uses, so control rights govern both.

The vendor HTTP providers stream over raw TCP sockets rather than Node's HTTP client, because these embedded camera endpoints expect an audio body of unknown length — declared with a deliberately large Content-Length and streamed until the socket closes.

Per provider, in short:

• ONVIF — RTSP DESCRIBE carrying Require: www.onvif.org/ver20/backchannel, picks the audio section the camera marked sendonly, prefers PCMU then PCMA, then SETUP + PLAY and pushes RTP. Digest auth, TCP interleaved by default.
• Amcrest / Dahua — digest-authenticated POST to /cgi-bin/audio.cgi as a single-part stream, Content-Type: Audio/G.711A.
• Hikvision — ISAPI TwoWayAudio: GET the channel list to discover the id and codec, then PUT open, stream to audioData, and PUT close.
• DoorBird — Basic-authenticated POST to /bha-api/audio-transmit.cgi, Content-Type: audio/basic.
• UniFi Protect — log into the NVR, read the bootstrap to find the camera, request a talkback WebSocket URL, then send whole ADTS frames over that socket.

The ONVIF provider deliberately departs from a strict reading of the spec in a few places because real firmware needs it — large G.711 frames with the marker bit set, retrying a session without the Require header when a camera answers 551, reconnecting from scratch after a failed SETUP, and normalising the malformed Content-Base values cameras commonly return. Those behaviours are exposed as the settings above so a stubborn camera can be worked around without patching Shinobi.