Gemini Live API: acoustic echo cancellation needed for SIP telephony deployments

Gemini API
1

Description:

When using the Gemini Live API in SIP telephony integrations (e.g. over Zadarma, Twilio, or other B2BUA carriers), the carrier reflects the model’s outbound audio back into the inbound RTP stream. Gemini Live’s VAD picks this up as user speech and fires inputTranscription and serverContent: interrupted events — causing the model to interrupt itself mid-sentence.

Observed behavior:

  • inputTranscription fires with the model’s own words (e.g. “I’m sorry,” / “How can”)

  • serverContent: {"interrupted": true} immediately follows

  • The model re-generates from where it was interrupted, creating split conversation turns

  • Conversation transcripts show the model’s words attributed to the user

Current workaround: prefixPaddingMs: 200 in the session config filters echoes shorter than 200ms. However, multi-syllable phrases (>200ms) still pass through.

Requested feature: Acoustic echo cancellation (AEC) support in the Gemini Live API input audio pipeline, so that audio frames matching recently sent output are suppressed before VAD processing. Alternatively, a higher prefixPaddingMs value (e.g. 500ms) or a separate echoSuppressionMs parameter.

Environment: Node.js server, G.711 μ-law 8kHz, SIP via Zadarma B2BUA, gemini-3.1-flash-live-preview

2

• We are experiencing a similar issue with gemini-3.8-live using the Live

API over WebSocket in a smartphone browser.

While the user remains silent, the microphone picks up the model’s own

speaker output. The model’s words then appear in the input transcription

as if the user had spoken, and the audible response cuts off. This happens

repeatedly and makes normal conversation difficult.

Our current implementation uses:

  • Browser microphone capture with echoCancellation: true,

    noiseSuppression: true, and autoGainControl: false.

  • A local WebRTC loopback for audio playback.

  • Automatic activity detection with low speech-start and speech-end

    sensitivity.

These measures have not resolved the issue on the affected smartphone. A

desktop Chrome test with simulated speaker-to-microphone loopback passed,

but it did not reproduce the smartphone behavior.

We have confirmed the repeated attribution of the model’s speech to the

user in the transcripts. We have not yet captured the corresponding

serverContent.interrupted events from the affected smartphone, so we

cannot conclusively attribute the playback stoppage to that signal or

establish whether the underlying cause is in the browser, our

implementation, or the API.

Is this a known issue affecting Gemini 3.8 Live? Is there a recommended

browser audio architecture or a working reference implementation that

prevents echo-triggered self-interruption while preserving genuine user

barge-in?

Disabling interruptions entirely or muting the microphone throughout the

model’s response would remove the full-duplex interaction we need. We

would appreciate guidance on the supported solution and any diagnostics

needed to investigate further.