V18 to V20 Issues

[harrywong]

I experienced the weirdest issue when going from v18 to v20. The employee's phone numbers when called from an external phone (cellphone) would go straight to the receptionist's phone instead of the assigned DID. However, calling my cellphone from the work phone, it worked fine and showed the correct caller ID (the receptionist's number, which is what we want).

The expected behavior is when calling the DID number, it should go straight to the employee, but this was not the case after the version change.

I noticed some odd issues with numbers missing the plus sign in front, but I doubt this is the issue, because changing it for the user we tested with resulted in it still behaving the same (making the DID and caller ID have a + in front).

To be as specific as possible, we went from a version 18.0 Update 9 (Build 31) fully system backup zip file, and imported it into a different cloud provider's instance (3CX Phone System 20.0.5.551 (Mar 3, 2025) on AWS). This resulted in everything seemingly working, until you try calling an employee's phone number. Also to note, the system was updated to the latest version after this import. Due to the 3CX DNS record only allowed to get updated 5 times a week, I've been limited on how often I can test this change.

Is it possible I'm missing a step in the checklist? Please point it out for me. Is something about how inbound rules work different in this version? I know they were moved per endpoint, but there doesn't seem to be a way to do what we need in the settings.

Any suggestions or ideas on how to better plan for this issue and how to address it would be greatly appreciated. This upgrade has been a huge pain point for me and my team. We're already thinking about switch from 3CX to some other system. I would like to stay with 3CX but the amount of issues with this upgrade problem have been through the roof.

 

[PhoneMan123]

It sounds like your inbound calls are matching the default destination set on the trunk due to the numbers not coming in the correct way. I'd check in your trunk settings what your default route is and see if changing that changes where the calls route to. If so check how your numbers are built in 3CX vs whats being sent by your carrier. If they are sending calls +1 then you'll want the DID's built that way. I've found setting them to * and the number can help if it's not always consistent from the carrier side. That should catch them if they have the + or 1 or +1 instead of just 10 digits.

 

[SteveITS]

@harrywong In Reports there is an Inbound Rules report that may help. In v20 the DIDs are attached to the object, such as the user or ring group. Verbose logging should indicate why calls are being routed where they are.

 

[AlexanderJHanna]

Note that in v20.06 you are not able to use the wildcard *
It was very helpful to use it but it does not accept you adding it anymore.

 

[bitn2]

Note that in v20.06 you are not able to use the wildcard *
It was very helpful to use it but it does not accept you adding it anymore.

Works like before.. no problem here.

 

[KyriacosS_3CX]

@AlexanderJHanna ,

If you don't mind me asking, which place were you able to use a star before but no longer?

There should not have been a change to that, like bitn2 and Phoneman123 also mention.

Best,
KS.

 

[AlexanderJHanna]

@AlexanderJHanna ,

If you don't mind me asking, which place were you able to use a star before but no longer?

There should not have been a change to that, like bitn2 and Phoneman123 also mention.

Best,
KS.

Hi,

Strange but under version 18 when adding DIDs for generic SIP trunks, I was able to add things like *3025555, 302555* or *5555 and it allowed me to enter the "*" without issues.

However, under version 20, I am not able to add the the * when adding DIDs under the generic SIP trunk. Then image shows what I am talking about (v20 Update 6, build 724)

 

[AlexanderJHanna]

Works like before.. no problem here.

No it does not. See my latest post.

 

[PhoneMan123]

Seems like you have something else going on then. I just tested on another V20 system with a generic template and was able to add it with no issues. Could you try building a new trunk with the generic template and adding it again?

 

[AlexanderJHanna]

@PhoneMan123,

Thank you for your reply. I had tested that before and did so just now and one i enter a *, i get the not allow message.

Are you on the same version as me?

Edit: Also happening with supported trunks.

 

[PhoneMan123]

I'm running V20 update 6 on the systems I tested this on. Also tested on ones that were upgraded from V18 to V20 and ones that were installed as V20. I tried both older trunks using the Telnyx config from when it was a supported carrier as well as ones built from the Generic template.

When you said you changed to a new hosting provider are you using 3CX hosting or outside hosting like with AWS or Digital Ocean? I know that hosted by 3CX has/had some limitations. Also what license level are you using. All of my tests have been on Enterprise licensing.

 

[AlexanderJHanna]

I'm running V20 update 6 on the systems I tested this on. Also tested on ones that were upgraded from V18 to V20 and ones that were installed as V20. I tried both older trunks using the Telnyx config from when it was a supported carrier as well as ones built from the Generic template.

When you said you changed to a new hosting provider are you using 3CX hosting or outside hosting like with AWS or Digital Ocean? I know that hosted by 3CX has/had some limitations. Also what license level are you using. All of my tests have been on Enterprise licensing.

It's an On-prem Linux box with the Enterprise LIC.

Interestingly enough, I just tried it on another v20 on-prem but with windows server and it accepted the * without issues. Very strange.

 

[AlexanderJHanna]

Any idea why it is not working on my Linux on=prem install?

 

[KyriacosS_3CX]

Hi,

Would the problem install be Multi-Company-Mode by any chance? On MCM wildcards are not permitted in DID import as you might end up with a common pattern for two tenants, or one tenant could end up "stealing" another's DIDs.

Best,
KS.

 

[AlexanderJHanna]

Hi,

Would the problem install be Multi-Company-Mode by any chance? On MCM wildcards are not permitted in DID import as you might end up with a common pattern for two tenants, or one tenant could end up "stealing" another's DIDs.

Best,
KS.

Hi, yes, I do have it in Multi-Company-Mode. There's your problem Alexander

I would love to be able to manage this myself due to my solution. If I disabled Multi-Company-Mode mode, add the wild cards and then enabled Multi-Company-Mode again, do you see any issues?

 

[bitn2]

Hi, yes, I do have it in Multi-Company-Mode. There's your problem Alexander

I would love to be able to manage this myself due to my solution. If I disabled Multi-Company-Mode mode, add the wild cards and then enabled Multi-Company-Mode again, do you see any issues?

Doenst make any sence and wont work.

 

[KyriacosS_3CX]

do you see any issues

Simple answer, yep

The system will not switch, as the reasons for not having wildcards would still stand. With MCM each company needs unique DIDs. With wildcards in place that's simply not possible.

I'm sure you can make a CSV in [spreadsheet software of your choice] with sequential numbers and import them easily enough for this not to be a terrible chore. Similarly importing users with DIDs assigned afterwards can save some of that manual work too.

Best,
KS.