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?
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
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.
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.
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.
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!
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.
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
John’s Garage
Porter Hospital
Westchester Library
whereas now it displays:
Placed Calls
CID:2191234567 (our own number)
CID:2191234567
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…
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
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:
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
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:
The user knows what format your carrier requires for a given destination and if he uses the wrong one the call will fail.
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.
