Very odd dialing issue

Good morning, all. I’ve got a very weird one. We have an outbound rule of just 1855xxxxxxx (send to carrier). It’s in the same outbound rule with other TFN NPAs (888, 800, 877, 866, etc.). They’re all built the same.

I can call 855 numbers just fine, but one number I’m not able to. When the phone extension dials 855-523-9355, the phone hears a “The number you have dialed is not in service”, yet I can call other 855 numbers, and actually this number IS in service.

So, to explain a bit, our patterns for TFN routing are their own outbound route, and are programmed as follows:
1800NXXXXXX
1822NXXXXXX
1833NXXXXXX
1844NXXXXXX
1855NXXXXXX
1866NXXXXXX
1877NXXXXXX
1888NXXXXXX
1+800NXXXXXX
1+822NXXXXXX
1+833NXXXXXX
1+844NXXXXXX
1+855NXXXXXX
1+866NXXXXXX
1+877NXXXXXX
1+888NXXXXXX
9|1800NXXXXXX
9|1822NXXXXXX
9|1833NXXXXXX
9|1844NXXXXXX
9|1855NXXXXXX
9|1866NXXXXXX
9|1877NXXXXXX
9|1888NXXXXXX
1+9|800NXXXXXX
1+9|822NXXXXXX
1+9|833NXXXXXX
1+9|844NXXXXXX
1+9|855NXXXXXX
1+9|866NXXXXXX
1+9|877NXXXXXX
1+9|888NXXXXXX

Users normally would dial 9 + <11-digit number> for a TFN call. However, we also process dialed as 10-digit (with or without the 9), because we also need to support dialing from the call log (which dials 10-digit w/o the 9). That’s why the patters are the way they are.

So, with the above in mind, if the user dials 9 + <10-digit number>, 9 + <11-digit number>, or even just <10-digit number>, the call will go through. But, this one TFN is not.

To make things even more strange, for the failed calls, there is no CDR record, suggesting it never even sends the call to the carrier for processing, and instantly fails the call w/o even trying.

Thoughts? Did I screw up my outbound route entries? My goal was to allow dialing of the TFNs as dialed in the following 4 formats:
9-1-855xxxxxxx (strip the 9 to the carrier, then send the rest as dialed)
9-855xxxxxxx (insert a 1 to the carrier, strips the 9)
1855xxxxxxx (send as dialed)
855xxxxxxx (insert a 1 to the carrier)

Is there a conflicting outbound route ahead of this one that would match?
What does the Asterisk log/CLI show when you attempt to call that number?

Already checked - no. The closest might have been the local 7&10 digit, but those ONLY have the 3 area codes in our city specifically called out. Everything before is like 911 and 4-digit TIE line routing (nothing even close to 855).

What’s the CLI saying when the call fails? If it not leaving Asterisk, the answer is there.

It is possible/likely the carrier you are using has not routed that particular number (it happens) , call them to check, use another carrier to also check.

Your working call was dialed as 98555239355; the failing one as 918555239355. Is that behavior consistent, or is the problem just intermittent?

If the former, the dial patterns for your Outbound Route may be set up incorrectly – post a screenshot of that page.

If the latter, the call could be blocked by your termination provider or by the destination party, because of previous fraud or abuse, or because your caller ID is not set up correctly.

Try calling 918004377950 and also 98004377950. With proper setup, you should hear your company number announced as ‘calling ANI’. ‘Charge ANI’ should be either the same number or blank.

Who is the toll-free termination provider? If you have lots of such traffic and are using one that pays you compensation, they may block specific destinations; add your regular LD provider to the trunk list as failover.

If you are using one of the ‘free’ ones where you don’t have to have an account, IMO that’s a bad idea for several reasons (no call records and no support, among others). I recommend signing up with Flowroute. If you only send toll-free traffic, you don’t have to fund the account (you get $0.25 free trial test credit, which will last forever as TF calls are rated at 0). Or, pay them $40 and also use them as backup for your regular LD ($0.0097/min. + USF).

Call isn’t going to the Carrier - no CDR on system or at carrier, and it is working when dialed as 10-digit (routing patter makes it carrier-compatible (11-digit), and it routes).

@Stewart1 and @comtech

Failure is consistent ONLY with this TFN. Others in the 855 range work when dialed either way (system converts all to 11-digit format when sent to carrier so this is all on the PBX side), as do other TFN NPAs, and no we’re using a single carrier for all traffic.

