#Hello Team. We have an agent set up, no issue with the outbound calls, but on inbound calls, the ca
1 messages · Page 1 of 1 (latest)
Thanks for the details. “Outbound OK but inbound connects then immediately drops” usually points to setup on the phone number or call-init path. Please check the following (most common first):
- Make sure the number actually supports inbound. Twilio “Verified Caller IDs” are outbound-only; only Twilio numbers you own support inbound. In the Phone Numbers tab, or via API, verify supports_inbound = true. If it’s a verified caller ID, inbound will fail. (elevenlabs.io)
- Ensure the phone number is assigned to an agent. Inbound-capable numbers must be explicitly assigned; otherwise inbound calls won’t be handled. You can confirm assignment in the dashboard or via GET /v1/convai/phone-numbers/:id (assigned_agent). (elevenlabs.io)
- Check the Call History for the exact failure reason (red error). Common causes include: “Missing required dynamic variables …” and “Agent has exceeded its daily call limit …” Both will cause calls to end immediately. (help.elevenlabs.io)
- If you enabled Twilio personalization (inbound webhook), your webhook must return all required dynamic_variables within the timeout; missing required variables typically results in no transcript and an early hangup. (elevenlabs.io)
- If you’re using your own Twilio stack with the Register Call flow, ensure your server calls ElevenLabs’ register call endpoint and returns the provided TwiML back to Twilio for the WebSocket bridge; otherwise Twilio will end the call. (elevenlabs.io)
- If you’re using a SIP trunk, verify transport and networking: use TCP/TLS (UDP not currently available), open the appropriate ports, and confirm trunk auth/hostname. Connection issues here commonly present as instant disconnects. (elevenlabs.io)
If you share which integration you’re using (native Twilio import, Register Call, or SIP trunk) and a recent callSid/conversation_id, I can point you to the exact fix path. (elevenlabs.io)
Sources:
Twilio native integration | ElevenLabs Documentation
Twilio native integration | ElevenLabs Documentation
Where can I locate the reason for my call failing? – ElevenLabs
Twilio personalization | ElevenLabs Documentation
Register Twilio calls | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
Twilio native integration | ElevenLabs Documentation
SIP trunk, but not the ID
If you’re sending the INVITE to the ElevenLabs SIP domain without an identifier (e.g., sip@sip.rtc.elevenlabs.io:5060), the call will connect and then terminate immediately. You must include an identifier (typically the E.164 DID you want to route) in the Request-URI, for example:
- sip:+14155551234@sip.rtc.elevenlabs.io:5060;transport=tcp
Any string identifier is accepted, but it cannot be omitted. This is a common setup mistake. (elevenlabs.io)
Also confirm:
- The SIP-trunked phone number is imported in the Agents Platform and assigned to the agent that should receive inbound calls. (elevenlabs.io)
- Signaling/ports match your transport (TCP 5060 or TLS 5061), and your trunk supports G.711 or G.722. (elevenlabs.io)
If you share the exact Request-URI you’re sending, I can confirm it matches the required format. For background on non-Twilio numbers via SIP trunking, see the help article. (help.elevenlabs.io)
Sources:
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
Can I connect a non-Twilio phone to ElevenLabs Agents (formerly Conversational AI)? – ElevenLabs
lets say im sending
To: sip:31203694169@sip.rtc.elevenlabs.io:5060;transport=tcp
From: sip:443300016469@sip.nyc.didlogic.net
Short answer: your To URI format is correct, but the identifier must exactly match how you imported the phone number in the Agents dashboard. If you imported +31203694169, you must dial:
To: sip:+31203694169@sip.rtc.elevenlabs.io:5060;transport=tcp
If you imported it without the +, dial it without the +. A mismatch prevents routing and can look like an instant connect-then-drop. (elevenlabs.io)
Details to check:
- Required To format: sip:identifier@sip.rtc.elevenlabs.io:5060;transport=tcp, where identifier is your phone number (or any string you chose) and must match your imported “Phone Number” exactly (including the leading + if you used it). (elevenlabs.io)
- From header: From: sip:443300016469@sip.nyc.didlogic.net is fine; it isn’t used for routing on our side. If you want the caller ID available to webhooks/agent, include custom headers like X-CALLER-ID (and optionally X-CALL-ID) in the INVITE. Twilio’s sip.twilio.callSid is also recognized as a fallback. (elevenlabs.io)
- Transport/ports: Use TCP 5060 (or TLS 5061 if you configure TLS). UDP is not supported. (elevenlabs.io)
- Codecs: Make sure your trunk negotiates G.711 or G.722. (elevenlabs.io)
- Assignment: Ensure the imported SIP-trunk number is assigned to an agent in Phone Numbers → Assign Agent. (elevenlabs.io)
- If it still fails: check Calls → Call History for the exact failure reason. (help.elevenlabs.io)
Given your example, if the number was imported as +31203694169, change your To to sip:+31203694169@sip.rtc.elevenlabs.io:5060;transport=tcp and keep the From as-is (optionally add X-CALLER-ID: 443300016469). (elevenlabs.io)
Sources:
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
Where can I locate the reason for my call failing? – ElevenLabs
SIP trunking | ElevenLabs Documentation
what are the sip servers that the elevenlabs is using
ElevenLabs SIP ingress/endpoints:
- Default (load-balanced): sip.rtc.elevenlabs.io (TCP 5060 or TLS 5061; UDP not supported). (elevenlabs.io)
- Enterprise static-IP endpoints (opt‑in):
- US/International: sip-static.rtc.elevenlabs.io
- EU residency: sip-static.rtc.eu.residency.elevenlabs.io
- India residency: sip-static.rtc.in.residency.elevenlabs.io
Note: static IPs are provided from a /24 block and require allowlisting. (elevenlabs.io)
FYI: ElevenLabs runs multiple SIP servers behind sip.rtc.elevenlabs.io; requests may originate from different IPs unless you use the static endpoints. (elevenlabs.io)
Sources:
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
Im not using twilio, im using DIDLogic
Got it—DIDLogic works via SIP trunking (no Twilio required).
Use this SIP endpoint
- INVITE destination: sip.rtc.elevenlabs.io
- TCP: port 5060
- TLS: port 5061
- UDP is not supported
- Your To URI must include an identifier (E.164 recommended). Example:
sip:+31203694169@sip.rtc.elevenlabs.io:5060
Transport can be set with ;transport=tcp as you showed.
Static-IP option (if DIDLogic requires allowlisting)
- Enterprise-only static endpoint: sip-static.rtc.elevenlabs.io
- Region-specific static endpoints are also available (EU/IN). Contact support to enable.
Other required settings
- Codecs: G.711 or G.722 (your side must support or resample).
- Auth: digest (username/password) or ACL (IP allowlist). Digest is recommended.
- In the ElevenLabs dashboard, import your DID as a SIP Trunk phone number and assign it to an agent before testing.
If inbound connects then drops immediately
- Verify you’re sending to 5060 (TCP) or 5061 (TLS) and not using UDP.
- Check TLS certificate validity if using TLS.
- Re-check digest/ACL auth settings on both ends.
- Review Call History in the dashboard to see the precise failure reason.
And to confirm: using non‑Twilio carriers like DIDLogic is supported through SIP trunking.
What configuration of the agent itself can be causing such an issue
Likeliest agent‑side causes of “connects then instantly disconnects” (per our docs):
- End Call tool firing at start: The End Call system tool is enabled by default for dashboard‑created agents. If your tool description or prompt makes the LLM call end_call immediately, the call will terminate. Temporarily disable the tool or remove custom end‑conditions to test. (elevenlabs.io)
- Transfer to Human triggered immediately: If the transfer_to_number tool is enabled with a rule that matches on call start (or with zero delay), the agent will attempt a transfer; depending on trunk capabilities (e.g., SIP REFER not allowed), this can present as an immediate drop. Verify transfer rules, method (Conference vs SIP REFER), and destinations. (elevenlabs.io)
- Agent transfer triggered immediately: Similar to human transfer, a transfer_to_agent rule with a condition that matches at call start or a 0 ms delay can move the session away or end it, appearing as a drop. Review rules and delays. (elevenlabs.io)
- Voicemail Detection ending the call: If voicemail detection is enabled and configured to end calls on detection, a false positive right after answer would terminate the call. Disable to test. (elevenlabs.io)
- Agent set to Chat Mode (text‑only): Agents configured for text‑only (chat mode) don’t use audio. Ensure the agent used for telephony is not in text‑only mode and no runtime override forces text_only=True. (elevenlabs.io)
Additionally, confirm the phone number is correctly mapped to the agent and the SIP identifier exactly matches your imported number format:
- The SIP INVITE must include an identifier (e.g., sip:+15551234567@sip.rtc.elevenlabs.io:5060); calling the domain without an identifier won’t route. (elevenlabs.io)
- The imported phone number must match the identifier format (with or without leading +) or routing will fail. Also ensure the SIP trunk number is assigned to the intended agent in the Phone Numbers page. (elevenlabs.io)
If you want, share which system tools are enabled on the agent and whether it’s in text‑only mode, and I can point to the exact toggles to adjust. (elevenlabs.io)
Sources:
End call | ElevenLabs Documentation
Transfer to human | ElevenLabs Documentation
Agent transfer | ElevenLabs Documentation
Voicemail detection | ElevenLabs Documentation
Chat Mode | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
End call | ElevenLabs Documentation
None of these cause the call to end instantly