#C088ZNU7QQ5 we are facing issue in gemini live , something it starts responding and parallel tool calling but then abruptly stops responding and the tool calling also stops in between , is this any issue of the model , or a recurring issue give gemini realtime ?

Thanks for reaching out, Areeb. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

it is happening 2/5 times and particulary these 2 times generaly it calls the wrong tool

Thanks — that helps. To diagnose the intermittent stoppage and wrong-tool calls I need a few more specifics: 1. Which tool was called incorrectly and which tool did you expect it to call? 2. Can you share the exact prompt or user input (redact sensitive info) that led to the wrong-tool call? 3. Which Gemini Live integration/SDK and version are you using (browser JS, realtime API, server SDK)? 4. Do you see any log entries, error messages, or warnings at the moment it stops or when the wrong tool is selected? A short log snippet is helpful. 5. Do the sessions that fail share anything in common (same room, same user, same time window)? 6. Are you applying any custom routing, heuristics, or tool-selection parameters before invoking Gemini? With these details I’ll provide targeted troubleshooting steps and likely causes. , with interactive elements

INFOrootSending event to webhook: {'type': 'conversation_item_added', 'item': {'id': 'GR_4529da364506', 'type': 'message', 'role': 'assistant', 'content': ["I'm sorry your"], 'interrupted': True, 'transcript_confidence': None, 'extra': {}, 'metrics': {'started_speaking_at': 1776260308.044866, 'stopped_speaking_at': 1776260309.489718}, 'created_at': 1776260308.044866, 'hash': None}, 'created_at': 1776260309.491694, 'roomName': 'e_69df94c16c9ece73ed5194f8_-_spinmaster_inboundvoice'} WARNINGlivekit.agents_SegmentSynchronizerImpl.playback_finished called before text/audio input is done INFOrootWebhook sent successfully latency=975.3ms INFOrootWebhook sent successfully latency=963.1ms INFOhttpxHTTP Request: POST XXXXXXXXXXXXXXXX "HTTP/1.1 200 OK" INFOrootUser interim transcript received ERRORrootFailed to notify participant 'heer' that user stopped speaking, error: strMethod not supported at destination INFOrootSending event to webhook: {'type': 'conversation_item_added', 'item': {'id': 'GI_dd14d5c5960a', 'type': 'message', 'role': 'user', 'content': ['Hello, can you hear me?'], 'interrupted': False, 'transcript_confidence': None, 'extra': {}, 'metrics': {}, 'created_at': 1776260415.506331, 'hash': None}, 'created_at': 1776260415.5063858, 'roomName': 'e_69df94c16c9ece73ed5194f8_-_spinmaster_inboundvoice'} INFOrootWebhook sent successfully latency=1437.5ms

Thanks — I looked over your logs and your answers. I’m responding about the intermittent stoppage and the wrong-tool calls. Summary of likely causes (based on your logs) • The warning

_SegmentSynchronizerImpl.playback_finished called before text/audio input is done

and the interrupted assistant message indicate a timing/interrupt mismatch in the media pipeline. • The “Method not supported at destination” error suggests a signaling/RPC mismatch when notifying participants during interruption events. • Gemini Live model versions (notably

gemini-3.1-flash-live-preview

) have known limitations: mid-session updates (e.g.,

send_client_content

) can be rejected, asynchronous function calling isn’t supported, and these can cause the agent to pause or pick the wrong tool during interrupted/partial input. Immediate actions to try 1. Confirm the Gemini model version you’re using. If it’s

gemini-3.1-flash-live-preview

, try switching to a realtime-compatible Gemini model if available. 2. Enable or tune Adaptive Interruption Handling: ◦ Increase

false_interruption_timeout

and enable

resume_false_interruption

so brief/noisy interruptions don’t cut the agent off. 1. Protect critical tool calls: ◦ Wrap important tool executions with

run_ctx.disallow_interruptions()

