[asterisk-ss7] Unable to create DAHDI err 34
Nyamul Hassan
nyamul at gmail.com
Fri Aug 26 13:44:43 CDT 2011
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>
More information about the asterisk-ss7
mailing list