my Solution for All Circuits are busy

Discussion in 'General' started by Nakkoush, Feb 24, 2009.

  1. Nakkoush

    Joined:
    Feb 14, 2009
    Messages:
    73
    Likes Received:
    0
    Dear Expersts,
    I use OpenVox TDM400P card 4FXO.. I don't why it is happening now and then and specially when I add new SIP trunks or edit some of them, my ZAP trunks stop responding and if I try to dial out I always get the famous "All Circuits are Busy".. I tried several times to reboot my system, went to my ZAP channels trunks and clicked submit and then apply configuration (without doind any changes), I tried to redetect my cards and always the same..

    What I recently discovered, If I Call any of my (non working for outbound) ZAP trunks the call goes through, gets redirected accordingly and after picking up the call I am again able to make an outbound call using the same ZAP channel Trunk..
    My primitive workaround has to be done for all my ZAP Trunks which are not able to dial out in order to activate them..

    Is there anything I am doing wrong or how can I avoid my above primitive method each time I have the "All Circuits are busy" message when I try to use my ZAP Trunks?
     
  2. Nakkoush

    Joined:
    Feb 14, 2009
    Messages:
    73
    Likes Received:
    0
    I also noticed that each time I reboot my system all my ZAP trunks cannot dial out untill each channel receive a call!
    I have 8 ZAP trunks, it means each time I restart I need to make 8 calls from my mobile to activate my outbound ZAP routes (to get rid of "All Circuits are Busy Now)..

    I tried without and with following "Elastix without Tears" 14.1 to 14.5 (my cards are properly installed..) and always the same results.. I doubt that two of them can be faulty at the same time..(2 PCI cards TDM400P)

    Any help, hint or solution is highly appreciated.
     
  3. Nakkoush

    Joined:
    Feb 14, 2009
    Messages:
    73
    Likes Received:
    0
    Patrick, thanks again mate.
    I have to admin that I am a looser when it comes to search in this forum..

    Thanks DaveD! I did what you proposed and my problem is gone.
     
  4. vtofa

    Joined:
    Oct 21, 2008
    Messages:
    67
    Likes Received:
    0
    This solution has a major disconnect detection problem, at least with Sangoma cards (and very likely with other cards, too): When a call comes in and is answered by Elastix, but isn't hung up by the Elastix end (i.e. the remote caller hangs up), Elastix doesn't detect the disconnect and keeps the line open indefinately.

    An example: Call comes in, and is placed in park. Then the remote caller hangs up. The call stays in the parking lot as a zombie and takes up the ZAP trunk it came in on. Once your parking lot timeout happens, and someone picks up the call, they hear nothing. Once they hang up the call gets disconnected properly and the line is freed.

    This is merely annoying during the day, but becomes a big problem at nite if the system is used to forward calls to an answering service. The call comes in on one line, then gets forwarded to the answering service on another line. The call eventually gets hung up by the caller, but at least one of the lines stays in the zombie state, and eventually occupies all lines, at which point the system only gives a busy signal to all incoming callers, and "all lines are busy now" to outbound callers.

    Does anyone know how to fix that?
     
  5. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
  6. vtofa

    Joined:
    Oct 21, 2008
    Messages:
    67
    Likes Received:
    0
    Thanks Dicko. It works, but the hangup detection is rather slow. Took about 1 minute for the call to release the line.

    Kewlstart works extremely well for hangup detection - as soon as I hang up, it disconnects. No hokey busydetects or busycounts.

    Is there a real fix for this, or are we stuck with this?
     
  7. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Well in loopstart that's a function of when the telco starts sending you the "fast busy" and what the busycount is, the answer is to use kewlstart as you say you do and have the telco supply a real "caller disconnect" (either "battery rversal" or "battery interrupt", unfortunately the ZAP driver can only operate on the information sent on the line, in the absense of a "real" event, either it can only use silence longer than a certain amount or the detection of a discernible energy pattern on the rx circuit (fast-busy).

    I imagine the asterisk bug will be fixed eventually, and if we were not here in Newbie's corner I would suggest a recompile of Asterisk 1.4 from svn where the bug is apparently fixed.

    Edit:
    Gotta say I prefer Bob's solution! (more hair, less worries, thanks Bob)
     
  8. vtofa

    Joined:
    Oct 21, 2008
    Messages:
    67
    Likes Received:
    0
    OK. We will recompile from svn. I'll let you know what the results are.
     
  9. vtofa

    Joined:
    Oct 21, 2008
    Messages:
    67
    Likes Received:
    0
    OK. We will recompile from svn. I'll let you know what the results are.
    Do you mean Asterisk (Digium SVN) or some other SVN repository?
    Thanks
     
  10. Bob

    Bob

    Joined:
    Nov 4, 2007
    Messages:
    2,400
    Likes Received:
    1
    Sorry for the delay in joining this thread.....has been one hell of a couple of months (work wise). You can guess this by the fact that I am not even in the Top 10 posters for this month.

    The issue that you have was corrected by Tahir (I believe) in the Elastix distribution (and subsequently the main Asterisk distribution) and placed in the Beta. If 1.4 had been released it would have come out in this version.

    For those that want to take the safe route, then selecting loopstart instead of the default kewlstart (I think Dicko provided a link earlier in the thread).

    For those that are taking the riskier route of recompiling Asterisk, then you might be more suited to temporarily turning on your Beta repository and perform a

    yum update asterisk*


    and then turn your repository off again.

    BIG DISCLAIMER
    Like anything that is beta, it is untested. It may even bring a later version than what is needed and it might bring part of 1.5 which could break things entirely, I don't know.....I last performed this yum update when I was running 1.4 beta and originally found the issue, and it did indeed correct the problems (e.g. the bug was fixed), but I have not done a yum update since. My recommendation is that if someone has a system with the bug, and is prepared to put their system on the sword for the good of others with the issue, then report back and let others know that it worked or didn't work.

    Hope this helps.....

    Bob
     

Share This Page