[SOLVED] Need Help To Troubleshoot Changing Outbound CallerID For Routes

FreePBX
,
1

Hi,
Our FreePBX (Asterisk 11.8.1/FreePBX 5.211.65-6) uses Routes to send calls to other states/area codes. In the past, when we’d call (e.g.) some customer in Florida, the call would go through our Florida Route (still does) (NO IT DOESN’T – see end) & display our Florida phone number on the callee’s CallerID screen. Our provider is VoIP.ms & we really like them & the problem seems to occur upstream from them, per the Asterisk logs.

Something has changed & now the called parties see our main number (from another state), which leads to missed calls.

In hopes this will help, I’ll paste the Asterisk Log (I only changed my name, the Co. name and our phone number with a global search-&-replace) for an example call from me to a number in FL which reads back the CallerID it sees:

( Log Dump Snipped – Irrelevant and spacey )

I can tell it seems that the line:
[2017-05-23 13:51:44] VERBOSE[22790][C-00002a34] pbx.c: – Executing [5615551781@from-internal:3] ExecIf(“SIP/123-0000e751”, “1?Set(TRUNKCIDOVERRIDE=9605554321)”) in new stack
is where the wrong number is being inserted, but I can’t find where or how to correct it.

Yes, something changed as we were troubleshooting some unrelated problems; but I have no idea what, since nothing we’ve changed (mostly to lock out foreign registration attempts) would affect the CallerID.

The Trunk’s “Outbound CallerID” is blank. The Trunk’s CID Options is set to “Allow Any CID”. The Trunk Dial Options is set to Tt with Override not checked.
The Outbound route to Florida is named “FL”, the FL Route’s CID is set properly, the Route Type’s “Emergency” and “Intra-Company” check-boxes are cleared; and the Dial Patterns are configured properly, exactly as they always have been.

I’ll be happy to provide any details I may not know to add at this point; but I’ve Googled my fingers to the bone & nothing I can find helps.

If there’s anyone who can read & understand these log entries (I’m working on it, but Google is not my friend), please reply ASAP, as this is the 400# gorilla in my tent right now & I’d like to get it fixed with all thanks and gratitude for any clue or hint. (I’m still on the steep part of the Asterisk/FreePBX learning curve, so I’ll do my part if one of you can tell me with some specificity what that part is. PLEASE?)

Thank you for reading & for any help you can offer!

Jim

2

Any FreeBPX/Asterisk gurus reading this? Any ideas I could try? Thank you again for reading.

3

Check your FL trunk configuration. It seems to me that you might have the “ForceTrunkCID” option set on the trunk. Also check your actual trunk Caller ID and make sure it’s set correctly.

The other possibility is that, for some reason, you are not actually selecting the “FL” trunk for your outbound any more. he trace seems to imply that you’re using the “Atlanta” connection for your outbound route, which may or may not have the correct CID set.

4

It may not apply to you, as we are in the UK, but we found our provider changed the way they accepted the caller ID, they have done this a couple of times, we started with being to use the standard UK format 0xxxxxxxxxx with no international access number, then they wanted 44xxxxxxxxxx, now they want +44xxxxxxxxxx. If we don’t conform, our calls go out as the main set number on the SIP line. I assume you have talked to your provider and asked what format they want sending to them?

5

Thanks, Dave.

“Atlanta” is the (only) Trunk, and there is no Outbound CallerID set in the GUI. CID Options is set to “Allow Any CID”.
“FL” is the Outbound Route in question. Its Route CID is set correctly, and “Override Extension” is checked.

Not selecting the “FL” Route would mean the Dial Patterns would have been changed, right? They haven’t been touched:

But how can I know if that’s working?

In the log, besides “TRUNKCIDOVERRIDE”, I can see it picking up the number I dialed here:

