We’ve recently added two remote extensions to our freePBX setup, and neither is able to dial long distance.
The ISP at our remote site won’t allow us to use our own router, and while they fix their issue I am having the phones register via the internet. Ultimately the phones will be connected via a gateway to gateway VPN, and so this shouldn’t be an issue. I know this is not secure as it currently stands, but I’ve been giving no option for the next few weeks and I am closely monitoring for any toll fraud or breaches.
However, as it stands now the phones can dial local numbers, but not any long distance. We do not have any restrictions in place on long distance calling. The only thing that stands out is that local calls are slow to complete, is it possible the dialling is timing out? I’ve watched the logs and console to try to diagnose the issue, but long distance calls aren’t even registering in CDR or when watching the live console.
Does anyone have any insight?
I’ve added the remote network range to the local network under sip settings, and I now have the remote office setup with a static IP. Should I put that in the firewall, or add it as well to the local network settings? Is that why long distance isn’t available to them?
Sounds like a reasonable setup. [quote=“brickhost, post:2, topic:38991”]
Is that why long distance isn’t available to them?
The reason long-distance is working is probably one of two possibilities:
- The system is set up using a different context for your local phones than your remote phones. I’m guessing you’re using “from-internal” for the local phones and “from-something-else” for these (because that would be logical). Set them all up as “from-internal” and you should see some improvement.
- The “remote” phones are using a Caller ID that isn’t allowed by your carrier and are (therefore) getting blocked.
They are set to from-internal, and the CID is being set by the outbound trunk and not the phone but I’ll set it to a proper form in the extension to see if that makes a difference. It’s the oddest thing as these phones were simply moved from the internal main network to the remote network (context and CID were not changed). On the server IPs were updated.
I went back and looked at your original problem report and this is the only thing that stands out. Tell me more about “slow to connect” and provide a /var/log/asterisk/full excerpt for a call that should be able to connect to LD and isn’t.
I’ve pulled the full log and had the remote extension make a call, all they receive is dead air and the call isn’t even registered in the log.
I do however see these messages sporadically, would they be related?
[2017-01-23 10:40:04] WARNING[C-00002eeb] chan_dahdi.c: Don’t know what to do with frame type ‘10’
Calls are being routed out via dahdi to centrex pots lines.
Thanks for all your help!
To me, this means you are routing the calls from the PBX (which can add a second or two of delay) to a local Centrex PBX (which will add a lot of delay) before the call is routed to the PSTN. Is that an accurate assessment of your system?
Yes, it is. Would it then be a matter of increasing a tolerance for the delay? Or is there another way around this?
It just seems like a lot of steps to get the call where you are going. It’s also possible that the Centrex is waiting for something before it dials the call, kind of like dialing a phone number without a dial plan in SIP.
It’s as straight forward as it can be in terms of dial pattern, we just prepend 9 which is what triggers Centrex to dial. So folks just dial the 7 or 10 digit number and get connected right out. I can post our dial patterns and plans if that would help, or I can change things so 9 gets prepended in the trunk rather than outbound route.
I’m sure it’s fine - I’m just trying to help you figure out why you calls are delaying…
If you know for sure that this is all good, then it must be something else.
Thank you, it’s the oddest thing, they worked just fine before being moved outside the main office. Local calls work without issue, inter-extension calling all works.
Would there be a firewall or something that would block long distance calls? Though I have included the remote subnet as a local network.
Maybe to diagnose the issue I’ll setup a voip outbound route and see if they have any issues with that.
Just to circle around to this and mark it as solved. The issued turned out to be the codecs on the Aastra phones, they had to be set to basic to work properly over the web!