System suddenly restarted, stuck in startup/reboot loop

Do you mean the dial patterns?

Its all in the logs.

you have a problem dialing 45673534 , then

grep 45673534 /var/log/asterisk/full

. . .

1 Like

Here is my Outbound Routes’ Dial Patterns. Hope helps

If you want to be able to dial local numbers by putting 7 digits number then replace the “1800” with your 1 + your local area code

1 Like

In your dahdi trunk settings, dial pattern tab add one or two w characters to the prepend field. This forces the pbx to wait for a second before attempting to dial.

1 Like

Thanks for the tips. These were the dial patterns that I copied from the old 4.211 system… seems like I might have too many or possibly some mistakes and/or conflicts?

It is a trial and success. If the one I send wont work you can always revert to yours but adding few more lines.

Also, do you usually make international calls? If not, I will not include “011.” If your system is compromised or been accessed by a bad person, they will make costly international phone calls.

also consider what @dicko suggested.

1 Like

KISS !!!

Delete everything you don’t completely understand, pseudo code :-

do while you don't yet understand
   add one that you do
   test it
  add another
  test it

Okay, I think we have it mostly working. I didn’t realize dial patterns were trial & error. But I deleted a couple and added a couple others and the numbers we’ve tested appear to be okay. Our Frontier service has always been stupid anyway (sometimes requiring a 1+ before local area codes with no rhyme or reason) so I’m sure our POTS is not helping matters. Maybe we can get over to SIP Trunks some day soon. :slightly_smiling_face:

I think the only two issues we have remaining are the caller ID issue:

if anyone knows anything about that?

And my “Restapps Daemon” not starting… little fire icon in the dashboard… but I think I can google that and try to find a fix. And things seem to be (mostly) working despite that error. Really if anyone has any insight about our incoming and outgoing caller ID showing on our phones instead of our server IP and “CID” that would be awesome. Then we can set this thread on fire and shut it down once and for all!

Nugget of understanding:

Inbound and outbound calling are almost entirety unrelated.

You process inbound calls so that they are handled within your PBX. This include the Caller ID. Now, knowing that you are using DAHDI and a “small” carrier, it’s likely that they aren’t providing Caller ID Information you can use (usually before the second ring). If that’s the case (let’s assume it is, since you can’t fix it if you leave it up to them), you need to implement the Caller ID Superfecta module. Basically, is takes the incoming caller ID number and looks it up in a series of “more costly, but more authoritative” services. The first (typically) is the “Line Data”. Comes with the call, but isn’t always correct enough. The second is the local CID cache, which is very cheap, but not likely to be helpful. After that, there are a ton of options that allow you to look up phone numbers. The search stops “on success”, so away you go.

For Outbound Calls, you need to set the Caller ID options you are comfortable with and you provider allows. Since you are DAHDI, most POTS providers do this “for you” (right or wrong) and don’t let you try to set the CID at all. If you have the option, you’ll probably need to talk to Frontier and get their “input” on what you can do. The simplest is to set the CID in the Trunk and don’t allow anyone to override it.

1 Like

Let’s give the community an output to look at, may be this can help

Make a call to 45673534 then
grep 45673534 /var/log/asterisk/full

You will have a line like
[2019-12-17 11:51:04] VERBOSE [20145] [C-0000001e] …
grep "\[20145\]" /var/log/asterisk/full

Copy and Paste the output.

grep "\[20145\]" /var/log/asterisk/full | pastebin 

It gives you a pastebin URL, easier to read…


This is the behavior when you call out on a trunk. It shows you the caller ID you have sent out. Elsewhere on your phone’s display, you should see the number you dialed.

If you are calling internally, that field will show the name of the person whose extension you dialed.

These behaviors are coded into the dialplan and I do not believe they are adjustable.

I should have time tomorrow to try the log commands described above, but I did just want to mention that before the old system went down and was rebuilt on the newer versions, the old system did used to show the actual outgoing caller ID on the phone displays. After we dialed, or when connected, it would display “John’s Garage <2191234567>” on the phones.

That was using FreePBX 4.211 and Asterisk 11. Only since the rebuild (FreePBX 15 + Asterisk 16) is it now displaying the trunk/dialplan behavior you describe.

This carries over to viewing the “Placed Calls” list on the phone’s history. It used to show a list of proper caller IDs to scroll through to see who we’ve dialed out to:

Placed Calls

  1. John’s Garage
  2. Porter Hospital
  3. Westchester Library

whereas now it displays:

Placed Calls

  1. CID:2191234567 (our own number)
  2. CID:2191234567
  3. CID:2191234567

so we can’t actually see on the phone who we called out to in the call history.

Is it because we are using older Polycom phones? Are they not fully compatible with any “new” changes to the way trunks/dialplans work in FreePBX 15 / Asterisk 16? Or what might have changed from our old FreePBX 4 / Asterisk 11 build that would have changed this functionality? If it’s not the newer software with the older phones, maybe there is some setting somewhere that I’m missing…


These settings in the Extension should allow you to get connected-line information back to the phones, which I believe is what you are describing.

1 Like

@billsimon Perfect, it worked! Thanks so much!

It turned out there were probably two ways to do this. The first was to go into this setting you gave me, under each extension, and change the “Send RPID” to NO.

But searching for “Send RPID” led me to this thread, which, coincidentally, had the EXACT same phones (Polycom IP330) that we have, showing CID:EXT on outbound calls:

… which led me to (in case anyone else comes across this): Fixed this by going to Advanced Settings in FreePBX and then under Dialplan and Operational (about half way down the page) I set “Display CallerID on Calling Phone” to False. Now the original caller ID is working on transferred calls and the proper outgoing numbers are appearing on outgoing calls :slightly_smiling_face:

