[Home]

Summary:ASTERISK-18334: chan_dahdi doesn't reset B-channels after calls.
Reporter:max severin (severin)Labels:
Date Opened:2011-08-24 03:01:20Date Closed:2011-09-14 10:40:06
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:1.6.2.20 Frequency of
Occurrence		Constant
Related
Issues:
Environment: 2.6.18-194.26.1.el5 x86_64 x86_64 x86_64 GNU/LinuxAttachments:
Description:chan_dahdi doesn't reset B-channels after calls. After the call was ended, B-channel in EDSS1 PRI don't come back to the free state, and the calls from another end of pri is failing with  "cause: Requested channel not available"(this is copied string from E1 switch logs).
without any changes in configs, version 1.6.2.17.2 is working without this problem.
Comments:By: Richard Mudgett (rmudgett) 2011-08-24 11:29:54.304-0500

You can get that cause if there is a call collision where an incoming and outgoing call pick the same B channel.  This is known as glare.  Glare can be minimized if the channel allocation strategy for each end are unlikely to pick the same channel.  The network side can pick from the lowest available channel and the CPE side can pick from the highest available channel.  Dialing DAHDI/G1/5551212 will pick from the highest available channel.  Dialing DAHDI/g1/5551212 will pick from the lowest available channel.

{noformat}
Dial(DAHDI/(g|G|r|R)<group#(0-63)>[c|r<cadance#>|d][/extension])

g - channel group allocation search forward
G - channel group allocation search backward
r - channel group allocation round robin search forward
R - channel group allocation round robin search backward

c - Wait for DTMF digit to confirm answer
r<cadance#> - Set distintive ring cadance number
d - Force bearer capability for ISDN/SS7 call to digital.
{noformat}

If this is not the case then more information is needed to determine the problem.  What steps are needed to reproduce the problem?

Also be aware that the v1.6.x series is no longer receiving regular maintenance.