when I am using call_initiation_webhook the call is running for 5 seconds and closing, it is happen | ElevenLabs | Page 1

versed lakeBOT Aug 20, 2025, 11:39 PM

#

AI-generated Answer for rohith_27334

Short answer
What you’re seeing is expected when using a “conversation initiation” (pre‑call) webhook with SIP trunks: Twilio inbound calls have a dialing window the platform explicitly uses to fetch your webhook in parallel, but generic SIP trunks don’t guarantee that grace period. If your initiation webhook is slow, the SIP side may tear the call down shortly after connect, which can look like a ~5‑second drop. ElevenLabs’ docs call out the Twilio dialing window and also recommend that initiation webhooks respond quickly. For SIP, pass caller identifiers via SIP headers and keep any pre‑call lookup minimal/fast. (elevenlabs.io)

What to do (verified steps)

Don’t rely on the Twilio‑only initiation flow for SIP trunks. The “fetch conversation initiation data” feature is documented for inbound Twilio numbers; with SIP trunks you should not assume the same dialing buffer exists. Keep the initiation webhook lightweight and fast. (elevenlabs.io)
For SIP trunks, include call identifiers in your SIP INVITE so your webhook can immediately personalize without extra round‑trips:
- Add X-CALL-ID and X-CALLER-ID headers (Twilio SIP has a fallback sip.twilio.callSid). These become available to your pre‑call webhook and as system dynamic variables. Use them to look up customer context quickly and return the initiation payload. (elevenlabs.io)
Verify SIP/RTP connectivity, since lack of media can also cause early hangups:
- Allow signaling on the transport/port you configured (TCP/TLS, typically 5060/5061).
- Allow RTP UDP media ports (e.g., 10000–60000) and avoid IP allowlisting that blocks ElevenLabs’ dynamic media IPs. (elevenlabs.io)
- If using TLS/SRTP, test with “Allowed” before “Required,” and confirm your provider’s certs and SRTP support. (elevenlabs.io)
- Ensure codec compatibility (G.711/G.722 as documented) to avoid no‑audio situations. (elevenlabs.io)
Check the Call History page for the exact failure reason/hangup code to confirm whether this is a webhook‑latency or media/signaling issue. (help.elevenlabs.io)

References

Twilio personalization (conversation initiation webhook behavior and timing expectations). (elevenlabs.io)
SIP trunking setup, headers for personalization, and troubleshooting (signaling, RTP ports, TLS/SRTP, codecs). (elevenlabs.io)
Call failure reasons in Call History. (help.elevenlabs.io)

If you want,

dapper plank Aug 21, 2025, 12:16 AM

#

on the client data I am getting the data from the webhook, the error on elevenlabs is "we have initiated the call but the response never reached the elevenlabs servers" but on telnyx the call says the elevenlabs has terminated the request

versed lakeBOT Aug 21, 2025, 12:16 AM

#

AI-generated Answer for rohith_27334

Short answer: The “call initiation” webhook you’re using is only documented for inbound Twilio calls. It isn’t documented for SIP trunking. For SIP trunks (e.g., Telnyx), pass any personalization/identifiers via SIP headers, not a call‑initiation webhook.

What the docs say

Twilio inbound “conversation initiation” webhook: ElevenLabs calls your endpoint during the Twilio dial/connection window; your endpoint must return conversation_initiation_client_data quickly. This flow is described only for Twilio. Ensure your endpoint responds within the timeout. (elevenlabs.io)
SIP trunking personalization: Include call metadata in SIP INVITE headers, e.g., X-CALL-ID and X-CALLER-ID. If you’re using Twilio Elastic SIP Trunking, sip.twilio.callSid is accepted as a fallback. The page references a “pre‑call webhook,” but only Twilio’s webhook is documented; for generic SIP providers you should rely on headers. (elevenlabs.io)
Outbound SIP calls (when ElevenLabs dials out): you can embed conversation_initiation_client_data directly in the POST /v1/convai/sip-trunk/outbound-call request. (elevenlabs.io)

Why Telnyx shows “terminated by ElevenLabs” while ElevenLabs shows “initiated but no response”
Per SIP trunking troubleshooting, this usually indicates signaling or policy mismatch. Verify the following against the docs:

