Thanks Florian, for the wonderfully detailed reply! I'll answer inline: On Fri, Aug 26, 2011 at 16:16, <florian at gruendler.net> wrote: > 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. > We are using LibSS7. No hunting order specified. The chan_dahdi.conf is in: http://pastebin.com/0pbrfScW > **** > > ** ** > > 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). > The server is a HP ML110 running Intel(R) Xeon(R) CPU X3450 @ 2.67GHz with 4GB RAM. Do you think this is too low for 4 x E1s? > 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. > I have got two other machines, same server / proc, each running 2 x 4E1 Digium cards, and none of them gives this error. So, I am confused why this is happenning. 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. > No SQL CDRs at all. Asterisk system is kept at bare minimum. CDRs are maintained from the Switch. > **** > > ** ** > > So long, **** > > ** ** > > Florian**** > > > Thanks again Florian! Regards HASSAN -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110827/46ce2423/attachment.htm>
|