Is it just me? extensions_custom.conf not working with Asterisk 16

I just installed a new FreePBX14 server from the latest FreePBX distro install, and this time I chose Asterisk 16 instead of 13.

I have 2 [current as of 9/15/2020]FreePBX14/Asterisk 13 installs, and the below code works on these two servers - but on my new freePBX/Asterisk16 install, It appears that extensions_custom.conf is not being recognized…?

What I’m doing – in extensions_custom.conf, I have added the following:

[from-pstn-add-one]
;add one to CID number for redial purposes
exten => _X.,1,GotoIf($["${LEN(${CALLERID(number)})}" != “10”]?notten)
exten => _X.,n,Set(CALLERID(number)=1${CALLERID(number)})
exten => _X.,n,Set(CALLERID(name)=${CURL(https:/my\ [email protected]/v2/phone/${CALLERID(num)}?format=pbx&ref=freepbx)})
exten => _X.,n(notten),Goto(from-pstn,${EXTEN},1)

and then in my SIP trunk, I put context=from-pstn-add-one

When I make an inbound call, I get a busy and the full log says “Call from ‘mytrunk’ to extension ‘s’ rejected because ectension not found in context ‘from-pstn-add-one’”

Of course when I set context for my SIP trunk to from-pstn, calls go through.

Really all I want to do is prepend a 1 to the incoming CallerID, and do a openCNAM lookup…

Maybe I’m doing it wrong or the hard way? if so - please enlighten me… ha!

But as I said, both of my other Freepbx/ Asterisk13 servers are working with this method.

I THOUGHT that all I had to do was add a new context in extensions_custom.conf, and add some code, and then perform Goto [another context|, and then when I route my trunk to the new context, it would run the commands there, and the call would (in this case) follow my command to Goto [from-pstn] and continue… but maybe I’m off base on this… ? I’ve checked owner and file rights. Also rebooted the server just to make SURE everything restarted

Your incoming calls are arriving without DID information. That’s why it is looking for extension “s.” The custom context is fine.

I have since started using the builtin CallerID lookkup sources in FreePBX gui so I don’t need to do the opencnam look up this way - now all that remains is to [somehow] have my CallerID numbers show as 1+10 digits - instead of just 10 digits (currently passed from voip.ms)

-My dial rules are set so users dial 1 +10 for all outbound (usa/canada) calls, and it’s a pain to always [edit-dial] to add the leading 1 to missed calls…

Probably a better way to do that …?

Thanks Billsimon… (now if only I knew how to “fix” that – since I use voip.ms for all three systems - )? not sure why this one seems to be behaving differently…?

If you are still using chan_sip trunks and you have a single number with your provider then you might just need to add it at the end of your registration string like user:secret@provider/didnumber

It was because I [stupidly] forgot to check the “this is an asterisk system” box on voip.ms

YOU sir are the MAN!
thank you

why on earth are you messing with the inbound CID?

You simply design your outbound routing to handle things properly.

I guess I haven’t figured out a better way to deal with this short of [clumsy to me] dial 9 or 8 to get outside - what I have done is set our system to route outbound any calls 1+10. (No need to dial 9, or 8 or whatever to get an outside line.) In addition, I set a dial pattern for 3xxS0 - so if you dial one of our extensions, it will immediately dial on the 3rd digit. There is no way I can think of to allow users to dial an internal extension 3xx immdiately PLUS allow 312.xxx.xxxx to hit chicago for example…
Adding 1 to the CID makes it so all call history in the phone are 1+10 - so you can just view call-history and hit dial.
To me this is a lot better than edit–dial the phone’s call history - to add 1 or add 9 and then have an outbound rule that removes 9 and adds 1.
Everyone understands 1+10 dialing and it just makes sense to them. can even do that on their personal cell phones (although not required by most providers)

AND all it requires to do this is to add 1 to inbound 10 digit CID - presto…

1 Like

This is a basic outbound route setup for standard 10 digit dialling, also accounting for the odd user that dials the 1, as the old people used to dialing 7 digits locally, as well typical international.
image

Dial patterns for immediate calling don’t have anything to do with routing.
Here is a sample from Yealink phones.

dialnow.item.1 = 911;2xx;[2-9]xx[2-9]xxxxxx;

Seems to me that he understands the concepts fine and preferred to set it up with caller ID normalized to include a 1 at the front. What’s invalid about that? Some providers send caller ID in full E.164 format including the + and people put them through a context that normalizes them to 10 digits. To each his own?

I’m also good with this - the point I usually try to make on this is “pick one”. Having numbers with and without various pieces makes things like Caller ID reporting, CDR reports, and CRM interfaces more challenging than required. Settle on one format and use it - I personally don’t care what the format is, just use the same one all the time.

1 Like

@mickier, to answer the initial question, here is your dialplan:

[from-pstn-add-one]
;add one to CID number for redial purposes
exten => _X.,1,GotoIf($["${LEN(${CALLERID(number)})}" != “10”]?notten)

the first exten line shows _X.. The underscore means this is a pattern match, the X means a digit between 0-9 and the trailing dot means one or more additional characters. This is the stock exten value when you want to match any sequence of digits.

Initially your provider was configured not to send the numeric DID as part of the INVITE, which Asterisk interprets as an s. The dialplan you’ve written is expecting a numeric value, so there is no match for the s. That’s what was indicated by this log line:

the full log says “Call from ‘mytrunk’ to extension ‘s’ rejected because extension not found in context ‘from-pstn-add-one’”

You’re dialplan will fail again in future if you ever receive a SIP INVITE without a purely numeric string. The fix for this is to adjust the exten lilnes such that it will match any string not just numeric, i.e.:

from-pstn-add-one]
;add one to CID number for redial purposes
exten => _.,1,GotoIf($["${LEN(${CALLERID(number)})}" != “10”]?notten)
   ... etc
2 Likes

[small lightbulb going on in my head] That is very helpful information thank you. I’ll try it.
Truthfully, while I’ve installed freepbx in seven small offices around my organization over the past few years, this one install has had enough little bugaboo’s and has showed me how LITTLE I actually know about Asterisk and phone technology at all… LOL!
Thankfully I have access to all of YOU.

Blessings on you

ps. even that original code I’m using was copied from someone in here… I admit it freely

1 Like

To me they do - to the extent that in my example, once I press 3 digits in my phone (cisco spa525g2) starting with a 3, my phone will not accept any more digits - the call has already been placed – so then no more numbers would ever reach my switch.

I know I don’t have to do it this way but I think it’s kinda smooth… and my users like the instant-dial.
I was just answering your original question - “why on earth are you messing with the inbound CID”

I’m certainly interested if there’s a better way to handle it.

How many extensions are on your system? If you are willing to renumber them, set up the system so (where possible) you don’t have valid numbers that are a prefix of other valid numbers. For US- or Canada-centric systems, both 10- and 11-digit dialing are accepted, but incoming domestic caller IDs are presented as 10 digits. For 20 extensions or fewer, they are numbered 100-119. For up to 100 extensions, one option is: 100-119, 290-299, 390-399, …, 990-999. If the customer dislikes the discontinuous ranges, we use 1000-1099. The latter requires dialing an extra digit, but manual extension dialing is rare; frequently called extensions are on BLF keys or contact entries.

If you want to allow 10-digit dialing without renumbering, you could replace 3xxS0 with e.g. 3xxS4; users are unlikely to pause more than 4 seconds after dialing an area code. When dialing an extension manually, the user can avoid the delay by pressing # after the number.

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