Thanks Florian, for the wonderfully detailed reply! I'll answer inline:<br><br><div class="gmail_quote">On Fri, Aug 26, 2011 at 16:16, <span dir="ltr"><<a href="mailto:florian@gruendler.net">florian@gruendler.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="DE-CH" link="blue" vlink="purple"><div><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Hi Hassan,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">simply spoken, the error output gives you ISDN reason 34 which </span><span lang="EN-US" style="font-size:11.0pt">indicates that there is no appropriate circuit/channel presently available to handle the call</span><span lang="EN-US" style="font-size:11.0pt">. <u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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.</span></p>
</div></div></blockquote><div><br></div><div>We are using LibSS7. No hunting order specified. The chan_dahdi.conf is in:</div><div><a href="http://pastebin.com/0pbrfScW">http://pastebin.com/0pbrfScW</a></div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="DE-CH" link="blue" vlink="purple"><div><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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).</span></p>
</div></div></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="DE-CH" link="blue" vlink="purple"><div><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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.</span></p>
</div></div></blockquote><div><br></div><div>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.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="DE-CH" link="blue" vlink="purple"><div><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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.</span></p>
</div></div></blockquote><div><br></div><div>No SQL CDRs at all. Asterisk system is kept at bare minimum. CDRs are maintained from the Switch.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="DE-CH" link="blue" vlink="purple"><div><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">So long, <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Florian<u></u><u></u></span></p>
<p class="MsoNormal"><span class="Apple-style-span" style="font-size: 15px;"><br></span></p></div></div></blockquote><div><br></div><div>Thanks again Florian!</div><div><br></div><div>Regards</div><div>HASSAN </div></div>