[2017-05-23 13:51:44] VERBOSE[22790][C-00002a34] pbx.c: – Executing [s@macro-dialout-trunk:3] GotoIf(“SIP/123-0000e751”, “0?disabletrunk,1”) in new stack
[2017-05-23 13:51:44] VERBOSE[22790][C-00002a34] pbx.c: – Executing [s@macro-dialout-trunk:4] Set(“SIP/123-0000e751”, “DIAL_NUMBER=5613641781”) in new stack
[2017-05-23 13:51:44] VERBOSE[22790][C-00002a34] pbx.c: – Executing [s@macro-dialout-trunk:5] Set(“SIP/123-0000e751”, “DIAL_TRUNK_OPTIONS=Ttr”) in new stack
[2017-05-23 13:51:44] VERBOSE[22790][C-00002a34] pbx.c: – Executing [s@macro-dialout-trunk:6] Set(“SIP/123-0000e751”, “OUTBOUND_GROUP=OUT_2”) in new stack
[2017-05-23 13:51:44] VERBOSE[22790][C-00002a34] pbx.c: – Executing [s@macro-dialout-trunk:7] GotoIf(“SIP/123-0000e751”, “1?nomax”) in new stack

… I don’t know what “OUTBOUND_GROUP=OUT_2” means, but the “FL” Route is the 3rd one on the list (Emergency, SC, FL) so if “Emergency” is = 0, “SC” = 1 then “FL” must = 2?

Continuing, this:

( Log Dump snipped – irrelevant and spacey )

has my head spinning, but it looks like Set(CALLERID(all)=8035550764) is where the incorrect number is stacked. FYI, my extension (sanitized) is “123”.

Sorry, but I’m still confused.

Thank you for your reply.

6

Good question, James.

I haven’t checked with VoIP.ms, but it appears to me that the incorrect CallerID is being set before the call departs the PBX.

( Log Dump snipped – irrelevant and spacey )

But I’ve already confessed to not having a clear grasp of the log entries yet.

The Set(CALLERID(all)=9605554321) and Set(CONNECTEDLINE(name,i)=CID:9605554321) are two places where I can see the error occurring…

Thank you again for a fresh perspective!

7

Worth a try, but I think you are right with it being set in the system. So what is that number then - “8035550764”, that must be set somewhere in the flow for it be used. Start at the extension and follow it through to the outbound routes and the trunk and see where it’s set.

8

OUT_2 is the internal name for the trunk. You can find it in the extensions.conf file and verify that the trunk is set up correctly.

9

Thanks, Dave, but neither “OUTBOUND_GROUP” nor “OUT_2” greps out of /etc/asterisk/extensions.conf.

I’ll keep looking for it…

ETA: Found it! In etc/asterisk/extensions_additional.conf. Reading… (Thanks!)

10

James, of course I sanitized it, but that “960…” number is our main line. It’s the one our FL callees see when they’re supposed to see our FL local number.

That log dump I posted initially was the extent of a single phone call from my ext. to a FL number whose Area Code, 561, is listed in our Dial Patterns. I tried to trace it out, but as I said I’m still scratching & clawing up the steep part of the FreePBX/Asterisk/VoIP learning curve here (old-school POTS head, me). I’m at least smart enough to ask experts for advice. :smile:

Thank you for replying!

11

What do you have in the Route CID box for the Outbound route in question? and what do you have for the Outbound Caller ID for the trunk?

12

James,
The Outbound Route’s Route CID is correctly set to our FL number, and the “Override Extension” box is checked (clearing the checkbox didn’t help). Neither of the “Route Type” boxes are checked so this shouldn’t be an “Emergency” nor an “Intra-Company” route.

The Trunk has no CallerID set (totally blank), and the “CID Options” pulldown is set to “Allow Any CID”. FreePBX bitched about the blank CallerID here, but I did it anyway since that’s the way I found it. I had tried to get it to say our company name (hopefully followed by the correct number), but I’m over that now. (Still would like it, but not going to waste any more time trying)

Still trying to wrap my head around the .conf files & what they’re doing…

13

Any other suggestions? Requests? Comments? I urgently need to fix this but need some help figuring out how.

THANK YOU all for contributing!

14

Another question:
In the macro, “macro-outbound-callerid”, there’s a variable called “USEROUTECID”. Is that “User Out CID” or “Use Route CID”? Sorry, *nix guys, but this is why I use Mixed Case…

If it’s Use Route CID, where is it set in the GUI, please? I’d think that’s where the Route CID is set.

Also, I can see (e.g.) where the FL Route has this line:

exten => _239NXXXXXX,n,ExecIf($["${KEEPCID}"!=“TRUE” & ${LEN(${TRUNKCIDOVERRIDE}
)}=0]?Set(TRUNKCIDOVERRIDE=9045558488))

