|Summary:||ASTERISK-18334: chan_dahdi doesn't reset B-channels after calls.|
|Reporter:||max severin (severin)||Labels:|
|Date Opened:||2011-08-24 03:01:20||Date Closed:||2011-09-14 10:40:06|
|Environment:||2.6.18-194.26.1.el5 x86_64 x86_64 x86_64 GNU/Linux||Attachments:|
|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 184.108.40.206.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.
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.
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.