#hello hoping ya all good , i wanted some help with my number configuration. i have a provider manif

1 messages · Page 1 of 1 (latest)

gritty moonBOT
#
AI-generated Answer for thed99

Thanks for the detail — here’s what to check based on the official ElevenLabs SIP trunking docs.

What must be true for stable SIP calling

  • Transport: ElevenLabs supports SIP signaling over TCP or TLS only (UDP signaling is not available). For TLS use 5061; for TCP use 5060. Ensure your provider never falls back to UDP for signaling. (elevenlabs.io)
  • FQDN: sip.rtc.elevenlabs.io is correct for the default environment. (elevenlabs.io)
  • Codecs: Use G.711 (PCMA/“alaw” or PCMU) or G.722. Calls can drop if an unsupported codec is negotiated. (elevenlabs.io)
  • Media/RTP: RTP is over UDP. If your carrier enforces SRTP, set “Media Encryption” to Required; if they don’t support SRTP, use Allowed or Disabled. A mismatch (e.g., ElevenLabs Required but carrier sends plain RTP) can terminate calls mid‑conversation. (elevenlabs.io)

Why your call might end after you speak

  • Transport mismatch: If the carrier “only supports UDP and TLS,” make sure all signaling is actually over TLS (no UDP attempts). ElevenLabs does not support UDP signaling, which can cause sudden terminations. (elevenlabs.io)
  • Media encryption/codec negotiation: If SRTP or an unsupported codec is negotiated after answer, carriers/SBCs may send BYE. Start with TLS transport + Media Encryption = Allowed and codecs limited to PCMA (G.711 A‑law) on your side to confirm stability, then tighten to Required SRTP if supported. (elevenlabs.io)
  • Agent tools ending calls: You already disabled end_call. Also check (or temporarily disable) Voicemail Detection — it can end calls automatically if it (mis)detects voicemail. (elevenlabs.io)

Immediate steps to try

  1. In the ElevenLabs Number (SIP trunk) settings: set Transport Type = TLS, Media Encryption = Allowed (test), then Required (if your provider confirms SRTP). Keep the Address as sip.rtc.elevenlabs.io (no “sip:” prefix). (elevenlabs.io)
  2. On your carrier/SBC: restrict codecs to G.711 A‑law (and/or G.722) only during testing. (elevenlabs.io)
  3. Verify signaling path: confirm every INVITE/UPDATE/BYE is over TLS:5061 and that no UDP signaling is attempted (UDP signaling isn’t supported). (elevenlabs.io)
  4. Check ElevenLabs Call History for the exact failure reason/error string for the dropped calls. This will tell you whether the platform or the carrier ended the call. (help.elevenlabs.io)
  5. If your provider enforces IP allow‑listing, consider requesting the Static IP SIP endpoints (sip‑static.rtc.elevenlabs.io) to simplify ACLs. (elevenlabs.io)

If this continues, please share with support: time of call, your ElevenLabs phone number ID, carrier trunk name, and (if possible) the SIP error seen in Call History

lyric cradle
#

for my codecs i only have alaw , ulaw and g729 ; i cant confirm manifone is my provider i dont have a console or anything ; i have this interrupting the agent while he is talking "Client disconnected: 1000"

gritty moonBOT
#
AI-generated Answer for thed99

Short answer

  • Codecs: ElevenLabs SIP supports G.711 (A‑law/μ‑law) and G.722. G.729 is not supported. Configure your trunk to prefer PCMA/PCMU (and/or G.722 if your carrier supports it) and disable G.729. (elevenlabs.io)
  • SIP signaling transport: Only TCP or TLS are supported for SIP signaling; SIP over UDP is not available. Use TCP:5060 or TLS:5061. If your provider can’t do TCP/TLS for SIP signaling, calls will fail/tear down. (elevenlabs.io)
  • Inbound FQDN: Use sip.rtc.elevenlabs.io for inbound SIP; examples in our provider guides show TCP transport with that FQDN. For TLS, use port 5061. Enterprise customers needing IP allowlisting can use sip-static.rtc.elevenlabs.io. (elevenlabs.io)
  • RTP/media: Ensure UDP RTP is open end‑to‑end (typical wide range like 10000–60000) and that NAT/SRTP settings match both ends; one‑way/no audio can trigger early call teardown. If SRTP “Required” causes issues with your carrier, test with “Allowed.” (elevenlabs.io)

About “Client disconnected: 1000”

  • We don’t have an official mapping of that log line in the public docs. Note that our WebSocket connections auto‑close after 20 seconds of inactivity, which results in a normal closure; if your SIP leg drops or goes silent, you may see a normal close. Please verify your SIP side isn’t sending BYE or hitting media timeouts. (elevenlabs.io)

Recommended next checks

Sources:
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
Telnyx SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
Generate audio in real-time | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
How can I contact support? – ElevenLabs

lyric cradle
#

so ineed to set up a webhook for SIP trunk that will give a conversation_initiation_client_data to 11labs?

gritty moonBOT
#
AI-generated Answer for thed99

Short answer: Yes. To inject dynamic variables/overrides at call start for SIP‑trunked inbound calls, you should enable and implement the pre‑call webhook and have it return a conversation_initiation_client_data object.

