Toggle sidebar Toggle sidebar

3CX v20 Changing Incoming caller to trunk # causing the call to use default route

ScottLCDC

Customer
Basic Certified
Joined
Jan 7, 2025
Messages
12
Reaction score
2
Hello,

I've seen this issue on a lot of posts and have followed the suggestions but have not been able to get this to work. Currently we have 2 DiDs configured and 2 IVRs configured, incoming calls are ignoring the DiD rules and defaulting to the main IVR. I have triple checked with my VoIP provider who has been helping me troubeshoot the issue but so far no luck.

Trunk #: 902334xxxx

IVR1: 800
IVR2: 801

DID's:

1742505256534.png

Log file shows the incoming call to the 2nd DiD which should route to IVR2 (801) it appears to get changed to the trunk number which does not match any DiD's and goes to the default IVR1 (800).

03/20/2025 3:28:30.978 PM [CM503012]: Inbound any hours rule (unnamed) for 10000 forwards to DN:800
03/20/2025 3:28:30.978 PM Rule matched
03/20/2025 3:28:30.978 PM Checking inbound rule '': hour type = 1; cond = 4; mask = ''
03/20/2025 3:28:30.978 PM Checking inbound rule '': hour type = 2; cond = 6; mask = '*902532xxxx'
03/20/2025 3:28:30.978 PM Checking inbound rule '': hour type = 2; cond = 6; mask = '*902532xxxx'
03/20/2025 3:28:30.978 PM [Flow] No office hours set, office hours assumed
03/20/2025 3:28:30.978 PM Current local time is: 15:28:30
03/20/2025 3:28:30.978 PM [Flow] Looking for inbound target: called=902334xxxx; caller="902349xxxx" <sip:902349xxxx@:0>
03/20/2025 3:28:30.978 PM CallerNameAddr: "902349xxxx"<sip:902349xxxx;nf=e>
03/20/2025 3:28:30.978 PM No inbound caller ID reformat rule for DN:10000 is defined, or it is disabled (<Rules />)
03/20/2025 3:28:30.978 PM Created device copy Dev(735382346):[sip:[email protected]:5060 / 902334xxxx]: AOR = <sip:[email protected]:5060/UDP>
03/20/2025 3:28:30.977 PM Source is identified as trunk Lc:10000(@DSMTel (AR)[<sip:[email protected]:5060/UDP>])
03/20/2025 3:28:30.977 PM Matched: User of RLine to 902334xxxx


03/20/2025 3:28:30.977 PM LineMgr: identifying the source of SIP request: SI Recv Req INVITE from 216.83.x.x:5060 tid=+86d17a09cc76238f339331e781036fbf1+sip+1+d22b6125 Call-ID=0gQAAC8WAAACBAAALxYAAL4WKnVCW3H9wWkvcIB2x38/[email protected]:
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 216.83.xx.xx:5060;branch=z9hG4bK+86d17a09cc76238f339331e781036fbf1+sip+1+d22b6125
Max-Forwards: 63
Contact: <sip:[email protected]:5060>;isup-oli=00
To: <sip:[email protected]>
From: <sip:[email protected]:5060>;tag=216.83.xx.xx+1+53a190a5+26917747;isup-oli=00


I know this is generally caused by the DiDs not matching what the provider is sending but they appear to match from the logs and what the provider tells me the format they are sending. I've tried with and without wildcard, with and without area code and country code but it never changes. Any help on this will be appreciated as this is causing grief for the customer.
 
Last edited:
Have you assigned your DID to the IVR?

1742546636541.png
 
Yes both DiDs are assigned:

1742555187591.png
 
And a side note, there is a 3rd DiD that was going to a dummy extension and auto forwarded to an external number that also wasn't working, same issue as above where it always went to the default route. As a temporary fix I had to get our VoIP provider to forward it on their end before it reached our pbx as it is a critical police dispatch number.

We have a v18 system with multiple DiDs (15) using the same provider, all DiDs have incoming rules to point to specific extensions and everything works fine on that pbx.
 
Last edited:
ScottLCDC said:
...

Trunk #: 902334xxxx
...
03/20/2025 3:28:30.978 PM [CM503012]: Inbound any hours rule (unnamed) for 10000 forwards to DN:800
03/20/2025 3:28:30.978 PM Rule matched
03/20/2025 3:28:30.978 PM Checking inbound rule '': hour type = 1; cond = 4; mask = ''
03/20/2025 3:28:30.978 PM Checking inbound rule '': hour type = 2; cond = 6; mask = '*902532xxxx'
03/20/2025 3:28:30.978 PM Checking inbound rule '': hour type = 2; cond = 6; mask = '*902532xxxx'
03/20/2025 3:28:30.978 PM [Flow] No office hours set, office hours assumed
03/20/2025 3:28:30.978 PM Current local time is: 15:28:30
03/20/2025 3:28:30.978 PM [Flow] Looking for inbound target: called=902334xxxx; caller="902349xxxx" <sip:902349xxxx@:0>
Click to expand...
Yes, they don't match because as you wrote:
  1. the trunk number is 902334xxxx
  2. the number to be hit according to the log is 902334xxxx (which confirms the trunk number, because of mapping in the trunk by the provider?)
  3. you did set up *902532xxxx and *902532xxxx as DID which is wrong