or ensure the tool waits for playout completion (

await context.wait_for_playout()

). 1. Make tool selection more robust: ◦ Clarify tool descriptions/prompts so partial transcripts don’t match the wrong tool. ◦ Add pre-call validation in your router: check the predicted tool against intent signals or confidence thresholds before invoking. 1. Inspect signaling and participant notification paths: ◦ Check for RPC/signaling version mismatches that could cause “Method not supported at destination” when notifying participants. 1. Collect improved repro data: ◦ Record full request/response tool selection decisions and timestamps for both successful and failing sessions. ◦ Note whether failures share the same room, user, or time window. Questions so I can narrow this down further • Which Gemini model/version are you using? • Which tool was selected incorrectly and which tool should have been called? Please share the (redacted) user input that led to the wrong selection. • Do failures always occur in the same room/user or are they random? • Can you share the router/tool-selection logic (or a short snippet) that decides which tool to call? If you share those details I’ll provide a prioritized next-step checklist and exact config/code changes to test. Sources: Gemini Live API plugin | LiveKit Documentation | Turns overview | LiveKit Documentation | Solving unwanted interruptions with Adaptive Interruption Handling | LiveKi... | Build Your First AI Voice Agent in Python: Complete Tutorial | LiveKit | Sequential Pipeline Architecture for Voice Agents | LiveKit, with interactive elements

gemini-live-2.5-flash-native-audio

Thanks — good to know you’re on gemini-live-2.5-flash-native-audio. I’ll focus on that. Likely causes based on your logs and model: • Timing/interrupt mismatch in the media pipeline (the

_SegmentSynchronizerImpl.playback_finished...

warning and interrupted assistant item). • False or partial-transcript interruptions causing the model to start/stop and choose the wrong tool. • Signaling/RPC mismatch when notifying participants (

Method not supported at destination

) that can disrupt flow during interruptions. Please try these prioritized actions: 1. Enable/tune Adaptive Interruption Handling: ◦ Increase

false_interruption_timeout

and enable

resume_false_interruption

so brief noises don’t interrupt the agent. 1. Protect critical tool executions: ◦ Wrap critical tools with

run_ctx.disallow_interruptions()

or ensure tools await playout completion (

await context.wait_for_playout()

). 1. Harden tool selection: ◦ Make tool descriptions unambiguous and add a pre-call confidence/intent check in your router to reject low-confidence selections. 1. Verify signaling compatibility: ◦ Confirm your signaling/RPC implementations and versions match across participants to avoid “method not supported” errors. 1. Collect repro data: ◦ Log full transcripts, predicted tool, tool arguments, model reply IDs, and timestamps for both success and failure cases. Quick questions to narrow it down: • Which tool was selected incorrectly and which tool should have been called? • Can you share the (redacted) user input that triggered the wrong tool? • Do failures occur in the same room/user or appear random? • Are you applying any custom routing/heuristics before invoking the tool? Send those details and I’ll give exact config/code changes to test next. , with interactive elements

Google Gemini Live's server-side VAD detects user speech mid-playback and triggers a new generation, causing the framework to cancel the current

SpeechHandle

and mark the conversation item as

interrupted: True

. This happens at two levels: Gemini interrupting its own generation mid-stream (fixed via

activity_handling: NO_INTERRUPTION

), and the framework cutting audio playback when a new user turn or tool-call response starts a new generation. WARNINGroot⚠️ High connection latency detected: 1149.0ms (expected <1000ms) WARNINGroot⚠️ Slow session startup: 3065.7ms (expected <3000ms) INFOrootSending event to webhook: {'type': 'conversation_item_added', 'item': {'id': 'GR_843449e8bc66', 'type': 'message', 'role': 'assistant', 'content': ['Thank you for calling Spin Master support. How can I help you today?'], 'interrupted': False, 'transcript_confidence': None, 'extra': {}, 'metrics': {'started_speaking_at': 1776322696.958254, 'stopped_speaking_at': 1776322699.820064}, 'created_at': 1776322696.958254, 'hash': None}, 'created_at': 1776322699.820377, 'roomName': 'e_69e088819f89614371c0b015_-_spinmaster_inboundvoice'} INFOrootWebhook sent successfully latency=1008.1ms INFOrootUser interim transcript received ERRORrootFailed to notify participant 'heer' that user stopped speaking, error: strMethod not supported at destination INFOrootSending event to webhook: {'type': 'conversation_item_added', 'item': {'id': 'GI_660f837f934f', 'type': 'message', 'role': 'user', 'content': ['My monster champ device is not working.'], 'interrupted': False, 'transcript_confidence': None, 'extra': {}, 'metrics': {}, 'created_at': 1776322708.7930949, 'hash': None}, 'created_at': 1776322708.79315, 'roomName': 'e_69e088819f89614371c0b015_-_spinmaster_inboundvoice'} INFOrootSending event to webhook: {'type': 'conversation_item_added', 'item': {'id': 'GR_5a6e964f3c75', 'type': 'message', 'role': 'assistant', 'content': ['I completely'], 'interrupted': True, 'transcript_confidence': None, 'extra': {}, 'metrics': {'started_speaking_at': 1776322707.21246, 'stopped_speaking_at': 1776322708.830852}, 'created_at': 1776322707.21246, 'hash': None}, 'created_at': 1776322708.832969, 'roomName': 'e_69e088819f89614371c0b015_-_spinmaster_inboundvoice'} WARNINGlivekit.agents_SegmentSynchronizerImpl.playback_finished called before text/audio input is done INFOrootWebhook sent successfully latency=979.1ms INFOrootWebhook sent successfully latency=956.4ms INFOhttpxHTTP Request: POST https://unifyapps-support.prod.unifyapps.com/api-endpoint/agent-mcp/e_69bc112c35007473805f0e82/messages?sessionId=e_69e088828b92dd1f8cc57386&amp;caseId=e_69e088819f89614371c0b015 "HTTP/1.1 200 OK" see this events