Here’s the CLI Trace - note it’s sending it to RESTRICTED ROUTE, when it shouldn’t be:

-- Executing [[email protected]:1] Macro("PJSIP/1602-00000321", "user-callerid,LIMIT") in new stack
-- Executing [[email protected]:1] Set("PJSIP/1602-00000321", "TOUCH_MONITOR=1528305971.3252") in new stack
-- Executing [[email protected]:2] Set("PJSIP/1602-00000321", "AMPUSER=1602") in new stack
-- Executing [[email protected]:3] GotoIf("PJSIP/1602-00000321", "0?report") in new stack
-- Executing [[email protected]:4] ExecIf("PJSIP/1602-00000321", "1?Set(REALCALLERIDNUM=1602)") in new stack
-- Executing [[email protected]:5] Set("PJSIP/1602-00000321", "AMPUSER=1602") in new stack
-- Executing [[email protected]:6] GotoIf("PJSIP/1602-00000321", "0?limit") in new stack
-- Executing [[email protected]:7] Set("PJSIP/1602-00000321", "AMPUSERCIDNAME=Kristian Guntzelman") in new stack
-- Executing [[email protected]:8] ExecIf("PJSIP/1602-00000321", "0?Set(__CIDMASQUERADING=TRUE)") in new stack
-- Executing [[email protected]:9] GotoIf("PJSIP/1602-00000321", "0?report") in new stack
-- Executing [[email protected]:10] Set("PJSIP/1602-00000321", "AMPUSERCID=1602") in new stack
-- Executing [[email protected]:11] Set("PJSIP/1602-00000321", "__DIAL_OPTIONS=HhTtr") in new stack
-- Executing [[email protected]:12] Set("PJSIP/1602-00000321", "CALLERID(all)="Kristian Guntzelman" <1602>") in new stack
-- Executing [[email protected]:13] GotoIf("PJSIP/1602-00000321", "0?limit") in new stack
-- Executing [[email protected]:14] ExecIf("PJSIP/1602-00000321", "1?Set(GROUP(concurrency_limit)=1602)") in new stack
-- Executing [[email protected]:15] ExecIf("PJSIP/1602-00000321", "0?Set(CHANNEL(language)=)") in new stack
-- Executing [[email protected]:16] NoOp("PJSIP/1602-00000321", "Macro Depth is 1") in new stack
-- Executing [[email protected]:17] GotoIf("PJSIP/1602-00000321", "1?report2:macroerror") in new stack
-- Goto (macro-user-callerid,s,18)
-- Executing [[email protected]:18] GotoIf("PJSIP/1602-00000321", "1?continue") in new stack
-- Goto (macro-user-callerid,s,37)
-- Executing [[email protected]:37] Set("PJSIP/1602-00000321", "CALLERID(number)=1602") in new stack
-- Executing [[email protected]:38] Set("PJSIP/1602-00000321", "CALLERID(name)=Kristian Guntzelman") in new stack
-- Executing [[email protected]:39] GotoIf("PJSIP/1602-00000321", "0?cnum") in new stack
-- Executing [[email protected]:40] Set("PJSIP/1602-00000321", "CDR(cnam)=Kristian Guntzelman") in new stack
-- Executing [[email protected]:41] Set("PJSIP/1602-00000321", "CDR(cnum)=1602") in new stack
-- Executing [[email protected]:42] Set("PJSIP/1602-00000321", "CHANNEL(language)=en") in new stack
-- Executing [[email protected]:2] Set("PJSIP/1602-00000321", "ROUTEUSER=1602") in new stack
-- Executing [[email protected]:3] Set("PJSIP/1602-00000321", "ROUTEUSER=1602") in new stack
-- Executing [[email protected]:4] GotoIf("PJSIP/1602-00000321", "1?notblind") in new stack
-- Goto (from-internal,918555239355,7)
-- Executing [[email protected]:7] GotoIf("PJSIP/1602-00000321", "1?restrictedroute-4cd0d9ef0357e7e05cd758fb93856ade,918555239355,2:outbound-allroutes,918555239355,2") in new stack
-- Goto (restrictedroute-4cd0d9ef0357e7e05cd758fb93856ade,918555239355,2)
-- Executing [[email protected]:2] Gosub("PJSIP/1602-00000321", "sub-record-check,s,1(out,918555239355,dontcare)") in new stack
-- Executing [[email protected]:1] GotoIf("PJSIP/1602-00000321", "0?initialized") in new stack
-- Executing [[email protected]:2] Set("PJSIP/1602-00000321", "__REC_STATUS=INITIALIZED") in new stack
-- Executing [[email protected]:3] Set("PJSIP/1602-00000321", "NOW=1528305971") in new stack
-- Executing [[email protected]:4] Set("PJSIP/1602-00000321", "__DAY=06") in new stack
-- Executing [[email protected]:5] Set("PJSIP/1602-00000321", "__MONTH=06") in new stack
-- Executing [[email protected]:6] Set("PJSIP/1602-00000321", "__YEAR=2018") in new stack
-- Executing [[email protected]:7] Set("PJSIP/1602-00000321", "__TIMESTR=20180606-132611") in new stack
-- Executing [[email protected]:8] Set("PJSIP/1602-00000321", "__FROMEXTEN=1602") in new stack
-- Executing [[email protected]:9] Set("PJSIP/1602-00000321", "__MON_FMT=wav") in new stack
-- Executing [[email protected]:10] NoOp("PJSIP/1602-00000321", "Recordings initialized") in new stack
-- Executing [[email protected]:11] ExecIf("PJSIP/1602-00000321", "0?Set(ARG3=dontcare)") in new stack
-- Executing [[email protected]:12] Set("PJSIP/1602-00000321", "REC_POLICY_MODE_SAVE=") in new stack
-- Executing [[email protected]:13] ExecIf("PJSIP/1602-00000321", "0?Set(REC_STATUS=NO)") in new stack
-- Executing [[email protected]:14] GotoIf("PJSIP/1602-00000321", "3?checkaction") in new stack
-- Goto (sub-record-check,s,17)
-- Executing [[email protected]:17] GotoIf("PJSIP/1602-00000321", "1?sub-record-check,out,1") in new stack
-- Goto (sub-record-check,out,1)
-- Executing [[email protected]:1] NoOp("PJSIP/1602-00000321", "Outbound Recording Check from 1602 to 918555239355") in new stack
-- Executing [[email protected]:2] Set("PJSIP/1602-00000321", "RECMODE=no") in new stack
-- Executing [[email protected]:3] ExecIf("PJSIP/1602-00000321", "0?Goto(routewins)") in new stack
-- Executing [[email protected]:4] ExecIf("PJSIP/1602-00000321", "0?Goto(routewins)") in new stack
-- Executing [[email protected]:5] Gosub("PJSIP/1602-00000321", "recordcheck,1(no,out,918555239355)") in new stack
-- Executing [[email protected]:1] NoOp("PJSIP/1602-00000321", "Starting recording check against no") in new stack
-- Executing [[email protected]:2] Goto("PJSIP/1602-00000321", "no") in new stack
-- Goto (sub-record-check,recordcheck,12)
-- Executing [[email protected]:12] Set("PJSIP/1602-00000321", "__REC_POLICY_MODE=NO") in new stack
-- Executing [[email protected]:13] Return("PJSIP/1602-00000321", "") in new stack
-- Executing [[email protected]:6] Return("PJSIP/1602-00000321", "") in new stack
-- Executing [[email protected]:3] ExecIf("PJSIP/1602-00000321", "0 ?Set(CDR(accountcode)=)") in new stack
-- Executing [[email protected]:4] Set("PJSIP/1602-00000321", "ROUTE_CIDSAVE="Kristian Guntzelman" <1602>") in new stack
-- Executing [[email protected]:5] GosubIf("PJSIP/1602-00000321", "0?sub-diversion-header,s,1()") in new stack
-- Executing [[email protected]:6] Set("PJSIP/1602-00000321", "INTRACOMPANYROUTE=YES") in new stack
-- Executing [[email protected]:7] Set("PJSIP/1602-00000321", "MOHCLASS=default") in new stack
-- Executing [[email protected]:8] Set("PJSIP/1602-00000321", "_NODEST=") in new stack
-- Executing [[email protected]:9] Set("PJSIP/1602-00000321", "CALLERID(all)="Kristian Guntzelman" <1602>") in new stack
-- Executing [[email protected]:10] Set("PJSIP/1602-00000321", "_KEEPCID=TRUE") in new stack
-- Executing [[email protected]:11] Goto("PJSIP/1602-00000321", "app-announcement-1,s,1") in new stack
-- Goto (app-announcement-1,s,1)
-- Executing [[email protected]:1] Progress("PJSIP/1602-00000321", "") in new stack
-- Executing [[email protected]:2] NoOp("PJSIP/1602-00000321", "Playing announcement SIT-NonWorkingNum	") in new stack
-- Executing [[email protected]:3] Playback("PJSIP/1602-00000321", "custom/sit-nonwrkngnum,noanswer") in new stack
-- <PJSIP/1602-00000321> Playing 'custom/sit-nonwrkngnum.g722' (language 'en')
   > 0x7f77d8225c40 -- Strict RTP learning after remote address set to: 98.28.168.99:5046
   > 0x7f77d8225c40 -- Strict RTP switching to RTP target address 98.28.168.99:5046 as source

