I am experiencing an issue with inbound calling on my imported Telnyx number.
Current situation:
When Termination SIP URI is set to sip.telnyx.com → Outbound calls work fine, but inbound calls return busy (486)
When Termination SIP URI is set to retell-ai-clinic.sip.telnyx.com (my specific Telnyx subdomain) → Inbound still returns busy AND outbound stops working entirely
Setup details:
Provider: Telnyx Elastic SIP Trunk
SIP Connection: retell-ai-clinic
Number: +16674218313
FQDN in Telnyx:(SRV record) ✓
Inbound agent: assigned and published ✓
Codecs: G722, G711U, G711A ✓
Transport: TCP ✓
SIP Region: Asia (Beta) ✓
The inbound call never appears in Retell Call History, which suggests the call is not reaching Retell at all.
Could you please advise on the correct configuration to get inbound calls working?
your inbound issue is on the Telnyx side, not the termination SIP URI. The Termination SIP URI in Retell should remain sip.telnyx.com (or your region-localized Telnyx FQDN) — that’s only used for outbound. That’s why switching it to your subdomain breaks outbound.
For inbound to reach Retell, in Telnyx you need:
FQDN added to the trunk = sip.retellai.com with SRV as the DNS record type (this is what routes inbound to Retell).
The number must be assigned/moved to this trunk.
Inbound settings: +E.164 number format, codecs G722, G711U, G711A, transport TCP, and your SIP region selected.
A 486 Busy on inbound that never reaches Retell Call History usually means Telnyx isn’t forwarding the call to sip.retellai.com — verify the FQDN entry (sip.retellai.com, SRV) is on the trunk and the number is attached to that same trunk. Also make sure the number has an inbound agent assigned in Retell.
The 486 is being returned upstream of Retell (almost certainly by Telnyx, most commonly: DID not assigned to the FQDN trunk, or Asia anchor site rejecting an out-of-region +1 NANP inbound). Could you please pull a Telnyx “SIP Call Flow” debug export for one failing inbound attempt? That will show exactly which Telnyx node returned the 486 and the Q.850 cause.
I’m unable to access a detailed SIP Call Flow debug export for inbound calls from the Telnyx dashboard. Telnyx is only showing the call logs on my side.
Based on the available logs, I can confirm the following:
Q.850 Cause Code: 17
Termination LRN: 6674021999
The logs still show the INVITE reaching sip.retellai.com and then receiving 486 User Busy. And I am using the Pakistani number for inbound; however, the outbound is working perfectly with the Pakistani number
Please let me know if there is any other specific information you would like me to collect from the Telnyx logs.
Hi Team!
Yesterday we discussed the issue, now we are waiting for your response
Please let me know once you have configured it. It will be really appreciated!
Thanks
Hey @ali.desndev could you please share a screenshot of the Telnyx call detail showing the 486 response and the Via headers that can help us confirm whether the 486 originated from our SBC or a Telnyx-internal hop. In the meantime as a quick A/B, can you temporarily switch the SIP region from Asia (Beta) to a GA region (US or EU) and place one inbound test. Thank You
Hi, I have attached the screenshots including the Via headers. I also changed the SIP region to US and tested again with an inbound call, but it is still returning a busy response (486), line busy. Thanks!
Hey @ali.desndev So, this confirms the issue is on the inbound binding of this DID inside your Telnyx account. Your outbound is fine because it uses a separately-configured Outbound Voice Profile. Can you check voice settings for this number.
Hi, I have attached the screenshots for reference. These confirm that our DID is properly assigned to the SIP connection, the SIP connection is correctly configured on the number, and the inbound settings are also configured correctly. We have also reviewed the authentication credentials (username/password) multiple times and they are correct.
Additionally, on the Telnyx side, the call logs/history show that the inbound call is received and forwarded successfully from Telnyx. This makes it appear that the issue may be on the Retell side, where the call is either not being identified correctly or not being accepted/answered properly.
Could you please check this further from your side? Thanks!
Hey @ali.desndev The SIP auth credentials are not relevant to this failure, those username/password fields authenticate Retell → Telnyx (outbound) traffic, which is why your outbound works.
The screenshots you sent confirm the DID is assigned to the retell-ai-clinic SIP Connection (good), and the Voice and Numbers tabs are configured. But the missing piece is on a different tab.
Can you share Authentication and routing tab? in the dm to me not here
here you’ll see Connection Type: Credentials / IP / FQDN. For Retell, this must be set to FQDN, and the FQDN list must contain:
If it’s currently set to Credentials, that is the bug, Telnyx is waiting for Retell to REGISTER (we don’t; we’re a static FQDN SBC), so it has no Address-of-Record to forward calls to and returns cause 17. If it’s already FQDN but the list is empty or contains a leftover host from a previous integration, that’s the same outcome.
Hey @ali.desndev From the info you gave us and checking on our side, there isn’t anything we can do on our side but you should contact Telnyx why The Terminating LRN 6674021999 does not match your DID’s NPA-NXX (667-421). Could you open a ticket with Telnyx support stating: “Inbound calls to +16674218313 on my account return 486 / Q.850 cause 17 with Terminating LRN 6674021999 (doesnt match NPA-NXX). Direction=Inbound CDRs are recorded but no INVITE leaves your network toward my configured FQDN (sip.retellai.com). Please verify the inbound number-to-Connection binding for this DID and provide a SIP Call Flow for a failing attempt showing which Telnyx node generated the 486.”
