Hello,
I am seeking assistance with a persistent routing issue in 3CX v20 where calls handled by a "Dial by Extension" IVR are immediately diverted to the voicemail of Extension 2010, regardless of the extension dialed.
Environment:
Version: 3CX v20 (Latest Build)
Setup: Inbound Call -> IVR 8100 -> IVR 8101 (Dial by Extension) -> User dials target extension.
The Problem: When a caller dials an extension (e.g., 2026 or 2050) via the IVR, the call never rings the target. Instead, it is immediately routed to the voicemail of Extension 2010. This happens even for brand-new extensions with default settings.
Technical Evidence from Logs: Analysis of the Verbose Activity Logs reveals the following chain of events:
Transfer Initiated: The IVR (8101) receives the digits and initiates a transfer.
Registration Failure: Even though the target extension (e.g., 2026) shows a green status icon and is registered in the "Phones" tab, the Call Engine identifies it as not_registered at the moment of the transfer.
Automatic Diversion: Because the status is seen as not_registered, the system executes an immediate diversion: creation_forward_reason = 'not_registered'.
Target Locked to 2010: The log explicitly shows: [Flow] Target endpoint for 2010 is VMail:9999.
What I have already checked:
Forwarding Rules: Target extensions have no active rules or exceptions pointing to 2010.
Direct Calls: Internal extension-to-extension calls (e.g., 2020 to 2032) work perfectly and follow their own voicemail rules, ringing for the full 20 seconds.
Departments: I have tried moving extensions between departments, but the dependency on 2010 persists.
Why would the PBX see an extension as not_registered during an IVR transfer when it is otherwise active and reachable?
Is there a "System-wide Operator" or "Default Failover" setting in v20 that could be forcing all unregistered results to Extension 2010 specifically?
Has anyone seen IVR 8101 (Dial by Extension) default to a specific extension if it fails to resolve a target status?
I have attached a snippet of the verbose log showing the diversion for reference. Thank you for any guidance!
I am seeking assistance with a persistent routing issue in 3CX v20 where calls handled by a "Dial by Extension" IVR are immediately diverted to the voicemail of Extension 2010, regardless of the extension dialed.
Environment:
Version: 3CX v20 (Latest Build)
Setup: Inbound Call -> IVR 8100 -> IVR 8101 (Dial by Extension) -> User dials target extension.
The Problem: When a caller dials an extension (e.g., 2026 or 2050) via the IVR, the call never rings the target. Instead, it is immediately routed to the voicemail of Extension 2010. This happens even for brand-new extensions with default settings.
Technical Evidence from Logs: Analysis of the Verbose Activity Logs reveals the following chain of events:
Transfer Initiated: The IVR (8101) receives the digits and initiates a transfer.
Registration Failure: Even though the target extension (e.g., 2026) shows a green status icon and is registered in the "Phones" tab, the Call Engine identifies it as not_registered at the moment of the transfer.
Automatic Diversion: Because the status is seen as not_registered, the system executes an immediate diversion: creation_forward_reason = 'not_registered'.
Target Locked to 2010: The log explicitly shows: [Flow] Target endpoint for 2010 is VMail:9999.
What I have already checked:
Forwarding Rules: Target extensions have no active rules or exceptions pointing to 2010.
Direct Calls: Internal extension-to-extension calls (e.g., 2020 to 2032) work perfectly and follow their own voicemail rules, ringing for the full 20 seconds.
Departments: I have tried moving extensions between departments, but the dependency on 2010 persists.
Why would the PBX see an extension as not_registered during an IVR transfer when it is otherwise active and reachable?
Is there a "System-wide Operator" or "Default Failover" setting in v20 that could be forcing all unregistered results to Extension 2010 specifically?
Has anyone seen IVR 8101 (Dial by Extension) default to a specific extension if it fails to resolve a target status?
I have attached a snippet of the verbose log showing the diversion for reference. Thank you for any guidance!
