[asterisk-dev] chan_dahdi channels locking.

[Steve Davies]

On 16 January 2012 14:55, Steve Davies <davies147 at gmail.com> wrote:
> 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.
>

Hi,

Firstly, Richard - You were of course correct - insofar as 1.8 should
fix this issue, but a regression caused the fix to go missing.

Secondly, thanks to that pointer I was also able to establish the most
horrible sequence of events leading up to the leaking of a p->call
object, which is an issue which has cropped up in 1.2, 1.4 and 1.6.2
in our production environments, but which I never had a satisfactory
answer to :)

Now I just need a workaround for our 1.6.2 users!

For others encountering this problem in pre 1.8 Asterisk: Avoid
sending hangup cause codes of 1, 34, 44 or 82 - All 4 of these can
cause the call object to be leaked during PRI or BRI hangup, leaving
the channel unusable. It seems that the PRI B-channel reset clears
this issue after a while.

Thanks,
Steve