Unable to create DAHDI err 34

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>


[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux