Posts

Asterisk / FreePBX sip trunk registration problem, Serious Network Trouble

The asterisk log file (/var/log/asterisk/full) shows entries like this:

[Sep  3 04:02:08] ERROR[3984] chan_sip.c: Serious Network Trouble; __sip_xmit returns error for pkt data

Solution: The server had been moved from one public IP-address to another. In Asterisk PBX settings, the fields for both External IP and Bind Address (under Advanced) needed adjustment to the new IP-address. After server reload everything worked normally.

Asterisk no sound from client

I was running an Asterisk server behind NAT without any problems at one location. Due to reoargnization it was moved to a new location and placed behind a pfsense firewall. After a while users reported increasing problems with no sound from the clients.

It turned out running a SIP server behind a pfsense can be problematic. When moving to the SIP server to a white IP-adress (no NAT), protecting it using iptables firewall on the SIP-server, all problems disappeared.

It should be noted that the pfsense firewall was not running the latest version of pfsense so it could be caused by a problem solved in later versions of pfsense. However, for different reasons it was not possible to upgrade pfsense so the solution was to move the SIP-server from behind pfsense.

SIP-client behind NAT disconnects incoming external call after 8-10 seconds

Scenario: a SIP server running Elastix (Asterisk and FreePBX) with SIP-clients behind NAT. Outgoing calls from the clients (which where CounterPath Xten and Siemens Gigaset C530ip, i.e. completely different brands) works well, but incoming calls are disconnected after 8-10 seconds.

Googleing the problem suggests the problem is caused by a SIP REINVITE on the client side, which can’t happen because of NAT. During testing, I discovered that calls between SIP-phones connected to the same SIP PBX worked fine, even between different locations. Only calls that originated externally would be interrupted.

This made me focus on the trunks instead and I found out that the problem indeed was a REINVITE but it occured on the trunk side.

The solution was to add the following lines to the PEER DETAILS and USER DETAILS on the trunk configuration in the SIP server:

directmedia=no
canreinvite=no