#when i use the api for calls the conversation often just drops

1 messages · Page 1 of 1 (latest)

daring duneBOT
#
AI-generated Answer for nik_qk

Short answer: most “dropped” calls come from inactivity timeouts, plan/concurrency limits, telephony/network setup issues, or an ongoing/recent platform incident. Here’s how to isolate and fix each—with links to the official docs.

  • Check the exact failure reason first

    • Open Calls → Call History; failed calls show a red error explaining why (e.g., daily call limit, missing dynamic variables, allowlist, etc.). If there’s no error message, contact Support via the form. (help.elevenlabs.io)

  • Prevent inactivity-related disconnects

    • WebSocket inactivity timeout defaults to 20 seconds; you can raise it (max 180 s) with the inactivity_timeout query parameter on the WS endpoint. (elevenlabs.io)
    • Conversation contexts also auto-close after 20 seconds of inactivity; you can keep a context alive by periodically sending an empty text message, and you may extend this inactivity window up to 180 s. (elevenlabs.io)
    • If you are using an agent, review Turn Timeout (Advanced tab). Turn timeouts are 1–30 s and control how long the agent waits in silence before prompting—too short can make the flow feel like it “stops responding.” (elevenlabs.io)

  • Verify you’re not hitting plan/concurrency limits

    • Conversational AI concurrency is per workspace: Free 4, Starter 6, Creator 10, Pro 20, Scale 30, Business 30. Exceeding it can cause call failures. (help.elevenlabs.io)
    • 429 errors indicate either too_many_concurrent_requests (you hit concurrency) or system_busy (temporary load; retry). (help.elevenlabs.io)

  • If using telephony, confirm integration details

    • Twilio native integration is recommended for inbound; custom server is for outbound. Mismatched settings or blocked WS can cause early disconnects. Ensure ÎĽ-law 8 kHz is set for both input and output when using the custom server, and verify your server/WebSocket is reachable. (elevenlabs.io)
    • For SIP trunking, allow SIP signaling to sip.rtc.elevenlabs.io (34.49.132.122) and RTP UDP media ports; NAT/firewall issues can cause one‑way audio or drops. (elevenlabs.io)

  • Rule out service incidents

    • If drops are clustered in time, check the Status page; there were recent resolved incidents affecting Conversational AI calling/turn‑taking (e.g., Jun 3, Jun 9, Jul 23, and Jul 2 for Twilio numbers). (status.elevenlabs.io)

Optional tuning if your agent uses tools

  • Long-running tool calls can stall a turn; tool timeouts are configurable per tool, and past timeout issues were fixed in February 2025. Review and set appropriate tool timeouts. (elevenlabs.io)

If you can share which path you’re using (native Twilio, custom server, or SIP) and whether you see 429s or inactivity in logs, I can map the exact settings to change and provide example WS parameters. (help.elevenlabs.io)

jade torrent
#

the thing is they dont get flagged as an error they are successfull but our user say that the calls just drop sometimes directly after the first sentence sometimes after a few minutes

daring duneBOT
#
AI-generated Answer for nik_qk

Thanks—that symptom (no API error, but the voice call stops after a sentence or a few minutes) most often traces to configuration or timeout behavior. Here are the checks that are documented to cause early call termination or “go silent” behavior:

  1. Make sure the agent isn’t ASR‑only for telephony
  • Telephony calls require agent_response and audio client events. If they’re disabled, calls can connect yet fail/stop. Enable those client events in the agent settings. This requirement was also called out during a June 3, 2025 incident.
  1. Verify the End Call system tool isn’t firing prematurely
  • Agents created in the dashboard include the End Call tool by default; API/SDK agents can add it manually. If your prompt or the LLM logic triggers it (e.g., thinks the task is done), the platform will hang up without an error. Either remove it or tighten its conditions.
  1. If you run outbound campaigns, check Voicemail Detection
  • With voicemail detection enabled, the agent can terminate the call quickly after detecting an answering machine. These events are logged in conversation history/batch results, so verify whether detection is triggering on “dropped” calls.
  1. WebSocket inactivity/context timeouts (custom server paths)
  • If you’re bridging telephony via your own server to our WebSocket, note defaults: contexts time out after 20s; the WebSocket inactivity timeout defaults to 20s (configurable up to 180s). You must respond to ping events and/or keep the context alive (send empty text) or extend inactivity_timeout. Otherwise audio may stop mid‑call.
  1. Conversation flow timeouts
  • Very short “Turn Timeout” values can cause the agent to quickly reprompt or pause if the user is silent, which can be perceived as the call stalling. Review and lengthen if needed. (This setting doesn’t hang up by itself but affects perceived continuity.)
  1. Inspect each affected call in Call History / Conversations API
  • Use Call History and the Conversations API to see status, transcript, duration, whether audio was produced, and (for tools like voicemail detection) logged events. This helps confirm whether End Call or voicemail detection was triggered vs. a transport/timeout.
  1. Rule out transient platform incidents
  • There were recent resolved incidents affecting turn‑taking/conversational calls (June 9 and July 23, 2025). If your drop times align, that may explain intermittent behavior; otherwise treat them as config/timeouts.

