vicidial.org

Hello,

We have being combing the board and trying diffrent solutions for this issue, going back and forth with carrier and still are getting random disconnects and CHANUNVAIL Msgs and so forth, Congestion issues.

Last upgrades are Asterisk 1.8.25 from 1.8.23 hoping this would fix the issue but no go, as soon as all agents start on inbound and outbound the issue continues.

any help is appreciated..

Our Vicidial versions

Version: 2.8b0.5
SVN Version: 2052
DB Schema Version:1362
DB Schema Update Date:2014-01-04 18:51:29

Please let me know if any more info is needed.
Well I havent been able to post sip.conf and other info cause it was too spammy....
what to do
Thanks..
greendialer

Hello and welcome to the forum!

I got a few questions for you:
Have you tried calling the phone numbers that gets disconnected? just to make sure its not the phone number that is the problem.
What does the carrier say?
Have you tried an other carrier? if not then I suggest you do
does it happen all the time or only under heavy load or some other thing like only a specific time of the day etc?

Enable sip debugging in asterisk and paste a failed call here

the "looks to spammy" will stop a few days after registration (I think), use pastbin.com if it happens on the next post

Thank you for the reply. It wont let me post the sip debug, not even with pastebin..Any help how to?..

How can i post the sip debug?


We called the numbers and they good. Basically every few min the carrier goes unreachable.. Then connects again.
It happens at any time..

Yes even with another carrier, same issue.

BTW. MAX Trunks 400 .. Max calls per second 20..

dial plan..

exten => _91.,1,Set(callerid(num)=+1XXXXXXXXXX)
exten => _91.,2,Set(callerid(ani)=Phone number)
exten => _91.,3,AGI(agi://127.0.0.1:4577/call_log)
exten => _91.,4,Dial(sip/${EXTEN:1}@xxxxxxx,55,To)
exten => _91,5,Hangup

This is usually a networking issue and this can ordinarily be proven by turning off qualify explicitly for the carrier.

qualify=yes or qualify=500 (or any other number) will cause asterisk to "disqualify" any sip connection that exceeds the specified time range (default is 1000, or one second, for "yes", or you can specify a number such as 500 which is a half second).

So the story goes like this: Every XX seconds, asterisk will send a sip packet to the other end of every sip connection which requires "qualifying". Your network (for whatever reason) does not manage to get the return back back from that connection in the required amount of time. At that moment, asterisk will flatly refuse to send any traffic to that sip connection (unreachable sip connection becomes "channel unavailable" without bothering to try).

So, fix your network problem ... and to prove this is true, you can modify qualify=no and it will continue to try even when the sip account is unreachable (as it will no longer be detecting "unreachable" for this connection, so it will not refuse to call ... it will just send the call blindly and hope for the best).

If this causes things to actually work, then it was merely that the time lag was too great, as opposed to the normal "packet never made the round trip". If this does not fix it (usually it does not, by the way), you'll just be dropping sip packets instead of channel unavailable.

Asterisk will "dial" .. and never receive a response. Then you can try to find out why the call never went through. Which inevitably turns out to be ... a network problem. LOL

Happy Hunting.

Hey @William,
Thank you for your views and replies..
fortunately,
it was a carrier issue.. when we switched to Ip auth and everything was setup on our side correctly, on their side issues were resolved and disconnects were over. whew!

We were in sip registration and then got switched to ip auth, at the same time one of their pbx servers would Disconnect us, thats were the problem was so now we are ip auth and have the other servers in our account entry for trunkinbound by ip addresses. Inbound/Outbound is working perfectly.
We have some other issue which I will open a new topic on.

Regards,
greendialer