for each of the FL area codes (e.g. 239 here, it repeats for all of them). So my question is, where in the GUI is “KEEPCID” set to not “TRUE” and where is “TRUNKCIDOVERRIDE” set in the GUI? If the execution of the above line (it repeats varying only by the Area Code) works like it seems to say, I think I’m almost golden here.

Not to brag, but I’m really good at C and Assembler, as well as a few other languages, but this Asterisk code is making me dizzy! Am I even correct in assuming that if the KEEPCID variable is not “TRUE” and there is nothing in “TRUNKCIDOVERRIDE” (LEN=0), the “904…” phone number will be set as the CallerID number? If so, if I can find those in the GUI (I know not to hand-modify any of the .conf files), we can all move on to something interesting.

Thank you again for reading, and many thanks for any insight or advice or answers you care to share!

15

That tells you what the value of the condition was, so KEEPCID is TRUE or the length of the TrunkOverride value is not 0. The compound condition is false, so one of the entries is wrong.

To test this, you can manually edit the file that this code is in (extensions_*.conf) to test it. Add a couple of NoOps before it and drop the values into the ‘full’ log file (or the CLI, if you prefer). Note that your changes will be overridden if you “reload” the FreePBX Configuration.

16

Thanks, that’s what I’m trying to avoid. Is there a way to set the entries permanently in the GUI?

Here’s what I think are the relevant fields:

and:

image.png693×268 11.7 KB

The tooltips that pop up don’t identify which variable is being set, and of course the variables aren’t specifically named in the GUI, so I’m just guessing. I believe that if I set those properly, this problem will go away (maybe after an amportal restart, but that happens every night anyway).

In FreePBX 5.211.65-6, where in the GUI are KEEPCID & TRUNKCIDOVERRIDE set, please?

17

Sorry to keep harping on it, but I really can’t find this in the Asterisk Admin Guide & Google isn’t helping either.

I need to set KEEPCID to not “TRUE” and blank out the TRUNKCIDOVERRIDE field, in hopes that will fix my CallerID problem on outbound Routes.

Can anyone clue me in to where to set these in the GUI? Please?

18

Holy Cannoli, .BATman!!!

“Each problem that I solved became a rule, which served afterwards to solve other problems.”
~Rene Descartes

Here’s a rule for you:

Just because it’s working, doesn’t mean it’s set up correctly.

If anyone is still following this ugly thread, the answer doesn’t have a da***ed thing to do with CallerID. That was a symptom, perceived by the User Community as “the” problem.

Teased enough? Okay:

The Root Cause was misconfigured Dial Patterns. We have a list of Outbound Routes, one for each state we cover. We use this to present local (to the callee) CallerID numbers when we call out from here. Each Route’s Dial Patterns start with the Area Codes for that state with the usual placeholders for digits. EXCEPT the Route for our own state!!! In trying to optimize and improve performance (due to widespread complaints of jitter, drops, dead audio, etc.), I had moved the most-likely Route (local calls) to the top of the list. “So what, who cares?” By putting that Route first, every single outbound call would first hit the Dial Pattern:
_exten => NXXNXXXXXX,n,ExecIf($["${KEEPCID}"!=“TRUE” & ${LEN(${TRUNKCIDOVERRIDE})}=0]?Set(TRUNKCIDOVERRIDE=9605554321))
and bail out at that point.

Notice the error? “NXX” matches all Area Codes. It didn’t even register (pardon the pun) that all the other Outbound Routes had specific Area Codes & this one didn’t.

Whoever configured this went through the trouble of setting the in-state Route (not as a default, a whole 'nother Route) but they just didn’t bother to set the in-state Area Codes. (!!!) So when I moved the most-used Route to the top (that wasn’t the cause of the performance problem, but I digress), the call flow never got to look at the other Routes.

Color me ‘stupid’. And “do as I say, not as I do” & refuse to assume that “it was working before” means it was configured correctly.

THANK YOU THANK YOU THANK YOU to everyone who chipped in to offer advice & goad me further. I sincerely appreciate the time and consideration you gave my stupid problem!!

I’d take on World Peace next, but I’m really only fit for whirled peas. :laughing:

1 Like