If you share a recent conversation_id that “dropped,” you can verify in the conversation details whether a system tool ended the call, whether response audio was generated, and the exact duration before termination.

jade torrent
#

tell me more about 2 and 5 and 7

daring duneBOT
#
AI-generated Answer for nik_qk

I don’t have the list you’re referencing—can you paste what items 2, 5 and 7 were?

In case you meant common drop causes we discussed earlier, here are the most relevant docs to review:

  • WebSocket inactivity timeouts: default 20s; you can extend to 180s with the inactivity_timeout query param. Keep the socket alive by periodically sending a single space character " " (empty string closes the socket). (elevenlabs.io)
  • Context/turn timeouts: multi‑context TTS contexts auto‑close after ~20s unless you send an empty text to reset; Conversational AI “Turn Timeout” (1–30s) controls how long the agent waits during user silence. (elevenlabs.io)
  • Agent‑initiated hang‑ups: the End Call system tool (enabled by default in dashboard‑created agents) lets the agent end the call; check your prompts/conditions so it doesn’t trigger prematurely. (elevenlabs.io)

If these aren’t the items you meant, please tell me what 2, 5 and 7 refer to and I’ll go deeper on exactly those.

Sources:
Convert text to speech in real-time | ElevenLabs Documentation
Conversational agents
End call | ElevenLabs Documentation

jade torrent
#

but theoretical we arent using it for telephones, the most obvious perpetrator is the end call function isnt it?

daring duneBOT
#
AI-generated Answer for nik_qk

Short answer: Possibly—but it isn’t telephony‑specific, and there are a couple of equally likely causes.

What the End Call tool does

  • End Call is a system tool that terminates the conversation/session (not just phone calls). It’s enabled by default for agents created in the dashboard; if you create agents via API/SDK you only get it if you add it. If present, the LLM can invoke it based on your prompts/conditions and the session will end without an API error. (elevenlabs.io)

Other common causes of “dropped” sessions (non‑telephony)

  • Client code calling endSession: the JS Client SDK exposes conversation.endSession(), which immediately disconnects the session. Audit your UI/event handlers for any accidental calls. (elevenlabs.io)
  • Context/websocket inactivity timeouts: with the multi‑context WebSocket API, contexts auto‑close by default after inactivity (20s by default; websocket inactivity up to 180s). Send a keep‑alive (empty text) or keep audio flowing to prevent silent closures. (elevenlabs.io)

How to confirm and mitigate

  • Check whether your agent includes the end_call system tool; remove it (API: don’t include it in built‑in tools) or tighten its prompt/conditions and retest. (elevenlabs.io)
  • Verify your client never calls endSession except on explicit user action. (elevenlabs.io)
  • Inspect conversation records via the Conversations API (status, transcript, duration) to correlate when/why the session ended. (elevenlabs.io)

If you want better mid‑session resilience in the browser, consider using the new WebRTC connection type, which improves recovery and audio handling; it’s a drop‑in switch in the client. (elevenlabs.io)

Sources:
System tools | ElevenLabs Documentation
Client SDK - ElevenLabs
Conversational agents
System tools | ElevenLabs Documentation
Client SDK - ElevenLabs
Get conversation details | ElevenLabs Documentation
ElevenLabs Conversational AI now supports WebRTC | ElevenLabs

jade torrent
#

so it could also be a problem comming from my code?