Thanks — this is very helpful. I’m responding about the events you shared (VAD mid-playback, interrupted assistant turns, latency warnings, and the “Method not supported at destination” error). What’s happening • The server-side VAD is detecting user speech during assistant playback and starting a new generation, which cancels the current SpeechHandle and marks the assistant message as

interrupted: True

. • That interruption can happen in two places: Gemini interrupting its own generation and the framework cutting audio playback when a new user turn or tool-call starts. • Your logs show high latency and slow startup, which make timing-sensitive VAD decisions more likely to misfire and increase the chance of mid-playback interruption. • The RPC error when notifying participants indicates a signaling/method-compatibility issue that can further disrupt flows during interruption events. Concrete next steps (prioritized) 1. Set Gemini activity handling to no interruptions ◦ Configure

activity_handling: NO_INTERRUPTION

so Gemini doesn’t interrupt its own generation mid-stream. 1. Tune server-side interruption thresholds ◦ Increase

false_interruption_timeout

and enable

resume_false_interruption

to avoid treating brief/noisy audio as user intent to interrupt. 1. Protect critical tool executions and playout ◦ For important tool calls, use

run_ctx.disallow_interruptions()

or ensure the tool awaits playout completion with

await context.wait_for_playout()

so the framework won’t cancel critical executions. 1. Harden tool-selection logic ◦ Add a pre-call validation step: require a confidence/intent threshold for tool invocation or a quick intent confirmation before calling irreversible tools. ◦ Make tool descriptions and invocation prompts explicit so partial transcripts map less frequently to the wrong tool. 1. Address latency and signaling errors ◦ Investigate the high connection latency and slow session startup (logs show >1000ms latency and >3000ms startup). Reduce network latency where possible and ensure webhook/HTTP endpoints respond fast. ◦ Verify signaling/RPC versions and supported methods across participants to eliminate “Method not supported at destination” errors. 1. Capture focused repro data ◦ Log timelines for: assistant start/stop timestamps, VAD events, interim transcripts, predicted tool + confidence, tool args, and any RPC errors for each session (successful vs failing). ◦ Record a few failing sessions with timestamps to reproduce the same timing conditions. Questions to confirm before I give exact config/code snippets • Have you already set

activity_handling: NO_INTERRUPTION

? If so, did behavior change? • Which tool was selected incorrectly in the failing cases, and what was the (redacted) user utterance that triggered it? • Do the problematic sessions correlate with high-latency periods in your logs? Send those answers and I’ll provide exact config values and sample code snippets to implement the changes above. , with interactive elements

yes Have you already set

activity_handling: NO_INTERRUPTION

but this didnt affect its breaking whenever the line of mcp comes which is bascially the tool call, that high latency is not the issue the break is happenign during tool call only i think the google gemini hasn tproperly supporyted tool calling and its vad

Thanks — I hear you: you set

activity_handling: NO_INTERRUPTION

and it didn’t help, the break always happens during MCP/tool calls, and you believe Gemini Live’s realtime tool-calling + VAD is the root cause. What I’ll do: confirm what’s true from the logs you shared, give focused mitigations you can try immediately, and ask one short question to pick the best next step. What’s happening (confirmed) • Interrupts occur precisely when the MCP/tool-call line runs; assistant turns are marked

interrupted: True

and playback is cut. •

