Some DIDs Immediately Return Busy (TargetBusy / DisabledByFwdRule) on 3CX v18

[Paul-2024]

Hi all,

I’m running 3CX Version 20, Update 6 Build 20.0.6.724, June 2025 with multiple SIP trunks from the same provider. Since this morning, only one of my DIDs will actually ring—calls to the others instantly return a busy tone.

Log Snippet

07/11/2025 12:43:17.268 PM    L:167.1[Line:10001<<CALLER_NUMBER{00000000-01db-f282-e6f8-9b29000002f3}] build target endpoint to EndCall.DisabledByFwdRule from Line:10001<<CALLER_NUMBER{00000000-01db-f282-e6f8-9b29000002f3} using source "DORCHESTER MA "<sip:[email protected]:5060;nf=e>

07/11/2025 12:43:17.269 PM    [CDR] Call(C:167): leg terminated: Line:10001<<CALLER_NUMBER{00000000-01db-f282-e6f8-9b29000002f3}, cause RouteBusy

07/11/2025 12:43:17.269 PM    L:167.2[Route:ROUTER@{}10001{00000000-01db-f282-e6f8-9b48000002f4}] segment terminated (RouteBusy) to L:167.1[Line:10001<<CALLER_NUMBER{00000000-01db-f282-e6f8-9b29000002f3}]

 

[Charles_3CX]

Regarding your question, please verify that the designations the DID's are set to are not busy, as the log indicates: cause RouteBusy.

 

[Paul-2024]

Regarding your question, please verify that the designations the DID's are set to are not busy, as the log indicates: cause RouteBusy.

Where exactly is that setting?

 

[Charles_3CX]

Please check the destination assigned to the DIDs, which you can view by navigating to Reports > Inbound Rules in the Admin Console.

Once you identify where each DID is routed, ensure that the destination (e.g., extension, ring group, or queue) is active and able to receive calls. For example, if the DIDs are routed to a queue, confirm that the assigned agents are logged in and available to take calls.

 

[Paul-2024]

I took a look at our Inbound Rules today and noticed a few oddities:

Only three trunks are listed, even though we have more configured in our system.

The main trunk—which is the only one currently passing calls—is not listed at all, despite functioning normally.

Of the three trunks that do appear, each one shows a blank destination.

Let me know if you need any additional details or logs from my end. I’m happy to assist with troubleshooting or to run any diagnostics you suggest, our offices are currently affected by this issue big time.

Thank you

 

[Charles_3CX]

We don't offer support via the forum, but you are welcome to pay and open a support ticket directly from the admin console, provided you are using all supported SIP trunks.

Please review our support procedures here before proceeding.

 

[Paul-2024]

We don't offer support via the forum, but you are welcome to pay and open a support ticket directly from the admin console, provided you are using all supported SIP trunks.

Please review our support procedures here before proceeding.

I wanted to share my recent experience with 3CX Priority Support so you’re aware that this wasn’t a setup mistake on our part but rather a subtle data corruption—likely triggered by recent updates on the hosted platform.

• Symptom: All outbound SIP trunks immediately returned “BUSY,” despite no changes on our end.
• Support Engagement: We opened a Priority Support ticket (US $100 fee) and spent several hours exchanging logs, packet captures, and screenshots. Unfortunately, the issue remained unresolved through the standard troubleshooting steps.
• Self-Service Resolution: A colleague eventually discovered that deleting each affected trunk and then re-adding it instantly restored full call functionality.
• Lesson Learned: The trunks themselves were healthy; some internal data must have become corrupted during an update process on 3CX’s hosted environment.

I hope this note helps anyone who encounters trunks answering “BUSY” out of the blue—try a quick remove-and-recreate of the trunks before investing in a costly support escalation.

 

[TheodorosG_3CX]

@Paul-2024 We have replied to the ticket conversation regarding your feedback.
Let us know if further clarification is required.