Plus it was a single global setting instead of having to modify each extension in case there were any adverse effects. But it was definitely this RPID setting that led me to the fix. Thanks again!

With the caller ID situation solved, the ONLY other issue we’re having is some goofiness with dialing out. Even for local calls, sometimes we can dial the 7-digit, sometimes we need to add the area code (219) and do the 10-digit, and sometimes it requires all eleven digits (1 + 219). I think one or two numbers wouldn’t dial out at all… but right now 90% of our calls are working. All said and done we’re pretty happy with it. It’s just getting those last 10% to all work and we will be golden.

Here is the log from trying to dial 45673534, as you guys asked:

* [2019-12-18 09:41:40] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:1] ResetCDR("PJSIP/223-00000141", "") in new stack

* [2019-12-18 09:41:40] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:2] NoCDR("PJSIP/223-00000141", "") in new stack

* [2019-12-18 09:41:40] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:3] Progress("PJSIP/223-00000141", "") in new stack

* [2019-12-18 09:41:40] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:4] Wait("PJSIP/223-00000141", "1") in new stack

* [2019-12-18 09:41:41] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:5] Playback("PJSIP/223-00000141", "silence/1&amp;cannot-complete-as-dialed&amp;check-number-dial-again,noanswer") in new stack

* [2019-12-18 09:41:41] VERBOSE[18475][C-000000d2] file.c: &lt;PJSIP/223-00000141&gt; Playing 'silence/1.ulaw' (language 'en')

* [2019-12-18 09:41:42] VERBOSE[18475][C-000000d2] file.c: &lt;PJSIP/223-00000141&gt; Playing 'cannot-complete-as-dialed.ulaw' (language 'en')

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] file.c: &lt;PJSIP/223-00000141&gt; Playing 'check-number-dial-again.ulaw' (language 'en')

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:1] Macro("PJSIP/223-00000141", "hangupcall") in new stack

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:1] GotoIf("PJSIP/223-00000141", "1?theend") in new stack

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx_builtins.c: Goto (macro-hangupcall,s,3)

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:3] ExecIf("PJSIP/223-00000141", "0?Set(CDR(recordingfile)=)") in new stack

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:4] NoOp("PJSIP/223-00000141", " montior file= ") in new stack

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:5] GotoIf("PJSIP/223-00000141", "1?skipagi") in new stack

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx_builtins.c: Goto (macro-hangupcall,s,7)

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx.c: Executing [[email protected]:7] Hangup("PJSIP/223-00000141", "") in new stack

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] app_macro.c: Spawn extension (macro-hangupcall, s, 7) exited non-zero on 'PJSIP/223-00000141' in macro 'hangupcall'

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx.c: Spawn extension (from-internal, h, 1) exited non-zero on 'PJSIP/223-00000141'

I VERY much appreciate all the help.

NANP numbers are of the format


some locales need use NXXNXXXXXX for instate and 1NXXNXXXXXX for out of state, landlines usually accept NXXXXXX but 45673534 won’t work, check in your local white pages what is needed exactly, if you can settle on a standard 10 or 11 digit pattern then prefix prepend your outbound routes to suit, it will be much easier for when you add VoIP trunks

(N is 2-9 ,X is 0-9 )

The example you gave, 45673534, has 8 digits so it didn’t match any outbound route (and would not have worked even if it did). Please post a log for calling a valid number.

You can take either of these approaches:

  1. The user knows what format your carrier requires for a given destination and if he uses the wrong one the call will fail.
  2. The PBX will accept 10 and 11 digit dialing for all domestic calls and accept 7 digit dialing for all calls in 219 and automatically converts the number to what the carrier wants.

I will say that the code you posted above:

do while you don't yet understand
   add one that you do
   test it
  add another
  test it

is working great. :grin:

1 Like

Another longing post - it’s what I do:

For outbound calling, there are two places that deal with number patterns.

The second is the Trunk. In my world, the Trunk is there expecting a number in one of three formats:

  1. Local Dial format (usually NXXXXXX).
  2. Long Distance format (usually NXXNXXXXXX)
  3. International Calling (usually 011. - the dot is important) Note that none of my installations allow for international calling, so I don’t actually use this one very often.

The first is the Outbound Route. This uses the number patterns to choose which Trunks will be used and to ‘reformat’ whatever gets sent from the phones into a format that makes sense. My outbound routes always strip off the ‘1’ on the front and then determine if the call makes sense as a local call (7 digits in the NXXXXXX format). Because of the nature of MY local calling area, all phone numbers are 10-digit (even if all that gets dialed is seven), so my Outbound Route will take care of that and make sure the call gets reformatted to match the rules for my Trunk.

So, let’s say (for example) that one of my people dials a 7-digit number. It gets picked up by my “catch-all” outbound route. I can either reformat it to 10 digits, or I can pass it to the trunk as a seven digit number. When I had DAHDI lines going out, I’d pass it to the DAHDI trunk “as is”. I’d also check for ‘non-local instate’ numbers (which required 10 digits, but no ‘1’) and pass those to DAHDI.

With my SIP trunks (which require 10-digit either with or without a ‘1’, depending on the carrier), I’d set up two trunks, one for each provider. Since I always pass 10-digit numbers to these trunks, if the first one takes the call, it will send the call (since the provider doesn’t want the ‘1’). If the second one takes it, the trunk can add the ‘1’ on the front and send the call.

My method, then, it to set up as many outbound routes as you need for your dialing situation. The “discard+match” has to match whatever number is being presented by the PBX. After that, you need to modify the number into one of a couple of different “master format(s)” that your trunks can expect and process.

Hope that helps.