Hi Hassan, simply spoken, the error output gives you ISDN reason 34 which indicates that there is no appropriate circuit/channel presently available to handle the call. First consideration: The available channels are exhausted by count (=your ingress channels exceed the possible egress channels) It would help to know what channel technology you use there, TDM/SS7 as well or other, and count setups in an SS7/SIP trace. I would try different hunting strategies here: first try from lowest to highest available so you should see free channels in the high range of your DAHDI spans. Second consideration: The available channels are not exhausted but they are not available fast enough after clearing the previous call. Changing the hunting order to least recently used, will give more time to clear the state of a channel in all memory registers and the problem will only hit you at full load. However, a switch should be non blocking and allow to use all channels concurrently at a certain guaranteed number of call setups per second. Maybe your customer end is doing something sneaky and tries to initiate a float of calls at the very same millisecond and giving Asterisk a hard time by that to process them concurrently. I have seen automated dialers blast even big iron switches because in real life even on great-many-multi-E1-trunkgroups, there is always a shift in channels setup when humans are sitting at the CPE side. You should consider that there is a processing lag introduced by the machine it runs on (specs too low). Third consideration: You line interface board may be broken or the driver not correctly initialized so the firmware may not communicate with the DADHI/libSS7 driver correctly. The reason 34 may just be the default ?catch all? exception that the driver API reports to Asterisk. I don?t know how to debug the DAHDI channel driver to a human readable log. Maybe some devs are currently not on holiday and can contribute to answer this or you call Digium support. Fourth consideration: Are you using SQL CDRs? I have seen a case at a customer site where the channels is not freed up until the CDR writing is complete. By bad design in Asterisk, a database lag can affect your system badly and various timers will timeout before it can proceed the call. In this case you must tune your database (refer to slow queries log if you use MySQL?) or turn off sql cdr and parse the csv-cdr to have an asynchronous process not affecting your PBX anymore. So long, Florian Von: asterisk-ss7-bounces at lists.digium.com [mailto:asterisk-ss7-bounces at lists.digium.com] Im Auftrag von Nyamul Hassan Gesendet: Freitag, 26. August 2011 08:51 An: Asterisk SS7 List Betreff: [asterisk-ss7] Unable to create DAHDI err 34 Hi, I just setup a new box last week, and for the past 2 - 3 days, it is giving the following problem: app_dial.c:2196 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion) I get hundreds of these lines on the console. It is not that calls are not connecting at all, but some of them are connecting, and some are not. I am not sure why this is happening. "core show calls uptime" shows some calls are connected, varies randomly. "dahdi show channels" show that all channels are "In Service" and no channels are showing blocked. In "core set verbose 3" mode, I also see the following right after the error line posted above: == Everyone is busy/congested at this time (1:0/1/0) "dahdi_maint -s 1" output shows some errors, but they are not changing at all. They're static: Span 1: >Framing Errors : 0: >CRC Errors : 0: >Code Violations : 96: >E-bit Count : 0: >General Errored Seconds : 85: Has anyone seen this before? Could someone please help? Regards HASSAN -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110826/cad594a8/attachment.htm>
|