PEER SIP Trunk Failing

Asterisk: 13.7.2

I have my FreePBX appliance connected to my Avaya Session manager via SIP as a trunk for outgoing call processing. It works great, except I have had two incidents over ~8 days (thousands of calls in between) where the connection shows as “OK” on the Asterisk side, but not connected on the Avaya Session Manager side. Almost like my 5060 port is closing and I need to reboot FreePBX to resolve the issue (losing pending and active calls).

In my forum crawling, I noticed people indicating that the issue could be an issue with qualify and the default of 60 seconds being too long. Below is a copy of my trunk outgoing SIP settings:

It’s pretty basic. Does this look correct? Is anything missing?

The last question I had was if there was a way to have the asterisk trunk status have a more accurate reflection of what is going on (versus just showing as “OK”)?

Thanks for your time and any guidance you can provide.

I also have a webpage displaying the following commands. They are used by 3-4 people simultaneously to keep an eye on things without having to be logged into the terminal. When they are on the page, it refreshes every 30 seconds.

$(ps axo pid,lstart,etime,cmd|grep -v queue|egrep ‘callbac[k]|PI[D]’)

$(( $(ps axo pid,etime,cmd|grep -v queue|egrep ‘callbac[k]|PI[D]’|wc -l) - 1 ))

$(asterisk -rx “sip show peer AVAYA-1” | grep Status)

$(free | awk ‘/Mem/{printf(“used: %.2f%”), $3/$2*100} /buffers/cache/{printf(", buffers: %.2f%"), $4/($3+$4)100} /Swap/{printf(", swap: %.2f%"), $3/$2100}’)

$(uptime | awk -F’[a-z]:’ ‘{ print $2}’)

$(df -h)


It happened again and I am seeing exceptionally long voice call errors in the SIP log right as the SIP connection between Avaya Session Manager and Asterisk is lost. Trunk status remains “OK” even though no calls can process.

The problem is that it could be the Avaya, your network, or your server hardware.

We have no way of knowing what to tell you to look for without narrowing the scope down, and even then if the problem turns out to be something in the Avaya, we’re going to be up a creek.

Turned out to be a DB Max connections problem.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.