All Circuits Are Busy

Discussion in 'General' started by hinzinho, Nov 18, 2009.

  1. hinzinho

    Joined:
    Sep 18, 2009
    Messages:
    461
    Likes Received:
    0
    I switched our old PBX system and T1 analog lines to Elastix 1.6-10 with Digium TE121 card and a PRI circuit last week. Everything was going great until this past Monday. For some reason, people were getting the "all circuits are busy" message whenever they dial out. Usually after a few tries, the call will go through. The problem started to disappear around noon time, with only 1 or 2 errors every other hours. As of today, all outgoing calls are working again except for two 800 numbers.

    From the log entries, I see two issues:
    -Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)
    -Channel 0/1, span 1 got hangup, cause 127


    What might have caused the issue(s)? Is the problem on the PBX side or telco? How can I fix this issue(s)?

    Thank you!


    I have replaced the real phone numbers with X's
    ----------------------------------------------------------
    Nov 16 08:38:33 VERBOSE [13266] logger.c:

    -- Executing [s@macro-dialout-trunk:19] Dial("SIP/5022-c825a820", "DAHDI/g0/1813XXXXXXX|300|") in new stack

    Nov 16 08:38:33 NOTICE [13266] app_dial.c:

    Hey! chan SIP/5022-c825a820's context='macro-dialout-trunk', and exten='s'

    Nov 16 08:38:33 WARNING [13266] app_dial.c:

    Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)

    Nov 16 08:38:33 VERBOSE [13266] logger.c:

    == Everyone is busy/congested at this time (1:0/1/0)
    --------------------------------------------------------

    Nov 17 17:25:48 VERBOSE [24283] logger.c:

    -- Executing [s@macro-dialout-trunk:19] Dial("SIP/5034-08c1f660", "DAHDI/g0/1800XXXXXXX|300|") in new stack

    Nov 17 17:25:48 NOTICE [24283] app_dial.c:

    Hey! chan SIP/5034-08c1f660's context='macro-dialout-trunk', and exten='s'

    Nov 17 17:25:48 VERBOSE [24283] logger.c:

    -- Requested transfer capability: 0x00 - SPEECH

    Nov 17 17:25:48 VERBOSE [24283] logger.c:

    -- Called g0/1800XXXXXXX

    Nov 17 17:25:48 VERBOSE [9677] logger.c:

    -- Channel 0/1, span 1 got hangup, cause 127

    Nov 17 17:25:48 DEBUG [24283] chan_dahdi.c:

    Set option AUDIO MODE, value: ON(1) on DAHDI/1-1

    Nov 17 17:25:48 DEBUG [24283] chan_dahdi.c:

    Already hungup... Calling hangup once, and clearing call

    Nov 17 17:25:48 DEBUG [24283] chan_dahdi.c:

    Set option AUDIO MODE, value: OFF(0) on DAHDI/1-1

    Nov 17 17:25:48 VERBOSE [24283] logger.c:

    -- Hungup 'DAHDI/1-1'

    Nov 17 17:25:48 VERBOSE [24283] logger.c:

    == Everyone is busy/congested at this time (1:0/0/1)
     
  2. blangys

    Joined:
    Sep 24, 2009
    Messages:
    94
    Likes Received:
    0
    I don't know enough on the Asterisk side to know, but my first call is to the carrier yelling at them. We get calls all of the time about phone systems down (with Avaya, Toshiba, Nortel, and Asterisk) and with a PRI, it has been 95% the carrier has an issue with the line. Good Luck!
     
  3. hinzinho

    Joined:
    Sep 18, 2009
    Messages:
    461
    Likes Received:
    0
    The "-Channel 0/1, span 1 got hangup, cause 127" issue is resolved. The problem was with our provider for the toll-Free numbers instead of the telco. They had to re-route their circuits and the way they handle the calls.

    As for "cause 34 - Circuit/channel congestion", my telco is still looking into the issue.

    Thanks blangys for the reply.
     
  4. VMdaS

    Joined:
    Oct 7, 2009
    Messages:
    14
    Likes Received:
    0
    I've been having problems with my circuits been busy too, and the thing is the signal that sends the supplier when you hang up a call is not being interpreted by the system. We tried to used inversed polarity. We haven't solved yet.
     
  5. hinzinho

    Joined:
    Sep 18, 2009
    Messages:
    461
    Likes Received:
    0
    Here we are again, every Monday we get this error "cause 34 - Circuit/channel congestion". One common factor I found is this:

    Code:
    Nov 30 01:45:20  	ERROR  	[29068] chan_dahdi.c:  	
    
    No more room in scheduler
    
    Nov 30 01:45:20 	ERROR 	[29068] chan_dahdi.c: 	
    
    Asked to delete sched id -1???
    
    Nov 30 01:45:20 	VERBOSE 	[29068] logger.c: 	
    
    == Primary D-Channel on span 1 down
    
    Nov 30 01:45:20 	WARNING 	[29068] chan_dahdi.c: 	
    
    No D-channels available!  Using Primary channel 24 as D-channel anyway!
    
    Nov 30 01:45:20 	ERROR 	[29068] chan_dahdi.c: 	!! Got S-frame while link down
    
    Nov 30 01:45:20 	ERROR 	[29068] chan_dahdi.c: 	No more room in scheduler
    
    Nov 30 01:45:20 	VERBOSE 	[29068] logger.c: 	== Primary D-Channel on span 1 up
    
    Nov 30 01:45:20 	ERROR 	[29068] chan_dahdi.c: 	!! Got a UA, but i'm in state 7
    
    I also see that at every hour, 1-23 B-Channels restart. However this morning, I only see 1,2, and 4 are restarting. The previous Mondays, the same issue (with different channels) until all the channels are restarted successfully before the error goes away. What is causing this? How can I fix it?
     
  6. ramoncio

    Joined:
    May 12, 2010
    Messages:
    1,663
    Likes Received:
    0
    Try adding resetinterval=never to your /etc/asterisk/chan_dahdi.conf
     
  7. brunosmith

    Joined:
    Oct 23, 2009
    Messages:
    28
    Likes Received:
    0
    I had that all circuit are bussy once. my problem was that the PBX had anonimous call disable.
     
  8. hinzinho

    Joined:
    Sep 18, 2009
    Messages:
    461
    Likes Received:
    0
    Since we ran the "dahdi restart" command, we have all our channels and the error disappeared. I would hate to run the "dahdi restart" command every week just to address this issue.

    ramoncio, can you explain why setting resetinterval to never is a good thing? The default is to restart every hour. I am just trying to understand the concept instead of just doing it.

    Thanks!
     
  9. ramoncio

    Joined:
    May 12, 2010
    Messages:
    1,663
    Likes Received:
    0
    Here in Spain, Telefónica is the main telco provider. They say that with power saving purposes, they shut down the ISDN BRI layer 2 when not in use. While helping Odicha with testing the first versions of the driver, I noticed sometimes I couldn't call out, getting the all-circuits-busy prompt. So he came up with that parameter that solved my problem. But I'm not sure why that solved it.
     
  10. hinzinho

    Joined:
    Sep 18, 2009
    Messages:
    461
    Likes Received:
    0
    Updated the libpri last week and that might have fixed my "cause 34" issue. We usually get that message every Monday morning and it hasn't happen yet *knocking on wood*.

    I see this message once a week, but I'm not sure if I should be concern or not:

    Dec 7 02:00:18 NOTICE [3351] chan_dahdi.c:
    PRI got event: HDLC Abort (6) on Primary D-channel of span 1
     
  11. Xexexe

    Joined:
    Mar 2, 2010
    Messages:
    12
    Likes Received:
    0

    Hi,
    Will try this hoping to resolve this dreaded error but i am abit puzzled.
    Does chan_dahdi affect ISDN cards too
    when mISDN is installed ?

    Thanks.
     

Share This Page