[Home]

Summary:ASTERISK-08271: On high call volume, Asterisk starts reporting: cause 34 - Circuit/channel congestion
Reporter:Alex Richardson (alexrch)Labels:
Date Opened:2006-12-04 07:59:05.000-0600Date Closed:2011-06-07 14:08:08
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) circuiterror.txt
( 1) zapata.conf
( 2) zaptel.conf
Description:When there is a high volume of outbound calls (let's say 10 outbound calls at the same time, every 4 seconds), Asterisk starts reporting the following error:

Dec  4 12:09:19 NOTICE[30005] app_dial.c: Unable to create channel of type 'ZAP' (cause 34 - Circuit/channel congestion)

This problem is not occuring always. However, entering 'zap show channels' in console shows only a few ZAP channels to be taken, most of the channels are free.

****** ADDITIONAL INFORMATION ******

I have attached zapata.conf, zaptel.conf. This is the extension thru which go the outbound calls:

exten => _1111XXXXX0.,1,Verbose(Calling Agent ${EXTEN:6:3} who is SIP enabled: ${EXTEN:9:1} at extension: ${EXTEN})
exten => _1111XXXXX0.,2,Random(50:13)
exten => _1111XXXXX0.,3,Dial(ZAP/g1/${EXTEN:10},8,tTj)
exten => _1111XXXXX0.,4,HangUp()
exten => _1111XXXXX0.,13,Dial(ZAP/G1/${EXTEN:10},8,tTj)
exten => _1111XXXXX0.,14,HangUp()
exten => _1111XXXXX0.,104,Busy()
exten => _1111XXXXX0.,114,Busy()
Comments:By: Joshua C. Colp (jcolp) 2006-12-04 13:52:25.000-0600

I am assigning this to mattf since I feel he is the individual who can best explain what might be happening.
By: acid (acid) 2006-12-05 14:58:02.000-0600

I can confirm this. I've very similar problem on my asterisk 1.2.3, zapatel 1.2.11, libpri 1.2.4. I've 30 SS7 CIC and 30 ISDN channels and on the bursty hours I'am getting very often this error. Does anyone know if downgrade to older version of asterisk could help ?
By: Donny Kavanagh (donnyk) 2006-12-07 17:08:51.000-0600

I can confirm this, i talked with matt about this before and he thought it might be a configuration issue.  Now i can see that it is not.

Here is a log i created when i was attempting to debug the issue.
By: Nico Giefing (nicox) 2006-12-12 11:25:11.000-0600

I have the same Problem with chan_ss7-0.9.0 and asterisk 1.2.13
After 2 to 3 days this error happened.
By: Serge Vecher (serge-v) 2006-12-12 11:48:33.000-0600

acid, nicox: chan_ss7 (Sifira one, I presume) is not officially supported by the Asterisk project. There is ss7 work being done in trunk, but not in 1.2, so I would not consider your problems related to alexrch's issue, unless you can show the same without the use of chan_ss7.
By: florian (florian) 2006-12-12 12:04:14.000-0600

serge-v: chan_ss7 runs on 1.2.13 as mentioned by nicox, please do not confuse this with lib_ss7. Chan_ss7 uses the zapata driver and libpri codebase, would look in that direction for this issue.
By: Serge Vecher (serge-v) 2006-12-12 12:12:45.000-0600

ok, what I said still holds true: it needs to be demonstrated, that chan_ss7, being an unsupported third-party software, is not a contributing factor.
By: Serge Vecher (serge-v) 2006-12-12 12:19:24.000-0600

this is probably related to 8069.
By: florian (florian) 2006-12-12 12:32:44.000-0600

Fair enough. What seems important is the cause code (34), which is identical in both chan_zap and chan_ss7. This seems to come from libpri, but I didn't have time to delve in this deeper. Perhaps Nicox and alexrch can comment on it.
By: florian (florian) 2006-12-12 12:36:08.000-0600

Hmm, not sure. 8069 does not mention the ISDN cause codes to which this seems to relate. Also not visible in the logfiles.
By: Donny Kavanagh (donnyk) 2006-12-12 12:54:34.000-0600

Matt is gone getting hitched but when he's back i'll definitely follow up with him on this one.
By: Alex Richardson (alexrch) 2006-12-13 12:32:19.000-0600

I don't know about the 8069 bug, but I'm pretty sure that at the time of congestions, I don't have any calls queued by Asterisk (at least not in var/spool/... folder if that's it?)
By: Donny Kavanagh (donnyk) 2006-12-13 12:34:32.000-0600

