FreePBX 14.
Whenever a user tries to call someone back by selecting “callers” from the top softkey it says seize failed. If they manually dial the number the calls works fine. Any thoughts?
Here’s the log output:
Call from ‘34029’ to extension ‘+(the phone number was here)’ rejected because extension not found in context ‘from-internal’.
You trunking provider is probably sending caller IDs with the initial + sign. Do they appear that way on the phones?
If so, you could add patterns to your Outbound Route(s) to permit the initial +, stripping it if needed.
Or, you could use a trunk context such as from-pstn-e164-us (or make your own if needed). Note that from-pstn-e164-us will reduce both caller IDs and DIDs to 10 digits (for US numbers). If your provider sends the initial + on DIDs and your Inbound Routes use that pattern, you’ll need to adjust them.
Yes they do show as “+(11 digit)” on the phone callers list. We use Bandwidth as our SIP provider. We have an east coast and west coast trunk with them. Since I’m not that great with Asterisk and FreePBX can you help me to add those patterns to the outbound route? Thanks Stewart!
I would remove the “+” in the Inbound Context and not send it at all, unless Bandwidth as suddenly starting requiring the “+”. On the Inbound Trunk, change the context to “from-pstn-e164-us” to normalize the numbers into the “normal” 10 digit format that I expect (even though I could be wrong) is what everyone actually wants you to use.
So I do know that if I go into the trunk and remove the + from the “outbound dial prefix” that breaks all outbound dialing. So maybe Bandwidth requires that.
Changing the context didn’t fix it.
OK. The ‘from-internal’ context you are using on your extensions is looking for a 10-digit number without a “+” on it. That’s why it’s failing. If Bandwidth requires the “+”, you need to change your trunk number rewrite rules to add the “+” on the way to that trunk. The Outbound Routes should us normal 10-digit dialing rules (no “+”) so that everything matches.
Change the inbound trunk to use the ‘from-pstn-164-us’ context. That will strip off the ‘+’ sign and get your numbers so that they match everything else the system is expecting (Caller ID look-ups, etc.).
Just so we’re clear - I’m done guessing. You’ve been here long enough to know the kind of information we need to help you. “That didn’t work - guess again” isn’t a game I have time to play.
Sorry I didn’t mean to offend. I changed the context on the inbound trunk so it said “context=from-pstn-164-us” instead of “context=from-trunk” and when I made a test call in the callerID still showed the number with a +. Thanks for your help. I wasn’t trying to make you play a guessing game. My bad.
Do I need to do a fwconsole restart or something so that context change strips the +?
The actual name of the context is:
from-pstn-e164-us
You will need to do an apply config (not restart), and from that point forward incoming calls should show a Caller ID Number without the leading + character.
I must still be missing something. I put “context=from-pstn-e164-us” in the incoming section of both my Bandwidth trunks. Submitted and applied config and then called in from my cell phone. The + is still there.
Put in peer details as well.
As soon as I put it in peer details my test call gave me “The number you have dialed is not in service…” I thought that might be because my inbound route has the + so I removed it there but it still does not go through. Same recording.
Weird thing is, I have several other PBX’s with these exact same trunk and outbound route settings and they don’t have a problem making a call from the callers list. Even with the +
Also remove the 1. DID field should be 10 digits.
Thanks, I’ll give that a try and report back
Your /var/log/asterisk/full log should be telling you what’s actually happening in the inbound call. I’m reasonably certain the answer is there.
Yeah this is what I see in the full log. I posted in the second post. Even if the workaround fixes the issue I would then have to delete every inbound route (almost 400 of them) and then re-import them without the + and 1. This was working a couple of months ago. I’m not sure what has changed. Also I have several other PBX’s with the same exact setup and they don’t error out at all when calling from the call list. I’ll have to see if I can test this after hours so I don’t break 400 users ability to call out at all. Thanks again for your help.
Just did a test on a working PBX. Interesting to see that it says “stripping + from start of number”
pbx.c: Executing [+18888880435@from-internal:1] NoOp(“PJSIP/77283-00013a95”, “Stripping + from start of number”) in new stack
[2019-06-10 14:32:02] VERBOSE[27861][C-00013e27] pbx.c: Executing [+18888880435@from-internal:2] Goto(“PJSIP/77283-00013a95”, “from-internal,18888880435,1”) in new stack
(added the 8’s for privacy on the forums)
So I need to look through that PBX and see if I can discover why it’s stripping the + and this other one isn’t.