This can't match. The log confirms that.

In addition, according to your picture below, the two IVRs have been assigned completely different DIDs: one without * and another different one. That makes even less sense to me.
 
Last edited:
Thanks for the reply, I'm confused why 3CX is using the trunk number and not the DiD called from:
To: <sip:[email protected]> which does match the DiD.
 
I don't know in this case. It could be related to the trunk settings and the number recognition.
 
We occasionally see a similar scenario, for example when a customer had individual phone numbers and they were all ported to a single SIP trunk with a number block. We then configure with the provider which of the individual numbers should be mapped to which single trunk number and then we enter this trunk number in the DID and it's all fine.
 
ScottLCDC said:
I'm confused why 3CX is using the trunk number and not the DiD called from:
To: <sip:[email protected]> which does match the DiD.
Click to expand...
If you're looking to direct calls by caller ID that would be Advanced > CID Rules...? The DID matches on the called number.
 
We then configure with the provider which of the individual numbers should be mapped to which single trunk number and then we enter this trunk number in the DID and it's all fine.
Click to expand...

If everything comes into the pbx using the trunk number as DiD how can you multiple inbound routes?
 
SteveITS said:
If you're looking to direct calls by caller ID that would be Advanced > CID Rules...? The DID matches on the called number.
Click to expand...

No, but based on this:
<!-- Gateway / Provider Inbound Parameters -->
<field name="ParameterIn" custom="" parameter="ToUserPart">$CalledNum</field>

I would expect the DiD to be reading To: <sip:902532xxxx@ which matches the DiD but is being ignored (or changed to the trunk number further in the call) and therefore going to the default inbound route (IVR1).

Although I could be way off in left field on this line of thinking as I have been banging my head off the wall trying to figure out why its ignoring the DiDs.
 
ScottLCDC said:
If everything comes into the pbx using the trunk number as DiD how can you multiple inbound routes?
Click to expand...
They former single numbers are mapped to a new different single trunk number.
 
ScottLCDC said:
Oh, you have multiple trunks with single DiDs?
Click to expand...
Yes, that happens a lot here in good ol Germany.
In the past, there were analog lines or ISDN with these individual numbers. There could be up to 9 numbers, which were either consecutive or completely random.

After the switch to VOIP, because analog or ISDN technology was phased out, there really was a separate SIP trunk for each number which had to be registered individually, but you could still only make 2 or 4 (or more) calls across all of them together. The providers, e.g. Deutsche Telekom, Vodafone, Versatel / 1und1 and many others, continued like this. Many functions such as CLNS, SIP 302 and a lot more were missing.

For example, we then ported to a new number block with 10 or 30 numbers to another provider and ported these individual numbers to different numbers on the new SIP trunk in the provider portal as I wrote above. This means that they can still be used inbound, but the SIP trunk with the number block has a completely different set of numbers which sometimes nobody knows or uses because only the old known numbers are still used. CLNS make it possible to call outbound with these old known numbers and that is how it works.
 
Okay, I did have that thought yesterday and ran it by my provider. So 4 trunks each with its own DiD and then route each trunk number to a separate IVR, ring group or extension as a fix. One of the issues is that it takes 2 days to setup a trunk on the provider side and I was initially hoping to have this issue resolved sooner than that setup time.

I believe that method would work but not sure it should be necessary to build the pbx that way since our v18 pbx's work fine with a single trunk with multiple DIDs.

Also this pbx may be expanding in size in the future with many more DiDs being added. This would require an additional trunk for each and of course the cost from the provider increases with each additional trunk line added as well.
 
bad example which is not ported now:
1742582546552.png

You'd rather not see the outbound rules ;)
 
ScottLCDC said:
Okay, I did have that thought yesterday and ran it by my provider. So 4 trunks each with its own DiD and then route each trunk number to a separate IVR, ring group or extension as a fix. One of the issues is that it takes 2 days to setup a trunk on the provider side and I was initially hoping to have this issue resolved sooner than that setup time.

I believe that method would work but not sure it should be necessary to build the pbx that way since our v18 pbx's work fine with a single trunk with multiple DIDs.

Also this pbx may be expanding in size in the future with many more DiDs being added. This would require an additional trunk for each and of course the cost from the provider increases with each additional trunk line added as well.
Click to expand...
If it worked with v18 using this one SIP trunk and multiple numbers - as is usual everywhere else - then it should work with v20 too.

This bad problem from this customer from us is not your problem.
 
Yeah I'm going to some digging with the provider templates on v18 and compare with v20 to see if something has changed.
 
You must log in or register to reply here.

Latest Posts

Forum statistics

Threads
112,142
Messages
590,939
Members
165,162
Latest member
lonedigger
3CX Logo Footer Copyright © Sitemap Privacy
Top Bottom