Unrelated for me, my box had one t1 crossed over to an emprix hammer and the other t1 connected to my provider.  Nothing else running on the box.  No agi, spooling, etc.
By: Alex Richardson (alexrch) 2006-12-13 14:33:56.000-0600

Well, I have one E1 connected to the legacy PBX, and another one to the telco. No spooling, just using AMI.
By: Serge Vecher (serge-v) 2006-12-13 15:31:57.000-0600

I'll be honest, the relationship to 8069 was a speculation on my part....
By: Donny Kavanagh (donnyk) 2006-12-28 21:05:03.000-0600

ping
By: Alex Richardson (alexrch) 2007-01-03 07:43:36.000-0600

pong :)

Is there anything new regarding this issue?
By: florian (florian) 2007-01-03 08:08:37.000-0600

I was kinda hoping for some response from mattf :) maybe he can shed some wise words to aid us in tracking down this issue properly.
By: Matthew Fredrickson (mattf) 2007-01-03 11:53:54.000-0600

I haven't seen anything conclusive on what might be causing this problem.  The chan_ss7 is an entirely separate issue that needs to be taken up with the maintainers of that channel driver.  As for the problem with it happening with chan_zap, if you can get it in that state, I'd need to login to find out more about what is wrong.  So if you can get it in that state, contact me either as Cresl1n on irc.freenode.net or MatthewFredricks on AIM.
By: Alex Richardson (alexrch) 2007-01-26 05:41:02.000-0600

It's impossible for me to set-up a login for you, cause it's behind client's VPN system and so on...

Would PRI debug be in any help to you?
By: acid (acid) 2007-01-26 11:17:38.000-0600

I can give you access to the system, where I'am facing this problem constanlty. Please contact my on my e-mail.
By: Alex Richardson (alexrch) 2007-01-29 08:57:20.000-0600

@matt: Am still waiting for the problem to repeat (sometimes it happens in a period of one week, sometimes in one month, sometimes - like lately - it is happenning almost every day). I will send you the PRI debug when it repeats. I hope this will help you at least a bit more.
By: Matthew Fredrickson (mattf) 2007-01-29 10:50:40.000-0600

If you post a PRI debug, make sure you don't post the full debug, post the relevant portion of it.  I don't know how much good it will do, but any little bit helps.
By: Alex Richardson (alexrch) 2007-01-29 11:05:46.000-0600

@matt: Hmm, I don't know if this is okay.....I don't get many PRI debuging info. Per every cca. 20 "cause 34 - Circuit/channel congestion" messages I get only this (do I have to turn on any other debuging, than just the "pri intense debug span XXX"?):

T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (68)

> [ 02 01 01 89 ]

> Supervisory frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 000        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 068 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 02 01 01 d9 ]

< Supervisory frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 108 P/F: 1
< 0 bytes of data
-- ACKing all packets from 107 to (but not including) 108
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (68)

> [ 02 01 01 89 ]

> Supervisory frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 000        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 068 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 02 01 01 d9 ]

< Supervisory frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 108 P/F: 1
< 0 bytes of data
-- ACKing all packets from 107 to (but not including) 108
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter
By: Steve Davies (one47) 2007-01-30 10:27:35.000-0600

Perhaps a datapoint for you guys, and perhaps not. I managed to cause this problem with an accidental misconfiguration, and even that was only a problem because I was using the bristuff patch.

Note, I am using chan_zap, q931 and a UK E1 circuit.

The circuit thought it was congested because the call-ref field was being set incorrectly in the response frame, so the SETUP was being cancelled.

To trace the problem I used:
 set verbose 1
 pri debug span 1
(I did not use intense debug)

and found that I had a SETUP with a call-ref of 140, but a PROCEEDING call-ref of 32780 was sent back. (These are actually equivalent, stripping the top-bit results in "12" both times)

Asterisk cannot handle this as it sees 2 different calls, but Asterisk always creates a call with the 2-byte call-ref to get round this. Perhaps something in chan_ss7 is causing the call-ref to go wrong in a similar manner?
By: Donny Kavanagh (donnyk) 2007-01-31 12:45:50.000-0600

This problem occurs for me without any patches, no bristuff, etc.  As well this bug is not related to chan_ss7.
By: Alex Richardson (alexrch) 2007-02-01 08:15:30.000-0600

@acid: did you and matt manage to find out anything about this?
By: Matthew Fredrickson (mattf) 2007-05-24 15:34:22

Does this problem still exist with the most recent versions of libpri and chan_zap?  I made a fix a while ago that possibly could have had an affect on this bug.
By: Matthew Fredrickson (mattf) 2007-06-06 17:24:29

No feedback