what can be a reason for my telephony agent is ending call before max_call_duration without any reason?

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

I have end_call function which will call when user ask to end call or process is done My user is speaking and there is no trace for end_call but its still decide to call the function.. i have setted max_call_duration=10 minutes.. but some time it will end the call in 7 to 9 minutes or 5 minutes or whichever time I have setted user_away_timeout = 30 seconds.. but for some cases user is speaking and it will still call end_call function and while user speaks it will end the conversation

Thanks — this is helpful detail. I understand: you call

end_call

only when user requests it or process is done, you set

max_call_duration = 10 minutes

,

user_away_timeout = 30s

, but calls still end early (5–9 minutes) while the user is speaking and there’s no explicit

end_call

trace. Let’s narrow this down and find the root cause. Quick summary of most likely causes given what you shared • Some part of the agent runtime is still invoking

end_call

(or

session.shutdown()

) indirectly — for example an LLM tool, a background task, or error handling — even though you don’t see a direct user-triggered call. • A silence / VAD detection component may be mis-detecting speech (false negatives) and triggering shutdown logic that calls

end_call

. • An intermittent error (e.g., inference API timeout or other exception) may be hitting error-handling code that calls

end_call

. • A retry/limit in the greeting or other flow could be reached at different durations depending on conversation events and cause an early shutdown. Targeted diagnostics to run (in order) 1. Capture verbose logs around a disconnect event ◦ Include timestamps, full stack traces, and all log lines that mention

end_call

,

session.shutdown

,

EndCallTool

,

error

,

exception

,

away

,

silence

, and any VAD or speech-detection components. ◦ Ensure logs show which code path invoked

end_call

(caller function / stack trace) so you can see whether it was user code, an LLM tool, or error handling. 1. Add instrumentation around

end_call

to log the call source and context ◦ Before

end_call

executes, log: caller stack trace, value of any flags/conditions (e.g.,

user_state

,

last_speech_timestamp

,

greeting_attempts

), and recent events (last 30s of detected speech events). ◦ If you can’t modify

end_call

directly, wrap it with a small wrapper that logs this metadata then calls the real function. 1. Verify VAD / silence detection behavior ◦ Log raw VAD/speech-detection decisions (speech vs silence) with timestamps. Confirm that speech is actually being detected when the user is talking. ◦ Temporarily relax or disable silence thresholds to confirm whether mis-detected silence is the cause. 1. Check for LLM/tool-driven shutdowns ◦ If the agent uses tools (like an EndCallTool) or LLM reasoning that can call tools, add logging for tool invocations and model outputs right before any shutdown. The model may be deciding to end the call. 1. Correlate external API calls / errors ◦ Look for inference API timeouts, rate-limit responses, or other transient errors in the logs just before shutdown. Add retries or more robust error handling if shutdown is triggered by an error path. 1. Reproduce with verbose tracing in a controlled test ◦ Create a short test call where the user speaks continuously and you reproduce the scenario while recording all logs and events. This will expose race conditions or intermittent checks (e.g., a background task reading outdated timestamps). What I can help you run/check next • If you can share a log snippet showing the 30–60 seconds before an early disconnect (redact any sensitive content), I’ll read it and point to the exact place that triggered

end_call

. • If you prefer to instrument first, I can provide a minimal wrapper snippet to add around

end_call

that captures caller stack and last-events log. Tell me the language/runtime you’re using and I’ll draft it. Short checklist to try immediately • Add logging/wrapper around

end_call

to capture caller stack. • Log VAD outputs and temporarily disable silence-based disconnects. • Search logs for exceptions or tool invocations that precede the shutdown. • Run an isolated test with continuous speech and verbose logs. If you send one recent log snippet (the last 60–90s before the hang-up) or tell me your runtime language, I’ll give an exact wrapper snippet and show what lines to look for to identify the source of

end_call

. , with interactive elements