### Answer The

telephony_provider_permission_denied

error is an issue *on your side (the originating/from number side) *, not the destination side. [(1) ]() , [(2) ]() This disconnection reason represents cases where the SIP trunk authentication failed. ## Common causes and troubleshooting steps: 1. Incorrect SIP trunk credentials - Double-check that you provided the correct username and password when importing the number to Retell. [(3) ]() 2. Verify your configuration - Make sure you imported the right termination URI, username, and password. The username is different from the friendly name. , [(4) ]() 3. Check your termination settings - Verify your termination setting in your SIP trunking provider. [(3) ]() 4. Re-import if needed - If the configuration is incorrect, delete the imported number and re-import with the correct details. 5. Check provider logs - Review the logs in your telephony provider (Twilio, Telnyx, etc.) to see what error they report on their side. If you're using Twilio, ensure the termination SIP URI is correct and has no spaces, and that credentials match exactly. [(4) ]()

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

​ To learn more, see the sources I considered: [[1] Debug call disconnection](https://docs.retellai.com/reliability/debug-call-disconnect) [[2] Debug outbound connection issues](https://docs.retellai.com/reliability/debug-outbound-call) [[3] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) [[4] I’m trying to use a toll-free number (connected from Twilio through a SIP trunk)](https://retell.discourse.group/t/i-m-trying-to-use-a-toll-free-number-connected-from-twilio-through-a-sip-trunk/127) ​

@AI Evy yes but this agent has issue only calling certain numbers not all of them

### Answer If the

telephony_provider_permission_denied

error only occurs when calling certain numbers (like specific countries) while other calls work fine, this is likely a geographic permissions issue on your telephony provider's side rather than a general authentication problem. ## Steps to troubleshoot: 1. Check geographic permissions - In your telephony provider (e.g., Twilio) , ensure geographic permissions are enabled for the countries/regions you're trying to call. Search for "geo" or "Voice Geographic Permissions" in your provider's settings. [(1) ]() 2. Use a localized termination URI - If you're calling international numbers, try using a localized termination URI near your target region (e.g., Dublin or Frankfurt for UK calls) . [(2) ]() 3. Verify route configuration with your provider - A similar issue was reported where calls worked from a softphone but failed through Retell for certain destinations. The provider responded with "503 Destination is unreachable" even though the trunk worked for other calls. In that case, the provider needed to check and test the specific route. [(3) ]() 4. Check call history and detailed logs - Review the SIP error code and error message in the call detailed log for the specific failed calls, as this can help identify the root cause. [(4) ]() If the issue persists, open a ticket with your telephony provider to investigate why specific destinations are failing while others succeed.

​ To learn more, see the sources I considered: [[1] I’m trying to use a toll-free number (connected from Twilio through a SIP trunk)](https://retell.discourse.group/t/i-m-trying-to-use-a-toll-free-number-connected-from-twilio-through-a-sip-trunk/127) [[2] Telephony Provider Unavailable](https://discord.com/channels/1186424376300679209/1417453291922526270) [[3] The trunk is not functioning properly](https://discord.com/channels/1186424376300679209/1458771340680106026) [[4] Debug outbound connection issues](https://docs.retellai.com/reliability/debug-outbound-call) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer This is a known limitation when using Twilio with custom SIP trunking for warm transfers with the user's number as caller ID. [(1) ]() ## How Retell Handles Caller ID on Warm Transfers For warm transfers, Retell uses SIP DIAL and sets the

from

and

P-Asserted-Identity

headers to the user's number. [(2) ]() , [(3) ]() The issue you're experiencing is that Twilio enforces caller ID restrictions—you cannot use arbitrary numbers as caller ID; the number must be a Twilio number you own or a number you have verified with Twilio. [(1) ]() ## Does Retell Support Diversion or Remote-Party-ID Headers? Based on the available documentation, there is no mention of Retell supporting the Diversion header or Remote-Party-ID header as alternatives to the From header for caller ID presentation. The documentation only references setting

from

and

P-Asserted-Identity

headers for warm transfers. [(2) ]() , [(3) ]() ## Your Options 1. *Cold Transfer (SIP REFER) * - Retell Twilio numbers support showing the user's number on both warm and cold transfers. However, for custom telephony via SIP trunking, cold transfer using SIP REFER is the documented method that can preserve caller ID, though it's up to the telephony provider to support caller ID override for SIP REFER. [(2) ]() , [(3) ]() 2. Use Retell-Purchased Twilio Numbers - Us

ers have reported that warm transfers with "User's Number" as caller ID work correctly when using Retell-purchased numbers (with Twilio as provider) , but fail with custom Twilio SIP trunking. [(1) ]() 3. Custom SIP Headers - You can add custom SIP headers for call transfers, but the documentation explicitly notes that "Twilio for example, does not honor the custom SIP headers in the REFER request." [(4) ]() , [(5) ]() 4. Contact Twilio - Some users have been advised to check with Twilio support to see if they can unlock caller ID permissions for your account. [(1) ]() Unfortunately, the warm transfer + user's number as caller ID + custom Twilio SIP trunk combination appears to have this inherent limitation due to Twilio's anti-spoofing policies.

​ To learn more, see the sources I considered: [[1] Issue on Warm Transfer with Users Number as Caller ID](https://discord.com/channels/1186424376300679209/1433255316186992801) [[2] Transfer call](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[3] Call Transfer Node](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[4] Set & parse custom SIP headers](https://docs.retellai.com/build/telephony/sip-headers) [[5] Help on Twilio DID questions](https://retell.discourse.group/t/help-on-twilio-did-questions/24) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer The TTS (Text-to-Speech) quality issues you're describing—slurring, clipping, and inconsistent pacing when reading phone numbers—can often be addressed through TTS provider selection and configuration adjustments. ## TTS Provider Considerations Different TTS providers have varying strengths when it comes to pacing and tone consistency: [(1) ]() - **MiniMax**: Offers the most consistent tone and rarely has pacing/tone quirks - **ElevenLabs**: Most natural sounding, but you may occasionally notice small pacing/tone quirks - **Cartesia**: Natural sounding, but pacing/tone can sometimes be less consistent than ElevenLabs If you need the most consistent tone and pacing (which is important for reading numbers clearly) , MiniMax may be worth trying. ## Additional Troubleshooting Steps 1. Adjust voice response speed - If your agent is talking too fast, the TTS might produce unclear output. You can adjust the voice response speed in the voice model settings or prompt. [(2) ]() 2. Switch TTS providers - If you notice quality issues, you can switch to another TTS provider directly. [(3) ]() 3. Check TTS latency - TTS latency details are available in call history and the Get-call API. Higher-than-usual TTS latency can sometimes correlate with quality issues. 4. Format the phone number in your prompt - Consider instructing the agent to read numbers with pauses between digits (e.g., "read each digit slowly with a brief pause between them") . If issues persist after trying different TTS providers and adjusting speed settings, I'd recommend reaching out to support for further investigation.

​ To learn more, see the sources I considered: [[1] TTS provider comparison](https://docs.retellai.com/build/tts-provider-comparison) [[2] TTS](https://discord.com/channels/1186424376300679209/1387743989490389052) [[3] Batch Calling, New Docs, and More Improvements!](https://www.retellai.com/changelog/batch-calling-new-docs-and-more-improvements) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

​ To learn more, see the sources I considered: [[1] Discord message from @bright_fox_24237 on 2026-01-16](https://discord.com/channels/1186424376300679209/1294891368505937952/1461653726334029885) [[2] Discord message from @pablo_63994 on 2025-12-01](https://discord.com/channels/1186424376300679209/1294891368505937952/1445123015795802186) ​

### Answer Based on the sources I have available, I don't see any community reports specifically about TTS audio quality issues with phone number articulation (slurring, clipping, or inconsistent pacing when reading back phone numbers) . The Discord messages I can access discuss other issues such as: -

telephony_provider_permission_denied

errors with Telnyx numbers [(1) ]() - Custom voice integration problems with ElevenLabs [(2) ]() - Pronunciation issues with specific words/acronyms (like "IQA") [(1) ]() However, none of these match the specific TTS behavior you're describing where digits are slurred, clipped, or read too fast. Since I don't have direct evidence of others reporting this exact issue in the available sources, I'd recommend: 1. Opening a support ticket or posting in the bug-report channel with specific call IDs where this occurred 2. Including which TTS provider and voice you're using 3. Sharing audio samples if possible This would help the Retell team investigate whether this is a known issue or something specific to your configuration.

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer Based on the available documentation, there is no partial/merge update capability for the

general_tools

array. The PATCH

/update-retell-llm/{llm_id}

endpoint replaces the entire

general_tools

array with what you provide. [(1) ]() ## Confirmed Behavior A community member reported a similar finding: when exporting and re-importing an agent's LLM configuration, the

general_tools

array must be sent in its entirety. They noted that "Export of the agent's llm section has general_tools and does not follow the same format as the sdk / api for updating" and had to convert certain fields to make the import work. [(2) ]() ## Recommended Approach Re-uploading the full

general_tools

array is the standard practice. Your workflow should be: 1. Retrieve the current LLM configuration using the GET endpoint or

client.llm.list()

[(3) ]() 2. Modify the specific tool in your local copy of the

general_tools

array 3. Send the complete updated array via PATCH

javascript
import Retell from 'retell-sdk';
const client = new Retell({
  apiKey: 'YOUR_RETELL_API_KEY',
}) ;
const llmResponses = await client.llm.list() ;

This retrieves all your LLMs so you can extract the current

general_tools

, modify the specific tool, and then send the full array back in your update request.

​ To learn more, see the sources I considered: [[1] Update Retell LLM](https://docs.retellai.com/api-references/update-retell-llm) [[2] Call status webhook for child calls post-transfer](https://discord.com/channels/1186424376300679209/1386823294589861898) [[3] List Retell LLMs](https://docs.retellai.com/api-references/list-retell-llms) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.