System suddenly restarted, stuck in startup/reboot loop


#101

Also - more importantly - we cannot dial out to certain numbers. We’ve discovered this throughout the day. A handful of local numbers, no matter how we dial them:

1234567
2191234567
12191234567

the call will not go out.

The 7-digit and 10-digit w/ area code versions prompt an immediate system message, “Your call cannot be completed as dialed” (sounds like a recording ON the FreePBX system, played immediately, BEFORE connecting to anything)… while the 1-digit w/ 1+area code version rings once or twice and “connects” but then gives the old-school phone company message “Beep-boop-beep! We’re sorry, your call cannot be completed as dialed.”

Again, it’s only certain numbers, seemingly at random, with no rhyme or reason as to which ones work and which don’t. They’re all local, all the same area code. Most calls have worked today but what would cause certain specific ones to trigger the above error?


#102

Likely a badly defined set of outbound routes that are either sending the INVITE to the carrier you chose in a format they don’t like or the lack of any outbound route that matches what was dialed .

A) check your logs , if that shows goodish
B) check with your VSP


#103

Do you mean the dial patterns?


#104

Its all in the logs.

you have a problem dialing 45673534 , then

grep 45673534 /var/log/asterisk/full

. . .


(Moussa) #105

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


(Lorne Gaetz) #106

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.


#107

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?


(Moussa) #108

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.


#109

KISS !!!

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

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

#110

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!


(Dave Burgess) #111

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.


(Moussa) #112

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] …
Next:
grep "\[20145\]" /var/log/asterisk/full

Copy and Paste the output.


(Itzik) #113
grep "\[20145\]" /var/log/asterisk/full | pastebin 

It gives you a pastebin URL, easier to read…


#114

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.


#115

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…

Thanks!


#116

image
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.


#117

@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!


#118

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:

http://pastebin.freepbx.org/view/a5e0dc07

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

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

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

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

* [2019-12-18 09:41:41] VERBOSE[18475][C-000000d2] pbx.c: Executing [45673534@from-internal: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 [h@from-internal:1] Macro("PJSIP/223-00000141", "hangupcall") in new stack

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx.c: Executing [s@macro-hangupcall: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 [s@macro-hangupcall: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 [s@macro-hangupcall:4] NoOp("PJSIP/223-00000141", " montior file= ") in new stack

* [2019-12-18 09:41:45] VERBOSE[18475][C-000000d2] pbx.c: Executing [s@macro-hangupcall: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 [s@macro-hangupcall: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.


#119

NANP numbers are of the format

1NXXNXXXXXX

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 )


#120

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.