i made sip trunk between 2 asterisk (asterisk A as load ballancer, and asterisk 1). when there is no call on server1 sip trunk status on load ballancer is ok without any problem, but when i send calls to this server from sip trunk (from load ballancer), trunk status still is ok for about 70 concurrent calls, but when numbers of concurrent calls increase about 100 concurrent calls and more, sip trunk will be unreachable. when trunk status is unreachable all call to this trunk will become busy with error :
unable to create channell of type sip, subscriber absent.
after 1 or 2 minute trunk status will be ok and again unreachable, so concurrent call wont go over 100 concurrent calls.
but from other side i have another server (asterisk 2) that its sip trunk on load ballancer allways is ok with 450 concurrent calls. their configs (asterisk 1 and 2) are the same, but i don’t know why sip trunk on asterisk 1 will be unreachable after high load of calls.
my resource is :
CentOS 7
Asterisk 13.18
Host : virtual (ESXI)
Thanks for your reply, I told the problem to our network department but they said :both servers are on same LAN and same network range, there is no firewall between them I change trunk to IAX , now error is chan_iax2.c: Auto-congesting call due to slow response i search for above error , and it’s for qualify option in iax trunk.
according to my searches, It may just be temporary network hiccups, or one box may be very slow to respond due to high traffic. and they suggest : You can try increasing the qualify value like:
qualify=1000.
how can i prove that problem is about network to my network department?
is there any tools or some way to prove it
Is this server 1, server 2, the load balance server? What is the RAM/CPU on those servers?
When the load balance system is getting the errors, does the destination server show the peer/endpoint down to the load balance system? Can the destination PBX send any calls to the load balance server when this is happening?
Virtual machines can also suffer from being allocated insufficient of the host’s resources or unsuitable scheduling policies. It may be difficult to tell that apart from network problems.
A common network design problem is buffer bloat. That means the network has enough capacity, but round trip times are excessive, because too many packets are suck in router buffers.
You can use tools like wireshark to see the actual packet round trip delays and jitter.
Increasing the qualify time may avoid the dropouts, but, if the problem is affecting media as well as signalling, it will not disguise the poor audio quality.
On a heavily loaded corporate network, the network manager should have enabled Differentiated Services, and you should then configure Asterisk to take advantage of them. These can prioritize VoIP traffic, assuming that it only represents a small part of the total traffic.