Incoming call only works shortly when trunk is disabled


I am discovering the possibilities with Freepabx (13.0.106) and Asterisk (13.7.0) on a raspberry PI. I also use version 12 of Freepabx and there is everything working as it should be.

But in version 13 I have a strange problem with one of the trunks.

When my sip trunk is enabled there is no incoming call possible, outgoing is no problem. However when I disable the trunk, outgoing calls is no longer possible but incoming is now working for a short period of time.

I tried to find something in the logs, but I have no idea in which log file to look and for what kind of information is important.

Beside trunk number 1 I also use a sip voipbuster account and that one is working properly.

In my router ASUS RT-AC68U I disabled/enabled firewall, SIP Passthrough (on/off), incoming port UDP 5060, but no success.

Any suggestions?

Greeting Erik


All of this sounds like Firewall problems.

Note that in Asterisk 13, there is a new SIP connection driver (PJSIP) which uses port 5060 by default. The old Chan-SIP interface is still available on port 5061.

So, here are your possibilities:

  1. You are not allowing incoming traffic on the right port.
  2. You are only allowing incoming traffic while the outgoing traffic enables the incoming traffic (for example, you down the port and it sends a message to your ITSP which enables talk-back in from the ITSP for 30 seconds).

Either way, I’m certain your problem is in your firewall. Double-check your Asterisk configuration and make sure that you are using the right ports in your incoming and outgoing contexts, and that the firewall is operating appropriately.


Thanks for you reply!

I tried the following:

Forward in the ASUS UDP port 5060 and 5061 to IP-address Freepabx, but no positive result. I don’t exactly understand your comments at point 2. As for now I think you try to explain that when I call out after disconnection the call, the server opens the line for 30 seconds for incoming calls. Even after an outgoing call, incoming calls is not possible. And as far as I know I don’t have an option in the ASUS where this is possible to change.

I tried to enable and disable NAT sip pass-through but also no positive result. I also tried a DMZ to the IP-address off the free PABX server but also no positive result.

If I change in free PABX at SIP Setting/Chan SIP Setting the port number from 5060 to 5061 my sip client will no longer connect. But calling from cell phone result also in no connection to the free PABX server.

When I made an outgoing call from the SIP trunk the cell phone rings, but calling back is no option. After disabling the trunk outgoing is not working but incoming works indeed for ±30 seconds.

But how do you explain that Freepabx 12 works properly with same settings firewall. And separate clients on laptop or phone also have no problems connecting directly to the sip server from behind same firewall. And beside that the second sip trunk in Freepabx 13 works correctly.

I’ll start with the part I didn’t fully explain:

When you start a connection to an exterior network destination, your firewall opens a “return path” to the port that established the link. This is done through something called a “SYN” (or “START” depending on whether you are a real network guy or work for Microsoft) packet and, as long as traffic flows back and forth, your “incoming” connection paired with the “outgoing” SYN request is honored. In order to allow traffic to flow, the port stays open for (typically) about 30 seconds. If there’s no traffic, the firewall assumes you are finished processing your traffic and shuts down the opening in your firewall.

Your action of shutting down the interface will start a session with the remote end if no session currently exists. Since this connection terminates after about 30 seconds, it sounds like that action is the only one that is actually getting forwarded to the remote destination.

So, If that’s the case: if you can get traffic through the firewall for about 30 seconds, that means that you are sending a “SYN” packet out which opens the connection through the firewall.

With the advent of FreePBX 13, a new “local” firewall has been added. You need to either set it up so that it is configured correctly or disable it completely. Having it up partially will cause all kinds of problems like this. There is a Wiki page (IIRC) on setting up the new firewall. Note that some of the settings only make sense once you understand what the author means, so you can’t just throw it together slap-dash.

If the traffic is not getting to your machine (wireshark would be a good tool for troubleshooting this part), then the firewall is blocking it. If the machine is, in fact, getting the packets and ignoring them, the local firewall is probably to blame.

At this point, more details would help. Telling us your network architecture would be a big help.

Things we are pretty sure about:

  • Port 5060 is working for your local phones from the local network.

This could mean that your firewall is completely off or that your local network has been identified as “safe” and the local firewall is allowing that traffic to pass.

  • You have “port forwarded” TCP ports 5060, 5061, and UDP ports 10000-20000 from your firewall to the PBX.

You say your actually forwarded UDP ports 5060 and 5061, but that’s so wrong I assume you meant you did the right thing and just mistyped. There’s no way that you could really do this and expect it to work, so you get the benefit of the doubt.

  • You have an ITSP that you are using for your incoming phone number.

You asserted this, indirectly.

  • Enabling and disabling trunks is working as one would expect.

When you disable an outbound trunk and can’t place an outgoing call, that makes sense. That’s what disabling a trunk does.

As far as why 12 works and 13 doesn’t, I couldn’t tell you. The big difference between the two is the local firewall, so if the configuration of all of your firewall equipment is correct, the configuration should work The local firewall is more of an impediment than a help in a PBX that doesn’t connect directly to the Internet, especially if you have a good, working firewall in front of your PBX.