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.
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?
[/quote]
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.
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?
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.
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!