Telnyx inbound target: FQDN sip.rtc.elevenlabs.io; SIP transport TCP (or TLS if you’ve enabled TLS). Destination number format +E.164. (elevenlabs.io)
Signaling reachability: allow SIP signaling on your chosen transport/port (TCP 5060 or TLS 5061). (elevenlabs.io)
No strict whitelisting of ElevenLabs signaling/media IPs: requests can come from multiple SIP servers behind sip.rtc.elevenlabs.io. If you must whitelist, contact support per the doc. (elevenlabs.io)
Authentication: prefer digest auth (username/password). If you use ACL/IP filtering, ensure Telnyx trusts ElevenLabs and vice‑versa. (elevenlabs.io)
Media/security alignment: if you set media encryption to Required but your provider profile doesn’t negotiate SRTP, calls can be torn down quickly. Test with Allowed (or Disabled) to isolate. (elevenlabs.io)
Codec expectations: ensure your trunk negotiates a supported codec (G.711 or G.722) or performs resampling as needed. (elevenlabs.io)

Where to see the exact failure reason

Check Call History in the ElevenLabs dashboard; failed calls show a red error explaining why the call ended or didn’t connect. (help.elevenlabs.io)

Actionable next steps

For SIP/Telnyx inbound: stop relying on a call‑initiation webhook; supply needed context via SIP headers (X-CALL-ID, X-CALLER-ID). (elevenlabs.io)
Recheck your Telnyx SIP connection per the ElevenLabs Telnyx guide (TCP transport, FQDN sip.rtc.elevenlabs.io, E.164, auth). (elevenlabs.io)
If ElevenLabs is making outbound calls to your Telnyx trunk

dapper plank Aug 21, 2025, 12:23 AM

#

how to pass sip headers x-cal-id and other one throughj telnyx

versed lakeBOT Aug 21, 2025, 12:23 AM

#

AI-generated Answer for rohith_27334

Short answer:

The documented headers are X-CALL-ID and X-CALLER-ID (not “x-cal-id”). Include them in the SIP INVITE when calling into ElevenLabs, and ElevenLabs will surface this metadata to your pre-call webhook and dynamic variables. If those aren’t present, ElevenLabs will only fall back to sip.twilio.callSid (Twilio-specific), which Telnyx will not set. (elevenlabs.io)

How to pass them with Telnyx:

Inbound (Telnyx ➜ ElevenLabs): Configure your Telnyx trunk to add custom SIP headers X-CALL-ID and X-CALLER-ID to the INVITE sent to ElevenLabs’ origination endpoint. ElevenLabs will read these headers on call setup. (ElevenLabs docs specify the accepted headers and that they must be present in the SIP INVITE.) (elevenlabs.io)
Outbound (ElevenLabs ➜ Telnyx): In the ElevenLabs dashboard, edit your SIP-trunked phone number and use “Add Header” to define any custom SIP headers you want ElevenLabs to include on outbound INVITEs to Telnyx. These custom headers are sent with all outbound calls. (elevenlabs.io)

Notes:

If your carrier requires different identifiers, ElevenLabs advises contacting support to register provider-specific headers. (elevenlabs.io)

Sources:
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation

dapper plank Aug 21, 2025, 12:26 AM

#

actually I haven't configured the outbound setup, do you think thats the issue

versed lakeBOT Aug 21, 2025, 12:26 AM

#

AI-generated Answer for rohith_27334

Short answer: No—missing “Outbound” settings would only affect calls that ElevenLabs initiates to your SIP trunk. Inbound SIP calls from your provider to ElevenLabs do not depend on the Outbound configuration.

What to check (from the SIP Trunking docs):