activity_handling: NO_INTERRUPTION

prevents Gemini from interrupting its own generation but does not stop the framework or VAD from canceling playback when a new generation (tool call or user turn) is triggered. • The framework’s VAD and tool-call flow can still cause mid-tool interruptions; this is consistent with known realtime constraints around Gemini live tool-calling/VAD behavior. Immediate mitigations to try now • Disable VAD or barge-in for the short window around tool execution: ◦ Before calling the tool, call

run_ctx.disallow_interruptions()

(or the equivalent in your framework) and re-enable afterward. • Block framework-driven interruption during playout: ◦ Ensure the tool handler uses

await context.wait_for_playout()

(or equivalent) so playout completes before any new generation is allowed. • Add a pre-call confirmation/locking layer: ◦ When the router selects a tool, acquire a short-lived “tool call lock” so incoming VAD events are ignored until the tool returns. • Make tool invocation idempotent and resumable: ◦ If the tool call can be retried safely, detect interrupted executions and retry once with the same args. • As a diagnostic step, route tool calls off the realtime/VAD path: ◦ Call tools from a non-realtime server flow (e.g., async backend request) and feed results back to the live session only after the call finishes. If you prefer a quicker workaround: • Bypass live-model tool-calling: run tool calls in a standard (non-live) Gemini model or backend service and inject the completed tool result into the live session. This avoids VAD/interrupt race conditions at the cost of slightly higher latency. One short question to pick the best next step • Can your tool calls be executed off the realtime path (backend/async) and then injected back to the session, or do they require strict realtime semantics? If you say “yes, they can be async,” I’ll provide a concise code/config snippet for safely routing tool calls off the realtime/VAD path and re-injecting results without interruption. , with interactive elements

class Behavior(_common.CaseInSensitiveEnum):
  """Specifies the function Behavior.

  Currently only supported by the BidiGenerateContent method. This enum is not
  supported in Vertex AI.
  """

  UNSPECIFIED = 'UNSPECIFIED'
  """This value is unused."""
  BLOCKING = 'BLOCKING'
  """If set, the system will wait to receive the function response before continuing the conversation."""
  NON_BLOCKING = 'NON_BLOCKING'
  """If set, the system will not wait to receive the function response. Instead, it will attempt to handle function responses as they become available while maintaining the conversation between the user and the model."""

this is supported in other models but vertex ai true not supported

Thanks — I see you’ve confirmed behavior and shared the enum context. I’m replying about the core question: does Gemini Live support non-blocking tool calls, and how to work around the tool-call interruptions you’re seeing. Short answer • Gemini Live (the realtime/Live integration you’re using) does not support true asynchronous (

NON_BLOCKING

) function/tool calling. Tool calls are effectively blocking: the model pauses and expects a tool response before continuing, which can cause interruptions during MCP/tool-call periods. What that explains in your case • Even with

activity_handling: NO_INTERRUPTION

set, the framework or model will still cancel playback and mark the assistant

interrupted: True

when a tool-call generation is started. That’s consistent with the blocking tool-call behavior and the VAD/interrupt interaction you’ve observed. Practical mitigations you can apply now • Send an immediate acknowledgement to the model when a tool is invoked (e.g., "Working on that...") so the blocking time is short. • Offload long-running work: accept the tool call, reply immediately, then perform the heavy work asynchronously in your backend and inject results back into the session when ready. • Prevent barge-in during tool execution: ◦ Use

run_ctx.disallow_interruptions()

(or your framework’s equivalent) while the tool is executing. ◦ Ensure the tool handler calls

await context.wait_for_playout()

where applicable so playout finishes before new generations. • Add a short “tool call lock” around tool invocation in your router to ignore VAD events until the tool completes or a safe timeout elapses. • Make tool calls idempotent and retryable so interrupted executions can be safely retried. If you need lower-latency, non-blocking behavior • Route tool calls off the realtime model (call tools from an async backend or a non-live model) and then inject results back to the live session when ready. This avoids the VAD/blocking race at the cost of some latency. If you want, I can: • Provide a concise code snippet showing how to acknowledge the model immediately and offload the heavy work asynchronously, or • Show a small example of using

run_ctx.disallow_interruptions()

and

await context.wait_for_playout()

around a critical tool call. Which snippet would help you most? Sources: Gemini Live API plugin | LiveKit Documentation | Function tool definition | LiveKit Documentation, with interactive elements