@AI Evy Hi, we have a confirmed SIP-level issue with inbound calls using an Australian number (+61). What we see: Inbound calls reach our carrier and PBX correctly. When the call is forwarded to Retell via Custom Telephony (SIP), Retell responds immediately with SIP 486 USER_BUSY. Call duration is ~1–2 seconds. Same PBX, same SIP trunk, same Retell agent: Spanish numbers work perfectly. Only the Australian DID fails. So this is not a carrier or PBX issue — the 486 USER_BUSY is generated by Retell. Question: Are Australian geographic numbers (+61) supported for inbound calls via Custom Telephony? Is there any country-based filtering or validation that could trigger a 486 response? Happy to share SIP traces if needed. Thanks!

Thanks for tagging me @Laia. I'll look through relevant sources and get back to you shortly.

@AI Evy Thanks for the detailed answer. Just to clarify, we already have SIP-level confirmation of where the issue occurs: Inbound calls to the Australian number reach our carrier and PBX correctly. When the PBX forwards the call to Retell via Custom Telephony (SIP), Retell responds immediately with SIP 486 USER_BUSY. Call attempts last ~1–2 seconds. The same PBX, SIP trunk, and Retell agent work perfectly with Spanish numbers. No concurrent calls, no agent saturation, no rate limits involved. Given that: 486 USER_BUSY is generated by the called platform, The rejection is immediate and deterministic, And the issue is number-specific (AU only), this rules out carrier issues, PBX configuration, and generic SIP misconfiguration. At this point, the key question is not general SIP behavior, but whether there is any internal validation, country-based handling, or unsupported-state logic for Australian (+61) inbound numbers in Retell’s Custom Telephony stack that could trigger an early 486 response. If needed, we can provide: Full SIP INVITE / response traces Exact timestamps of failed calls Comparison traces (ES number vs AU number) Could you please confirm whether this can be escalated for internal routing / number validation review on Retell’s side? Thanks.

Thanks for the follow-up, @Laia. I'll get back to you soon.

@AI Evy Thanks for sharing the references. After reviewing the documentation and related threads, I want to clarify a few points based strictly on observed behavior and existing reports: According to the Custom Telephony documentation, inbound calls via SIP should not be subject to the same geographic limitations as Retell-purchased numbers. In our case, inbound calls to an Australian DID (+61) are consistently rejected by Retell with SIP 486 USER_BUSY, immediately after INVITE. This happens deterministically and only for the AU number. The same PBX, SIP trunk, and Retell agent work without issue for Spanish numbers. No concurrency, rate limits, or agent availability issues are present. Additionally, we’ve seen very similar reports in the community: Inbound calls returning 486 USER_BUSY for connected Telnyx numbers. Cases where the rejection was traced to platform-side logic, not carrier or PBX configuration. Given that: 486 USER_BUSY is generated by the called platform, The issue is number-specific and country-specific, And similar behavior has already been reported by other users, this strongly suggests an internal validation, routing, or unsupported-state condition affecting certain inbound numbers (possibly AU +61) in the Custom Telephony stack. At this point, further carrier or PBX troubleshooting is unlikely to surface new information. Could this be escalated for: Internal inbound routing review, or Confirmation of any known limitations or unsupported states for Australian (+61) geographic numbers when using Custom Telephony? We can provide full SIP traces and precise timestamps if required. Thanks.

Thanks for the follow-up, @Laia. I'll get back to you soon.

@AI Evy Thanks for the clarification. Just to close the loop on the remaining points: The Australian number is correctly imported and has a valid inbound_agent_id assigned. (We have confirmed this, and inbound works immediately if we swap the number to an ES DID with the same agent.) In our case, inbound calls do reach Retell’s SIP endpoint and are explicitly rejected with SIP 486 USER_BUSY. This differs from the Telnyx/Turkey examples where calls never appeared to reach Retell or only returned provisional responses. The 486 USER_BUSY response is: Generated by Retell, Immediate (1–2 seconds), Deterministic, Number-specific (AU only), And occurs with no agent concurrency or saturation. At this point: Carrier origination is verified. PBX routing is verified. Number import and agent binding are verified. SIP signaling reaches Retell and receives a final response. This leaves internal inbound routing / validation logic as the only remaining variable. Even if this is not currently documented as a country-based restriction, the observed behavior strongly suggests an unsupported or blocked state for certain inbound numbers, and specifically for this AU (+61) DID. Could this be escalated to the telephony / routing team to verify: Whether AU geographic numbers are fully supported for inbound Custom Telephony, Or whether there is any internal handling that would intentionally return a 486 in this scenario? We’re happy to provide: Full anonymized SIP traces, Exact timestamps, Side-by-side comparison (ES vs AU). Thanks.

Thanks for the follow-up, @Laia. I'll get back to you soon.

@AI Evy Thanks, this is very helpful. Given the precedent you mentioned regarding cached inbound SIP routing / fallback agent state, this actually aligns very well with what we’re seeing: The AU number is correctly imported and bound to an inbound agent. The agent works immediately if we swap the number to an ES DID. Inbound SIP INVITEs reach Retell and are immediately rejected with SIP 486 USER_BUSY. The behavior is deterministic and number-specific. No carrier, PBX, or configuration issues remain. Based on this, it’s very plausible that this AU number is affected by a stale or invalid internal routing / fallback state, similar to the case where inbound calls were routed to a non-existent agent until routing was reset. Request: Could this AU number be checked for any cached inbound routing or fallback state and, if applicable, have its inbound SIP routing reset or reinitialized on Retell’s side? We’re happy to provide: Org ID Phone number Exact timestamps Full SIP traces Thanks — this seems like the most likely remaining cause.

Thanks for the follow-up, @Laia. I'll get back to you soon.