What to do

  • Configure the webhook URL in Agents Platform settings and enable “Fetch conversation initiation data” on your agent. Then have your endpoint return type: conversation_initiation_client_data with optional conversation_config_override and dynamic_variables.
  • For SIP trunks specifically, include call metadata in your SIP INVITE so the platform can pass it into the pre‑call webhook. Supported headers: X-CALL-ID and X-CALLER-ID; Twilio’s sip.twilio.callSid is accepted as a fallback. These values become available in the pre‑call webhook and as system dynamic variables.

Notes

  • The conversation_initiation_client_data schema is documented here (fields like conversation_config_override, dynamic_variables, user_id).
  • If you also need post‑call data, the post‑call webhook payload includes conversation_initiation_client_data for auditing/analysis.

If you need exact request parameters for Twilio vs. SIP, the Twilio flow includes caller_id/agent_id/called_number/call_sid; for SIP the IDs are derived from the SIP headers above.

lyric cradle
#

i dont understand how is this going to solve my problem of call terminating anormally?

gritty moonBOT
#
AI-generated Answer for thed99

Short answer: it won’t. The “conversation_initiation_client_data” webhook is for personalizing the call (passing dynamic variables/overrides before the agent speaks). It does not control SIP signaling, RTP media, or call stability. (elevenlabs.io)

What will affect abnormal terminations (and what to check)

  • Transport: Only TCP or TLS are supported for SIP signaling; UDP transport is not available. Ensure your trunk never falls back to UDP and that you’re actually using TLS on 5061 (or test TCP on 5060). (elevenlabs.io)
  • Codecs: ElevenLabs SIP supports G.711 (A-law/ÎĽ-law) and G.722. If your side negotiates G.729 at any point, expect failures/no audio. Force G.711 or G.722 only. (elevenlabs.io)
  • Media/RTP: If the call connects then drops while speaking, it’s often RTP-related. Open UDP for RTP media (typically 10000–60000), check NAT, and align SRTP settings. If SRTP is set to “Required,” confirm your provider supports it or test with “Allowed” to isolate. (elevenlabs.io)
  • TLS specifics: Validate your provider’s TLS certs and ciphers. If issues persist, try TCP temporarily to isolate TLS problems. (elevenlabs.io)
  • Load balancing/IPs: Traffic can originate from multiple SIP servers behind sip.rtc.elevenlabs.io. Avoid pinning to a single IP; if you must allowlist, request the static endpoint. (elevenlabs.io)

Helpful for troubleshooting (not a fix)

  • Include X-CALL-ID (and X-CALLER-ID) so call metadata is traceable in the pre-call webhook and logs, which helps diagnose drops. (elevenlabs.io)

If the problem continues after the checks above, please open a support ticket and include timestamps, your SIP traces, and the X-CALL-ID you sent so we can investigate the specific hang-ups. (help.elevenlabs.io)

Sources:
Twilio personalization | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
How can I contact support? – ElevenLabs

lyric cradle
#

but didnt you say it times out or something ?

gritty moonBOT
#
AI-generated Answer for thed99

Short answer: there are timeouts in different parts of the stack, but the ones documented are not what hangs up SIP calls mid‑sentence.

  • WebSocket inactivity timeout: our realtime/TTS WebSocket closes after 20s of inactivity by default (configurable up to 180s via inactivity_timeout). This applies to WebSocket clients, not SIP trunk calls. (elevenlabs.io)
  • Agent “turn timeout”: this only controls how long the agent waits in silence before prompting again. It does not end the call. (elevenlabs.io)

For SIP trunking call drops, use the SIP docs/troubleshooting:

  • Signaling transport: UDP signaling is not supported; use TCP/TLS (you’re on TLS:5061, which is correct). (elevenlabs.io)
  • Codecs: ElevenLabs SIP supports G.711 or G.722. G.729 isn’t supported—ensure your trunk negotiates PCMA/PCMU (or G.722). (elevenlabs.io)
  • RTP media: mid‑call drops while speaking often indicate RTP/firewall issues. Open UDP for RTP (typically 10000–60000) and check NAT/SRTP settings per your encryption choice. (elevenlabs.io)
  • Endpoint/FQDN and ports: sip.rtc.elevenlabs.io behind load balancing; allow TLS 5061 (and TCP 5060 if used). IPs may vary due to distributed infra. (elevenlabs.io)

Re your webhook question: conversation_initiation_client_data is for personalization (dynamic variables/overrides) at conversation start. It won’t by itself resolve premature hangups. For SIP trunks, you can pass X-CALL-ID and X-CALLER-ID so they’re available to your pre‑call webhook and system variables. (elevenlabs.io)

Next checks:

  • Look in Call History for the exact failure reason if one was recorded. (help.elevenlabs.io)
  • If you disabled the end_call tool, drops are likely transport/media, not an agent‑initiated end. Keep TLS on, prefer G.711, and verify RTP reachability as above. (elevenlabs.io)

If you want, share a SIP trace (INVITE/200 OK/ACK, SDP, and RTP flow) and I can point to the exact mismatch per the docs.

Sources:
Generate audio in real-time | ElevenLabs Documentation
Conversation flow | 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

lyric cradle
#

so it is things on manifone side, give me a texte in french to ask them properly to solve this it is urgent