Problem statement
Home Assistant does not currently support two-way audio, which is a core feature of video doorbells and many security cameras. Users who want this today must fall back to a manufacturer's own app, breaking the local-first and integration promise of Home Assistant. This opportunity is about building two-way audio as a generic, platform-level capability that any integration can build on, not a feature tied to any single brand or implementation.
Home Assistant aims to provide the same user experience regardless of the platform used. Two-way audio will therefore ship with full parity across iOS and Android, enabling users to speak through their phone to any compatible camera or doorbell via the Home Assistant companion app. Two-way audio support via the Home Assistant frontend is included as well.
Previous analysis and community work - most notably the Core PR at home-assistant/core#148282 - surfaces a key constraint: the majority of Home Assistant users run local http connections, and current WebRTC players do not allow microphone access over insecure http. This requires native WebRTC players in the companion apps capable of accessing the microphone over http connections.
Community signals
The primary community thread tracking demand for this feature:
Related Core PR with prior implementation work:
Scope & Boundaries
In scope
- Two-way audio in the Home Assistant companion apps on iOS and Android, with full feature parity between platforms
- Two-way audio in the Home Assistant frontend, with parity to the companion app experience
- Generic capability model that any integration can implement against
Not in scope
- Integration-specific implementations
- Cameras using HLS streams (WebRTC connections only)
- Two-way audio enabled by default - user interaction is required to initiate
Foreseen solution
Cameras speak many different protocols: RTSP, RTMP, WebRTC, HLS, FFmpeg-processed streams, and so on. The Home Assistant frontend and companion apps can't speak all of these natively. go2rtc sits in the middle as a translation layer and pulls the stream from the camera, transcodes or re-wraps it as needed, and hands it to the client.
The foreseen solution only supports WebRTC connections and cameras need to support either native 2-way audio (via go2rtc) or 2-way audio via WebRTC. HLS support is not available.
Standard camera streaming is one-directional: go2rtc pulls a stream from a camera and pushes it to a viewer. That's recvonly in WebRTC terms - the client only receives.
Two-way audio requires the connection to be sendrecv - the client both receives the camera's stream and sends microphone audio back through the same session. This is a fundamentally different negotiation at the WebRTC handshake level. Furthermore, devices need to emit their capability for two-way audio appropriately. Two-way audio must not be initiated by default, instead it should only activate on explicit user interaction.
Risks & open questions
Open questions
- Handling of http & https connections by the WebRTC players for mobile apps
Appetite
Medium - 4-5 weeks
Execution issues
No response
Decision log
Problem statement
Home Assistant does not currently support two-way audio, which is a core feature of video doorbells and many security cameras. Users who want this today must fall back to a manufacturer's own app, breaking the local-first and integration promise of Home Assistant. This opportunity is about building two-way audio as a generic, platform-level capability that any integration can build on, not a feature tied to any single brand or implementation.
Home Assistant aims to provide the same user experience regardless of the platform used. Two-way audio will therefore ship with full parity across iOS and Android, enabling users to speak through their phone to any compatible camera or doorbell via the Home Assistant companion app. Two-way audio support via the Home Assistant frontend is included as well.
Previous analysis and community work - most notably the Core PR at home-assistant/core#148282 - surfaces a key constraint: the majority of Home Assistant users run local http connections, and current WebRTC players do not allow microphone access over insecure http. This requires native WebRTC players in the companion apps capable of accessing the microphone over http connections.
Community signals
The primary community thread tracking demand for this feature:
Related Core PR with prior implementation work:
Scope & Boundaries
In scope
Not in scope
Foreseen solution
Cameras speak many different protocols: RTSP, RTMP, WebRTC, HLS, FFmpeg-processed streams, and so on. The Home Assistant frontend and companion apps can't speak all of these natively. go2rtc sits in the middle as a translation layer and pulls the stream from the camera, transcodes or re-wraps it as needed, and hands it to the client.
The foreseen solution only supports WebRTC connections and cameras need to support either native 2-way audio (via go2rtc) or 2-way audio via WebRTC. HLS support is not available.
Standard camera streaming is one-directional: go2rtc pulls a stream from a camera and pushes it to a viewer. That's recvonly in WebRTC terms - the client only receives.
Two-way audio requires the connection to be sendrecv - the client both receives the camera's stream and sends microphone audio back through the same session. This is a fundamentally different negotiation at the WebRTC handshake level. Furthermore, devices need to emit their capability for two-way audio appropriately. Two-way audio must not be initiated by default, instead it should only activate on explicit user interaction.
Risks & open questions
Open questions
Appetite
Medium - 4-5 weeks
Execution issues
No response
Decision log