The marking for IntraCompany route made me realize, it is indeed getting caught on something ahead of time - AND the fact it’s playing the NonWorkingNum announcement… THere’s only 1 outbound route set with those rules, and it’s my very first one “RAN-DENY”. It’s a place where we list all the numbers we want to deny on the system. However, it shouldn’t be catching this number. Here are all those entries:
1809.
1900.
1NXX555.
1NXX976.
809XXXXXX.
900XXXXXX.
NXX555XXX.
NXX976XXX.
9|1809.
9|1900.
9|1NXX555.
9|1NXX976.

I see where I think it’s getting caught, but don’t believe it should be:
NXX555.

This phone number does have three 5’s in a row, but the pattern is 8555xxxxxx, and the rule is set for 8xx555xxxx, so it shouldn’t’ be matching against that.

You’ve got it.

A Dial Pattern is a unique set of digits that will select this route and send the call to the designated trunks. If a dialed pattern matches this route, no subsequent routes will be tried. If Time Groups are enabled, subsequent routes will be checked for matches outside of the designated time(s).

Rules:

X matches any digit from 0-9
Z matches any digit from 1-9
N matches any digit from 2-9
[1237-9] matches any digit or letter in the brackets (in this example, 1,2,3,7,8,9)
. wildcard, matches one or more characters
prepend: Digits to prepend to a successful match. If the dialed number matches the patterns specified by the subsequent columns, then this will be prepended before sending to the trunks.
prefix: Prefix to remove on a successful match. The dialed number is compared to this and the subsequent columns for a match. Upon a match, this prefix is removed from the dialed number before sending it to the trunks.
match pattern: The dialed number will be compared against the prefix + this match pattern. Upon a match, the match pattern portion of the dialed number will be sent to the trunks
CallerID: If CallerID is supplied, the dialed number will only match the prefix + match pattern if the CallerID being transmitted matches this. When extensions make outbound calls, the CallerID will be their extension number and NOT their Outbound CID. The above special matching sequences can be used for CallerID matching similar to other number matches.

