Toggle sidebar Toggle sidebar

Solved DIDs routing to the wrong extensions

Status
Not open for further replies.

SethTalley

Customer
Basic Certified
Joined
Oct 5, 2019
Messages
83
Reaction score
12
I have one Telnyx trunk with nine DIDs, xxx.xxx.xxx1 through .xxx9.

I have nine extensions, x101 through x109.

I have nine Inbound rules, xxx1 goes to x101, xxx2 goes to x102, etc, in and out of office. They are unnamed, and in numerical order

MMS to xxx1 go to ext. x101 etc.

MMS from x101 goes out on xxx1 etc.

Calls from x101 shows up with caller ID xxx1 etc.

I have no ring groups.

I have no call queues.

My only Digital Receptionist is the Out Of Office IVR

BUT

  • With "Call Source Identification" and "Use both CSI and Caller Number/Name" checked, all calls coming in on xxx1-xxx9 go to Ext. x109.
  • With "call Source Identification" checked and "Use both CSI/CNN" unchecked, all calls coming in on xxx1-xxx9 go to Ext. x109.
  • With "Call Source identification" unchecked, all calls coming in on xxx1-xxx9 go to Ext. x101.

I'm sure I missed something simple and I would love it if someone clever could tell me what it is. That whole "Call Source Identification" thing was from the forums but that was as far as I got.

Thanks in advance!
 
Telnyx is a supported provider, so if you set it up with the built in template you should not have to change anything.

I would remove any changes you made to the call source, etc then try putting a * in front of the DID in the trunk - so *12223334444 instead of 12223334444

If that fails you need to turn on verbose logging, make a test call, and examine how the call comes into the PBX.
 
It is very clearly coming in to the correct DID:

>To: <sip:1xxxxxxxxx8@10.13.70.8> From: "yyyyyyyyyy"<sip:[email protected]>;tag=Krr53Ua3rHrUa

And then it's choosing to xend it to the wrong number:


01/30/2022 1:19:54 PM - [Flow] Target endpoint for 109 is Extn:109
01/30/2022 1:19:54 PM - [CM503010]: Call(C:3): Making route(s) from Line:10000<<yyyyyyyyyy to <sip:[email protected]:5060/UDP>
01/30/2022 1:19:54 PM - [CM505003]: Provider:[Telnyx LLC] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5060]

Changing the plus to the star had no effect.
 
Hi @SethTalley

As @SweetAction mentioned Telnyx is a supported provider so you should be using the default template with no changes made to it.
So make sure you have reverted all changes to their default settings (Telnyx supported rInstance so call source identification should be off) and let us know how your DIDs are formatted currently.
Are you using 10 digits, 11 digits or E164 (+1) format?

There is also a way in the Telnyx portal to control the format of the numbers sent to you. I believe the default recently is E164 without the "+".
All you need to do is to match the number format Telnyx is using with the one you are using,
https://www.3cx.com/docs/telnyx-voip-provider/
 
I have turned off Call Source Identification.

DIDs are formatted +1 234 467 8901 on 3CX.

Telnyx reports DNIS as E.164, ANI as E.164/National. Numbers in my dashboard appear as +1 234 567 8901.

With Call Source Identification off, all calls from xxx.xxx.xxx1 through xxx.xxx.xxx9 pass through to Extension 109.
 
Telnyx being a supported provider and familiar with 3CX should be able to help you sort this out. Have you reached out to them?
 
Nope. I can totally do that. Thing is, it's coming in on the right number from Telnyx, identified as the right number by 3CX, and then passed to the wrong extension. And again, checking and unchecking CSI flipped it from x101 to x109.

That's no longer the case - the only other thing that I changed while investigating this was putting my DID inbound rules in numerical order (they were xxx1-xxx7, then xxx9, then xxx8; they are now xxx1-xxx9). Changing it back, however, did not repeat the initial error (all calls going to x101). We're at the new error (all calls going to x109) regardless of what number is called.
 
I'd love to see a full log showing call from origin to termination. The snippet above makes no sense unless the inbound rule is pointing to the wrong place, but I'm assuming that the inbound rules is correct.
 
I'm happy to generate that. Please keep in mind, however, that I'm a reasonably clever individual who does PBX stuff by default, not by choice so I'll screw it up miserably unless I have good instructions. ;-)

What do I look for in the log file for "origin" and what do I look for for "termination?" I've noticed that setting logging to verbose gives you uhhh a lot and doing a PCAP on it runneth my cup over equally.

Again, thanks for your help.
 
Call would look something like this at "start"
start.png
and something like this at "end"
end.png

but I really want this part and it's surrounding lines.:
reason.jpg
 
There is... a lot between those two. I've attached it as an anonymized log file.
 

Attachments

