[asterisk-dev] chan_dahdi channels locking.

[Steve Davies]

On 11 January 2012 17:11, Richard Mudgett <rmudgett at digium.com> wrote:
>> Hi, All.
>> I discovered an issue with chan_dahdi.
>> I tryed to use patch from
>> http://lists.digium.com/pipermail/asterisk-commits/2011-January/047635.html
>> because i realy need this feature. But it seems that i missed
>> something
>> important.
>> It looks like all is OK, but in a moment some channels appeared to be
>> Loked like channel 13 (near)
>> Maybe anyone could point me to the Right solution? I just need to
>> save
>> Type Of Number that i was reseiving from channel.
>>
>> CentOs 6 2.6.35.6-45.fc14.i686
>>
>> asterisk  1.8.7.1
>
> I think using Asterisk v1.8.7.1 is really your problem.  Asterisk v1.8.7
> has a bad regression in the ./configure script that does not setup the
> use of libpri correctly.  It is fixed in v1.8.8.
>
> Richard

Coincidentally, I just encountered the same issue for the first time
in just one site of many using 1.6.2.22. The issue went away when the
periodic B-channel reset occurred. There are also similar sounding
issues going back a couple of years here and there on the 'net.

Of course as we are using 1.6, we do not have access to "pri show
channels" but there is definitely something odd with the data posted
by the OP:

PRI       B    Chan Call       PRI  Channel
Span Chan Chan Idle Level      Call Name
[snip]
 1   13 Yes  No   Idle       Yes

This is a channel that is in call level "idle" but at the same time is
non-idle and has a PRI call. Should that be possible?

We saw a similar issue about a year back where if you answered an ISDN
channel, and then sent a Busy, it would often 'leak a channel', and
prevent that channel being used again. On this more recent occasion,
the only significant event that I see leading up to a channel lock is
that the call is routed via a Local/ channel, and the target channel
fails and is hung-up.

I plan to set up a test environment to try and reproduce this. I'll
feedback if I discover anything more concrete.

Regards,
Steve