Could you move your TFN route up?

I just edited the patters to specify exact length (rather than end with a period). What throws me is, with what I had in there, it shouldn’t have matched because it started with a 1, but the only one that would have matched was:
NXX555.
Having the N in there, it shouldn’t have found a match because a 1 was dialed. But, changing those entries to this worked:
1809NXXXXXX
1900NXXXXXX
1NXX555XXXX
1NXX976XXXX
809NXXXXXX
900NXXXXXX
NXX555XXXX
NXX976XXXX
9|1809NXXXXXX
9|1900NXXXXXX
9|1NXX555XXXX
9|1NXX976XXXX

The one that matched was NXX555XXX. (the N matched the initial 9) and your changes fixed the problem.

That just seems weird. IMO you should instruct your users not to dial an initial 9 – by dialing the same as they would on their mobile or home phones, there will be fewer mistakes. Also, you can set up the phones to process a call as soon as a valid 10- or 11-digit number is entered. The way it is now, if you dial e.g. 9165069700 (a valid number in Sacramento), the phone must wait a delay (or for the user to press Send) before completing the call, because you may actually be calling 916506970023 (a valid number in Millbrae).

Also, the block on (just) 809 seems strange. There are many NANPA area codes outside of US and Canada and most are expensive to call. See https://en.wikipedia.org/wiki/List_of_North_American_Numbering_Plan_area_codes#Caribbean_and_Atlantic_Islands . As an alternative to keeping track of these, your carrier may have a ‘maximum call rate’ or similar setting for the trunk.

Unfortunately debugging anything using a “restricted route” is not likely to succeed as it is obfuscated. Disable that module and try over.

Ah, that makes sense then. Thx, now I get why it was a match.

In terms of an “outside prefix”, user adoption of new systems has been far greater and far more successful when it functions the way they’ve been used to for years.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.