SIPTRUNK call routing only routing to main account number.

[rjamesm2884]

we use siptrunk and our call queues DIDs are not working. If we call a queue directly, it gets picked up by the main number. When we set up SIPTRUNK on the routing section we will have the admin account number from siptrunk and routed to the digital assistant IVR. If I change the account number to the actual main number it still routes to the IVR but so does everything else that dials inbound. We updated to 3CX to V20 and the problem still happens.

 

[bitn2]

Adjust your dids to *number without your phone prefix.

 

[rjamesm2884]

Is that the recommended for SIPTRUNK? I tried sed *accountprefix and that didn’t work.

 

[OlegR_3CX]

Are you using a supported trunk? What is it?

 

[OlegR_3CX]

For the supported trunks you can find the info in the documentation, and also have the number in E164, but ensure in advance that this is what the provider sent you, and check the settings too.
In case, the trunk is not supported and you are not sure, use * as was advised and see if it works for you.

 

[rjamesm2884]

yes, I'm using SIPTRUNK https://www.siptrunk.com/. Calls don't ring the DID of a queue instead they go to the main line.

 

[OlegR_3CX]

For the test, does it work if you use * and the remaining 6 digits of the DID?

 

[bomb]

Ignore the * it's not that.

SIPtrunk is using a field/tag in the calls that 3cx doesn't support. The result is 3cx will periodically (or entirely) ignore call routing and just shove the call into the default route. I'm on site but I can check my support tickets for the exact field later.

SIPtrunk won't do anything about it. If you're in V18 you should be able to force 3cx to ignore it. If your on V20 youre in tough luck territory.

 

[FireMedic]

Are you using proper E.164 syntax (i.e. +19031234567) and has this been an existing customer? If so, take the "+" off. I ran into this on some existing customers that we upgraded to v20 on with SipTrunk. When we changed the DIDs to have the "+" like the 3cx documentation said to, it broke everything. Apparently Siptrunk was passing the 11 digit DID withOUT the "+" so it wouldn't match on any of the ring groups and thus would land on the default route as specified in the sip trunk page. When I took the "+" off o the DIDs in 3CX, then it started routing calls to the ring groups correctly.
On the other hand, I had two new installs with Siptrunk and on those, the "+" prefix was necessary for the DIDs to match correctly. So try it both ways and see if that solves your issue.
I'm guessing that Siptrunk formerly did not pass DIDs in the full E.164 format but recently started to adhere to E.164. And I'm guessing that they only implemented full E.164 formating on new sip trunks to avoid breaking existing configurations. Just a guess.

 

[bomb]

Quoting from a support ticket:

---

Calls should be received without the Diversion header, and the 'ToUserPart' should contain the DID number. We recommend contacting your provider to rectify the diversion header being sent. Otherwise, you will need to reconfigure the inbound parameters of your SIP Trunk for it to work, but have in mind that this will be considered a custom template, which is not supported.
---

Our resolution was to switch most of our DIDs to Voxtelesys.

Note: the ticket said a couple other necessary fields were mangled too. This started happening to us maybe 90 days ago.

 

[rjamesm2884]

Numbers are without the + and yes I'm using i.e. 19031234567. We are on V20 so what's the conclusion it stopped working??

 

[YiannisH_3CX]

Numbers are without the + and yes I'm using i.e. 19031234567. We are on V20 so what's the conclusion it stopped working??

Our test accounts which we use to test and maintain the templates show that the dialed number comes in the full E164 number format. Your numbers should be in the E164 number format and you should be using the default template.
If routing still does not work for you please contact SIPTRUNK or your reseller and ask them how your account is configured.

 

[rjamesm2884]

I’ve contacted SIPTRUNK and they claim after v20 the headers are process differently. We are still not getting the DIDs to route to queue or extension they are being handed over to the trunk prefix.

 

[OlegR_3CX]

Maybe you can be more specific here and show us some of the examples based on the Trunk feedback and what the issue on your system is now.
Thank you