I built a new Freepbx server around an Intel NUC to replace an aging Trixbox server and all phones which are on the same subnet as the server can hear audio between themselves but nobody at remote sites can hear audio in or out. The firewall is exactly the same between the two servers (they both have the same IP address so I only have one running at a time). The old server was running Asterisk 126.96.36.199-FONCORE-r78 whereas the new server is:
UDP Ports forwarded 5060, 4569, 10000-20000, 5004-5037, 5039-5082.
RTP debug only showed packets going out, none coming in.
I have verified that:
is on both old and new server
CHAN SIP is set for port 5061, CHAN PJSIP is using 5060.
SIP NAT is setup and RTP debug shows the external IP address, not the internal ip address of freepbx.
Im not sure what else to take a look at
I’m going to guess that your NAT settings (in the SIP settings entry on the Advanced menu) are probably not optimal. If you check the outgoing packets, I expect you’ll see that the server is sending its nonroutable address to your remote phones.
The “Sent RTP packet to” log message is showing the public ip address that the phone system hangs off of. I should have mentioned (and will update) that I did setup the NAT properties as part of my debugging this.
OK, well also remember that PJSIP (which wasn’t available in TrixBox) and SIP are both competing technologies on your new installation. Make sure you have everything set up the way whichever channel driver you are expecting to use wants.
That’s a horrible sentence, but I hope you know what I mean.
I should probably figure out how to disable PJSIP then so that I am only working with SIP which was used in Trixbox. Would this make sense as a step forward to simplify things?
MY OPINION - Yes, disable PJSIP at least until you get everything else working. If you want to add PJ-SIP later (it is the direction Asterisk is headed) you can at any time by changing a few settings and restarting your server.
I will bring the new server up once my boss is off the conference call he is on. Is it as simple as removing PJSIP from the list of available technologies in Advanced Settings?
Pretty much - yeah. Make sure the options for the SIP settings are right.
I switches to just using CHAN_SIP in advanced settings then went and recreated 4 of the extensions which I had previously created as PJSIP as just SIP and was able to make calls within our office and to outside lines but not between extensions that are inside and outside the office. I monitored the firewalls log and didnt see any dropped packets designated for the PBX. Im stumped.
Wait, say that again, but this time, explain what you are and aren’t seeing. There are a dozen versions of failing “between inside and outside”, each of which has a specific solution set.
We need to know what phones are getting registered, if the external ones can call out, if the internal ones can call out, you know - a map of what is and isn’t working.
I’m going to suggest that you might want to review the intergrated and adaptive firewall settings (two different parts of the firewall) to make sure that everything in there makes sense.
Quick add: You may need to restart the server to get everything going the way it needs to be, and you might need to check the firewall settings. Trixbox didn’t have any kind of integrated firewall, so that is one of the pieces that is immediately suspect from your old configuration to the new.
Internal Extension to outside phone WORKS
Internal Extension to Internal Extension WORKS
Internal Extension to External Extension NO SOUND
The system firewall is turned off. I dont see any settings for an adaptive firewall.
So there is something in the RTP settings in your firewall that is not working.
Obvious suspects include the phone configuration (which should not have changed) and the firewall/router into your local network.
Can your external extensions call out to outside phones?
Are you external extensions connecting via VPN?
Something in the NAT configuration of either the SIP channel (I assume you’re using SIP) or the redirection of the UDP 10000-20000 ports is getting in your way.
One possibility that comes to mind is that your internal phones are trying to talk directly to the external extensions. There’s a setting that basically says “Try to make the phones talk to each other instead of going through the server.” I can’t remember off the top of my head (something-direct-something), but that might be getting in your way.
Have you tried using wireshark at each end to see where the audio channel is actually getting routed?
I will try to setup a day this week when I can bring the new server back online to test but now that the holidays are over thats going to be more difficult. That way I can get more information to try to figure out the configuration issue.
The phone config hasnt changed
The firewall/router configuration hasnt changed
I will try to find out if external extensions can call outside phones
the external extension connect to the external ip of the firewall.
I havent tried wireshark on each end.
Im hoping that I can do more testing Wed morning.
External extensions can NOT hear voice in either direction when dialing outside lines.
OK, so it sounds like the external extensions are having a complete RTP meltdown.
Don’t take this the wrong way, but good. It really narrows the scope of the problem.
We are now looking at a classic “one-way audio” problem. Everything is working but the remote extensions, which are outside the firewall. The NAT and redirection rules that should have been applied to your Trixbox server are still in place, so as long as the IP address of the server doesn’t change (and you flush the ARP cache for your router) you should be getting connectivity.
So now we can focus on what is different between the extensions in TrixBox and FreePBX. The first, and most obvious difference, Is the integrated firewall. I know you’ve said you disabled it, but could you turn it on, please?
Here’s what I’d like to get you to try:
- Turn the firewall back on and set it up. All of the Interface should be in the “External” zone (so the filters will be applied by default). If you have an interface that cannot be reached from the Internet, you can put that one it the “Internal” zone.
- Start adding your “known” destinations as “Internal” or “Trusted” (I’d use Trusted) so that the firewall filters will ignore them. These include your local network, any trusted networks where your extensions may be sitting, and your SIP and DNS providers.
- Turn on the Adaptive Firewall and have it manage the connections to your Chan-SIP channel driver. This way, the RTP filters and redirection should work automatically.
- Finally, if you have the Sysadmin module installed, go in there and set up the port filtering stuff in there. Add your “trusted” zones to the network whitelist. I know it’s belt-and-suspenders, but it’s just another place that should work, but making sure it works can’t hurt us.
With these changes in place, the stuff the only other place that can hurt us is the system firewall.
It’s simpler than that. You have to exclude your routed networks from channel_sip NAT.
trixbox is quite old and as such used an old version of FreePBX that you had to set you local network in a file.
Look in etc/asterisk on the trixbox system and run ‘grep localnet *’ from that directory. Copy the networks referenced in the localnet variable into the localnet field in the sip settings module of the current FreePBX.
You will be good to go.
Ive run into an issue where my outside extension are no longer connecting in and Im not sure why. Im going to have to find time to restore the last backup I made and step forward again. Im stuck only able to work on the phone system for a short period of time each morning.
I ended up doing a restore from before removing PJSIP then removed CHAN_SIP instead to keep all the extension info I already had configured. Then set SkyKing’s setting for the NAT and I am able to have two way communication on external extensions.