SethTalley said:
There is... a lot between those two. I've attached it as an anonymized log file.
Click to expand...
So it wants to send the call to 109 because that's what the rule is saying:

Code: 
01/31/2022 1:51:27 PM - [CM503012]: Inbound office hours rule (unnamed) for 10000 forwards to DN:109
01/31/2022 1:51:27 PM - [Flow] No office hours set, office hours assumed
01/31/2022 1:51:27 PM - [Flow] Looking for inbound target: called=1xxxxxx0728; caller="xxxxxx3181" <sip:xxxxxx3181@:0>
01/31/2022 1:51:27 PM - CallerNameAddr: "xxxxxx3181"<sip:xxxxxx3181;nf=e>
01/31/2022 1:51:27 PM - No inbound caller ID reformat rule for DN:10000 is defined, or it is disabled (<Rules />)
01/31/2022 1:51:27 PM - IncomingCall: C:1 from <sip:[email protected]:0/UDP> to <sip:[email protected]:5060/UDP>
01/31/2022 1:51:27 PM - Added leg L:C:1.1[No endpoint yet]
01/31/2022 1:51:27 PM - Call from "xxxxxx3181"<sip:[email protected]>;tag=8p56p9KDaU6Xm to <sip:[email protected]>;tag=c8ace203

and

Code: 
01/31/2022 1:51:27 PM - [Flow] Endpoint Extn:109 has no forwarding rule on reason 'All calls'
01/31/2022 1:51:27 PM - [Flow] No office hours set, office hours assumed

is 109 the default destination in the trunk? Edit the trunk, then scroll to
1643669285463.png

Can you show me the rule for 0728?
 
Excellent! I suspected this was me being dumb and configuring things poorly. I have another functional 3cx system that works gangbusters and does nearly everything I tell it to, but I don't have any DIDs over there. Over here? Nuthin' but DIDs.

So yes. x0729 *is* the main trunk number. here's 0728:3cx routing.png
 
I think that the DID isn't matching the inbound rule and as a result is going to the main route, which you are confirming is 109.

Try this to confirm this theory

Put a name in the inbound rule for 108 (example: YOURNAMEHERE)
Make a test call
Search the log for "Inbound office hours rule"
Post that part of the log.

What should happen:
It should say something like
01/31/2022 1:51:27 PM - [CM503012]: Inbound office hours rule (YOURNAMEHERE) for 10000 forwards to DN:109

What will likely happen:
01/31/2022 1:51:27 PM - [CM503012]: Inbound office hours rule (unnamed) for 10000 forwards to DN:109

Indicating that the inbound rule you want to be applied isn't being applied. You can also add a different name to the rule for 109 if you want.

And if so, we can focus on that.
 
  • Like
Reactions: SethTalley
Also apart from what @SweetAction is saying which is all very correct from your log I can see that the numbers are arriving without a "+" from Telnyx. If you have your DIDs added with a "+" then that's your issue.
Try changing one of your DIDs to 1XXXXXXXXXX and test again.
 
  • Like
Reactions: SethTalley
  • Like
Reactions: SethTalley
SweetAction said:
Shouldn't the * in front (what I recommended here: https://www.3cx.com/community/threads/dids-routing-to-the-wrong-extensions.87613/post-414469) handle this potential problem?
Click to expand...
It should, but I am trying to cover all basis because something does not add up here. Normally switching the call source identification shouldn't change the target endpoint since Telnyx uses rinstance which supersedes everything else so I want to start from the beginning and check everything again.
 
  • Like
Reactions: SethTalley
If you have rules set to match the number +1NXXNXXXXXX, and your provider sends 1NXXNXXXXXX, then it won't work, the same if you use *+1NXXNXXXXXX.

If you want to use a wildcard, then replace the + with that...*1NXXNXXXXXX. This will cover DIDs sent with, or without a leading +. You could also use the wildcard, and only the last 7 digits of the number *NXXXXXX
 
  • Like
Reactions: SethTalley
AWRIGHT!

1) Putting in "XYZPDQ Rule" and then searching through verbose logs for "XYZ" finds nothing. The rule is never applied.

2) Removing the plus sign from x728, re-adding the DID, and re-configuring the inbound rule to eliminate plus signs causes calls from x728 to route to extension 108.

It seems that this document needs revision as (A) it says to use " E164 number format (e.g. +1234567890)", I can confirm on my Telnyx page that I am using +1234567890 format, and as Yiannis has pointed out, Telnyx is not passing the plus sign along.

How should I configure my inbound rules and DIDs in such a way as to bomb-proof them? I can see this leading to a discussion between 3CX and Telnyx at which point whatever rules I rewrite today may break next week...
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
112,325
Messages
591,898
Members
165,478
Latest member
postmaster@studiolegaleda
3CX Logo Footer Copyright © Sitemap Privacy
Top Bottom