We are currently running an inbound AI call setup for one of our clients (a dental practice in Nassau, Bahamas) and are looking to migrate from our current Telnyx configuration to a Twilio + Retell setup. I wanted to reach out to verify our migration plan before we proceed.
Current Setup (Telnyx):
The practice’s phone provider (Southworth, running a Vodia PBX) SIP trunks inbound calls over to Telnyx using credential-based authentication, which then routes to our AI agent. The trunk was configured using credential auth after an initial IP-auth attempt failed due to a From header formatting issue on Vodia’s side.
Intended Setup (Twilio + Retell):
Our standard flow for Retell deployments is as guided;
Create an elastic SIP trunk on Twilio with PSTN transfer and call transfers enabled
Add a termination URI and create a credential list to authenticate inbound INVITEs
Add Retell’s origination URI (sip:sip.retellai.com)
Assign a number to the trunk
On the Retell side, connect the number via SIP trunking using the termination URI and credentials
For this migration specifically, Southworth/Vodia would need to re-point their outbound trunk destination from Telnyx to the new Twilio termination URI and swap the credentials accordingly. The number and overall call flow otherwise remain the same.
Questions we’d like to verify:
Is our migration approach above correct, or is there anything we should account for when migrating an existing SIP trunk (on the phone providers side) from another carrier to Twilio?
For the return transfer path (agent transferring back to the practice), can you confirm the recommended approach for call transfers back to through this setup, keeping in mind we would like to avoid incurring international call charges?
If you could please clear this up for us, would be appreacited
Migration Approach:
Your plan is correct and aligns with the Twilio SIP trunking guide. The key steps are:
Create an elastic SIP trunk on Twilio with termination (credential auth or IP whitelisting) and origination set to sip:sip.retellai.com
Import the number into Retell with the termination URI and credentials
Southworth/Vodia re-points their outbound trunk to the new Twilio termination URI
One thing to note: if you plan outbound calls, you’ll need to whitelist Retell’s SIP SBC CIDR block 18.98.16.120/30 on the Twilio termination side, and for international dialing (Bahamas), enable the country under Twilio’s Voice Geographic Permissions → “Elastic SIP Trunking.”
Transfer Back to the Practice:
To avoid international PSTN charges on transfers back, you can set the transfer destination as a SIP URI (e.g., sip:username@domain) instead of an E.164 number. This routes the transfer over SIP directly back through the Vodia PBX rather than going out to PSTN. Both cold and warm transfers support SIP URI destinations as you can see transfer call docs. You’d configure the transfer tool’s destination as the practice’s SIP endpoint.
If SIP-based transfer isn’t feasible, the transfer would go through Twilio’s PSTN routing and international rates would apply on Twilio’s side.
Perfect, really appreciate the speedy response @shaw
We do indeed plan outbound calls, however we were planning on using Credential Based authentication over IP, so I think we’re good to go on that front without the whitelisting?
Secondly, I’ve gone ahead and enabled Bahamas under Twilio’s Voice Geographic Permissions.
Yes, you’re correct. for the termination setup (which handles outbound calls), you can either whitelist Retell’s IP CIDR block or create credential-based authentication. Since you’re going with credential auth, you don’t need to whitelist 18.98.16.120/30 — just make sure you supply the correct username and password when importing the number into Retell.
We have been moving forward with the migration and this is what the phone provider has to say:
We are getting request time out to access the service. Is it expecting communication from the Bahamas, is there any IP security that might blocking?
We are going to need to coordinate with the software support team as this is a new setup, and I don’t think its as easy as changing the host and login information .
In light of this, could you let me know what could be the cause behind them getting a request time out to access the service or how we can go about debugging this considering it is not my field of expertise
Also, is there any form of support we can reach out to that can help up with this setup directly?
Your phone provider may need to whitelist Retell’s IP blocks for SIP traffic. Retell’s SIP infrastructure uses these IPs:
IP block: 18.98.16.120/30 (All regions), 143.223.88.0/21 and 161.115.160.0/19 (certain US traffic)
SIP server: sip:sip.retellai.com
Supported transports: TCP (recommended), UDP, TLS
If the provider is in the Bahamas, their firewall or network may be blocking traffic to/from these IPs. They should whitelist the above IP ranges and ensure the correct transport method is configured.
The provider just informed us that they are seeing an error that 1XXXXXX0157 isn’t part of the Twilio account.
Can you confirm that 1XXXXXX0157 is part of the Twillio account?
The error I am getting is indicating that it is not.
This is actually a number on their side that receives overflow/after-hours calls, which are then routed via SIP to us.
Does this number need to exist on Twilio or require any additional setup? Or should calls be accepted as long as SIP authentication is correct?
We are unaware about whether the IP block was whitelisted since they havent responded to us on that as of yet, but I’d like to make sure of this not being a concern as well.
That makes sense, but isnt this number on their end?
They originally shared this number with us and we connected over SIP2SIP. To my understanding, this is a number that calls get redirected to when needed, that eventually uses their SIP Trunk to reach ours.
The number we have on our Twilio SIP Trunk and connected on retell is separate and different. Is this still a number I will need to have added on our Twilio somehow?
In a SIP-to-SIP scenario where their system sends calls to your SIP trunk, the number 1XXXXXX0157 is their number it doesn’t need to exist in your Twilio account.
The error “not part of the Twilio account” is likely coming from their Twilio setup. They need to ensure that number is properly configured on their SIP trunk to originate calls.