Transport: ElevenLabs supports SIP signaling over TCP or TLS; UDP signaling isn’t available. Ensure your provider (e.g., Telnyx) is sending INVITEs to ElevenLabs via TCP/TLS, not UDP. Also use the correct ports (5060 for TCP, 5061 for TLS). (elevenlabs.io)
Firewall/network: Allow SIP signaling on the chosen port and RTP media over UDP (typ. dynamic ports 10000–60000). Blocking these can cause early call teardown. (elevenlabs.io)
TLS specifics (if enabled): Validate certificates and try TCP to isolate TLS issues. (elevenlabs.io)
Inbound configuration: In the ElevenLabs dashboard, set the “Transport and encryption” for the SIP trunk so it matches what your provider uses for inbound calls. (elevenlabs.io)
Headers/metadata: If you pass call identity via SIP headers, use X-CALL-ID / X-CALLER-ID (or Twilio’s sip.twilio.callSid as a fallback). These map into pre-call metadata. (elevenlabs.io)

Reference lines:

Outbound settings specify where ElevenLabs sends calls it initiates (“Address … where the SIP INVITE is sent”); they don’t affect inbound trunks. (elevenlabs.io)
Connection and troubleshooting guidance (ports, transport, TLS, distributed SIP servers). (elevenlabs.io)

If you’re also using a conversation-initiation webhook, ensure it responds promptly to avoid delays during call setup (not Twilio-specific best practice). (elevenlabs.io)

dapper plank Aug 21, 2025, 12:36 AM

#

if I do general call its working but only for webhook attached calls its not working

versed lakeBOT Aug 21, 2025, 12:36 AM

#

AI-generated Answer for rohith_27334

Short answer: yes—this symptom is consistent with the call initiation webhook not responding correctly/quickly. With Twilio numbers, ElevenLabs explicitly fetches your initiation webhook “in parallel” during Twilio’s dialing period; with SIP trunks (e.g., Telnyx) there’s no such guarantee documented, so any slow/blocked/malformed webhook response can cause the call to fail even though “general” calls (no webhook) work. This is why you only see the issue on webhook‑attached SIP calls. (elevenlabs.io)

Checks and fixes (only from official docs):

Return the exact payload and a 200 immediately. Your endpoint must respond with a JSON body of type conversation_initiation_client_data (example structure shown in docs) and should return quickly to avoid delaying call handling. (elevenlabs.io)
Make sure ElevenLabs can reach your webhook. If you use IP allowlisting or a WAF, allow the documented static egress IPs for all ElevenLabs webhook services. (elevenlabs.io)
Validate you enabled the initiation webhook flow where applicable. For Twilio inbound, enable “fetch conversation initiation data” on the agent; for SIP trunking you still supply the same conversation_initiation_client_data payload, but you won’t get Twilio callSid fallback behavior. (elevenlabs.io)
For SIP trunking (Telnyx), pass caller metadata via SIP headers so it’s available to your webhook:
- Include X-CALL-ID and X-CALLER-ID in the SIP INVITE (and, if you forward metadata from your webhook, keep the same names). There is a fallback header sip.twilio.callSid, but that only helps on Twilio’s Elastic SIP—not Telnyx—so set the X-* headers explicitly. (elevenlabs.io)
Outbound setup isn’t required for inbound calls. Outbound trunk settings are only used when ElevenLabs initiates calls to your trunk; inbound calls from your trunk to ElevenLabs work with your origination path alone. (elevenlabs.io)

If after these changes you still see “initiated the call but the response never reached the servers,” focus on:

Fast path: immediately return a minimal valid conversation_initiation_client_data (you can omit overrides) and do any heavy work asynchronously. (elevenlabs.io)
Networking: confirm your firewall/WAF isn’t blocking the ElevenLabs webhook egress IPs. (elevenlabs.io)

Relevant docs:

Twilio call personalization (initiation webhook, response format, timing note). (elevenlabs.io)
Agent WebSockets request format (conversation_initiation_client_data structure). (elevenlabs.io)
Webhooks behavior and requirement to return 200 quickly. (elevenlabs.io)
Webhook egress IPs (apply across ElevenLabs webhook services). (elevenlabs.io)
SIP trunking (SIP headers X-CALL-ID/X-CALLER-ID and Twilio fallback header). (elevenlabs.io)

dapper plank Aug 21, 2025, 5:36 PM

#

actual problem is webhook is taking time in responding back to the call, in the mean time elevenlabs is closing connection why so. Can I increase time limit to wait for the webhook to respond

#when I am using call_initiation_webhook the call is running for 5 seconds and closing, it is happen