Solved v20 build 1620, DID incoming assignment not working

[dkirk-ads]

Debian installation of v20, upgraded all along from v18. Need to use two of my DIDs to direct dial two different user extensions. In the v20 interface I attach the DID number to each user extension where it shows "Assigned DID number(s). I have done this for two different users using two different DID numbers. I have bounced the SIP service. When either of these DID numbers are called the main IVR extension assigned to that SIP trunk answers, never the intended user extension; its not routing properly.

If I play with call handling, for example, and create a new Ring Group using either of those two DID numbers it correctly asks if I want to disassociate the number from the user, so it knows about the user and the DID assignment.

When I look at the IVR receiving the calls to these DIDs the only DID assigned is the correct corporate number, I'm not sure how this IVR is getting the DIDs assigned to users.

Is this a v20 bug, coming up from the various v20 builds? Should I remove the DIDs from the SIP Trunk definition and re-add them?

 

[dkirk-ads]

Removing the DID from the trunk definition and then adding it back didn't change anything, the DID continues to hit the main trunk IVR instead of the assigned user.

 

[SweetAction]

Switch to verbose mode, replicate issue, download logs (generate support info), and check the logs to see how 3CX is seeing the calls and thereby how 3CX is routing the calls.

 

[Carlo24]

Am having the same issue, I was on a non supported sip provider and had to port the numbers to a supported one but the issue still persisted. I believe its a bug also but not sure why 3cx insists on opening a support ticket for this. Anyway will open one and await feedback

 

[Colorado VoIP]

on certain providers we have to enter the full 11 digit number on additional DIDs, like 15552223333 and on others we have to enter *5552223333 to get the calls to route. maybe try removing the 1 or adding the 1 depending on your setup.

 

[dkirk-ads]

When you create DID numbers the page clearly spells out "DID numbers must be in e164 format: If your number is (813) 591-0130 enter it as +18135910130" ... but that is WRONG ... changing the DID from +1xxxyyyzzzz to *xxxyyyzzzz allows the routing to work, thank you Colorado VoIP! That solution was considered days ago but it clearly spells out "must be in" that e164 format so it was never tried.

 

[bitn2]

We had the same problem on our test instance. Its only working with *1324564.

 

[SweetAction]

The * is a wildcard, which means anything in front of the remaining digits is matched.

If your provider sends in e164 format, then you can use the entered number in e164 format. If not, you have to use the format the provider is using.

Some providers you can switch the format of.

 

[dkirk-ads]

Yes, understood, but 3CX states we "must" use the e164 format during the DID creation. That wording is confusing and should be changed.

 

[SweetAction]

Yes, understood, but 3CX states we "must" use the e164 format during the DID creation. That wording is confusing and should be changed.

3CX also tells their certified providers whose templates are included in the system that they *must* send in that format, so either the provider isn't certified OR isn't sending in that format OR you are using a template that is old/before that requirement.

 

[dkirk-ads]

When creating a new trunk under v20 they show up on the list so I assume they are certified. Not sure how to tell which template I am currently using for them.

 

[SweetAction]

Not sure how to tell which template I am currently using for them.

It's about when you created it (which is why 3CX likes to say delete and recreate it)

If they have a version of the template (v1) and you created a trunk with that, then v2 came out, your trunk still uses the settings from v1, no matter how many 3CX upgrades you do.

 

[leejor]

If you have access to the 3CX Activity Log, and I assume your on premise system does, then a check of the Log, in Verbose, would confirm the format of the number is being sent. Using the wildcard means you don't have to concern yourself with what is being sent in front of the last 7, or 10 digits. Obviously the use of the word "must" is an attempt to standardize numbers, and hopefully cut down on trouble tickets. However, the providers must also co-operate, or it doesn't work.

 

[Colorado VoIP]

deleting and recreating a trunk with some times over 100 DIDs on it is not really an option, so we keep the * trick handy in the bag of tricks.

 

[dkirk-ads]

Agreed, I'm reluctant to do that when it will inevitably break other definitions and other functions. Maybe over a weekend when I'm guaranteed no phone usage, then maybe I will go through that pain. When the trunk is exported I see the older definition is in use.

 

[SkippyJ]

I have the same issue with a brand new 3CX Hosted instance and a 3CX preferred SIP trunk provider BreezeConnect in Australia and all inbound calls go to a single extension even if I assign 2 x DID to another extension. (there are only 4 DID lines)

today I deleted the 3cx trunk - recreated it - and still have the same problem.

Tried to enter * in front of my did and it will not allow me to do that. says (incompatible number)

This same SIP trunk was working fine on V18 instance before I rebuilt the PBX on v20 on the 3cx free hosted platform as a backup & restore option could not be used.

Any pointers that might fix it?

I've also changed the SIP trunk setting on the breeze SIP trunk to "Catch all E164 (3cx V20)" on their advice - with no change in the DID behaviour.

All calls still go direct to the same extension

 

[treynolen]

We had this issue where we were using *123456 for our DIDs and it worked for a while but then QUIT working. We ended up having to add them all back in as e164 to get them to work. When I opened a ticket with 3CX, they said the provider (in this case Siptrunk), was not sending out in e164 format. When I reached out to Siptrunk, they said that they *never* modify the number, so if it comes to them in e164 they pass it along, but they don't change it to be in that format. I've not seen this break on any of our upgrades. The one that broke was originally installed as v20.

 

[SkippyJ]

We had this issue where we were using *123456 for our DIDs and it worked for a while but then QUIT working. We ended up having to add them all back in as e164 to get them to work. When I opened a ticket with 3CX, they said the provider (in this case Siptrunk), was not sending out in e164 format. When I reached out to Siptrunk, they said that they *never* modify the number, so if it comes to them in e164 they pass it along, but they don't change it to be in that format. I've not seen this break on any of our upgrades. The one that broke was originally installed as v20.

Thanks for the reply. - It's currently running V20.0 Update 2 (Build 708)

As a V18 upgrade wasn't possible, we built this as a new instance mid May 2024 to do the initial config of extensions, VM rules, DND and call forwarding to mobile phones on no answer etc before we setup the primary SIP trunk in June.

At present the SIP TRUNK is setup with a default extension # configured and on the DID tab 1 number goes to the same "default" extension # and the other 2 lines are configured to go to the other users extension #.

Does V20 mandate the use of Ring Groups or some other setting to make DID work, or is it a 3CX DID BUG on clean V20 installations.

 

[SkippyJ]

This V20 DID issue is now rectified.

BreezeConnect our AU SIP trunk provider does not send +61xxxxxxx

They send them as 61xxxxxxxx

So we had to remove the + from all DID's assigned on this SIP trunk which was making all calls go to the default extension due to the number being presented not having a + at the front - which then didn't match the systems configured DID number.

 

[bitn2]

Just put a * in front of your local number. Instead of +6112345678 put *5678