No incoming sound in chan_sip on 5160

Asterisk version: 13.13.1 (after yum update)
FreePBX version:
Distro installed: FreePBX-64bit-10.13.66
All FreePBX modules are up-to-date.

Right now PJSIP on 5060 and on 5160 works fine
Chan_SIP on 5060 drops incoming calls after ~30 seconds, and the issue I’m trying to solve right now is Chan_SIP on 5160 (default port), I can’t hear anything from the other side of the call, but they hear me (outgoing and incoming calls).

I tried to turn off the IPTables for a moment, just to make sure it’s not the problem, and the built-in firewall module is off.
The hosting company don’t believe there’s anything on their end that can cause that.

Also, what do you think about reinstalling the distro with Asterisk 11 instead of 13? this is a production server and my organization counts on it, maybe Asterisk 11 is more stable/mature?

These are classic symptoms of one-way audio. It is almost always a problem in the firewall setup for your system.

I’m going to guess that the incoming call gets dropped because there was incoming audio traffic for 30 seconds. This is another symptom of firewall configuration issues.

Thanks, do you think it has to be on the server side, or can it also be something on the client side?

The thing is, the hosting company for my PBX saying they have no firewall on their end, and the problem exists even when I temporarily disable IPTables on my server…

On the other hand, I’m currently visiting Spain, and the internet here is terrible, I won’t be surprised to hear that they mess up with VOIP packages (originally I used “Vodafone” and they’re known for blocking VOIP, so I moved to Orange, which I hope they don’t, but who knows…).

Many thanks!

There are at least two places that can be causing a problem:

  1. The firewall is not passing the RTP traffic (normally UDP ports 10000-20000) to the server. This can be an issue if the client decides to pass traffic outside those parameters. Note that’s an unusual problem, and easily tested by using a different client. It can also be a problem is your external firewall (which your hosting provider says he isn’t using) is not configured correctly.

  2. You need to set up the Integrated Firewall. Make sure that all of the ports associated with your system are considered “external” so the firewall will trap traffic, then set up the hosts associated with your system so that they can reach in. If you are using Cell Phones (for example) to connect to your VOIP services, you may need to also set up the Adaptive Firewall to allow those systems to connect to your system.

  1. Just to remind, with PJSIP I have NO ISSUES at all, it’s only with Chan_SIP, so it’s hard for me to understand how firewall can block the traffic of Chan_SIP but allow it with PJSIP.

I also tried to setup a fresh installation of the FreePBX Distro with Asterisk 11, where the Chan_SIP is the only option, and the issues exists there too.

  1. Please explain for my knowledge, how activating the Integrated Firewall (I assume you’re referring to the FreePBX Module) can solve issues. I thought it’s another layer of protection and can only add more restrictions on top of the regular IPTables…

We don’t care - it is two different channel drivers. If the issues exist in two different installations, the problem isn’t in the installations. It’s like saying “HTTP and FTP are both file transfer protocols, so I don’t understand how allowing port 80 wouldn’t let me access FTP.”

… there are literally THOUSANDS of installations that are working that way. This isn’t some thing we tossed together over the weekend. People have been working on FreePBX for over 10 years. The Chan_SIP driver has been out for as long as Asterisk has been around - I doubt that your one-way audio problem is a driver problem.

For a fresh install, the problem is ALWAYS a firewall problem.

OK - your story is that your cloud vendor has given you server space out on the Internet that does not have a firewall, right?

You need one.

Notice that there are no caveats - that sentence ended right where it should. Even if you have one, you should implement the Integrated Firewall so that when people access your local network, they can’t gain unauthorized access to your PBX.

You cannot manually manage IP Tables from a FreePBX Distro machine - the IP Tables installation is wiped out by FreePBX on purpose because of the number and types of special cases required to run the system. If you are setting things up in IP Tables, your installation is running without a firewall, because the first this the PBX does is wipe those out.

Having said that, my original advice still stands. You can argue with me some more if you want, but you aren’t going to change the facts:

  1. You are running without a firewall.
  2. You don’t have the integrated firewall set up, so your SIP ports (both 5060 and 5160) are vulnerable.
  3. You haven’t set up the Adaptive firewall (which requires the Integrated Firewall) which manages external SIP connections for you.

In addition to those facts, there are a couple of things that I’m assuming:

  1. Your server space vendor is lying to you - I believe there is (at least) a firewall and probably a NAT processor in front of your system.
  2. You haven’t actually set up the server in a configuration that allows for remote connections.

I’m done. Hope it all works out for you.

Wow thanks for all the information!
I hope that my poor english skills didn’t got me misunderstood, I didn’t try to say I blame something specific or that I have any clue what’s wrong, I was just asking for my own knowledge, I thought that both Chan_SIP and PJSIP requires UDP 10000-20000 and I set Chan_SIP on the A11 machine to 5060, like I set the PJSIP on the A13 machine. So I thought it may not be a port allowance issue.

About the Firewall, I agree with you that it’s risky to run without it, but for the specific issue I’m having, I didn’t understand how adding the firewall module can solve the issue (other than hardening my PBX box, which is of course crucial).

I don’t know if my hosting company is lying to me or not, but their customer service said they’re not using NAT and they don’t have any firewall between me and the public net, so that was the information I was counting on…

Thanks again for all your time and effort!