[Home]

Summary:ASTERISK-21117: Bad interpretation of the file chan_dahdi.conf when using open r2 parameters
Reporter:Rafael Angulo (rafuchoucv)Labels:
Date Opened:2013-02-15 14:30:14.000-0600Date Closed:2013-07-11 11:35:01
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:1.8.20.1 10.12.0 Frequency of
Occurrence
Related
Issues:
Environment:Last estable version of Asterisk 10 (compiled) over Centos 5.5Attachments:( 0) dahdi.conf
( 1) dahdi-channels.conf
( 2) mfcr2-config-fix-1.8.patch
( 3) system.conf
( 4) wanpipe1.conf
Description:I'm having a problem with the interpretation asterisk does of this file(chan_dahdi.conf), the file itself contains the definition of an E1 link (fractional 1-15 for incoming calls and 17-31 for outgoing calls) in Venezuela with the well know ISP CANTV(incoming r2, outgoing dtmf). The openr2 version is 1.3.1 ,asterisk 1.18.15, dahdi 2.6.1. the problem is also confirmed in Asterisk 10 with open r2 1.3.2 y dahdi 2.6.1. The configuration file is attached to this report. When I try to send outgoing calls through channels 17-21 they fail. When I type the command "mfcr2 show channels" it shows the 30 channels, as part of the info, the row named "Immediate Accept" show channels from 1 to 21 in "no", and channels from 22 to 31 in "yes". As long as I understand, this field is controlled by the parameter mfcr2_immediate_accept in the chan_dahdi.conf file, but the file (attached to this mail) indicates the first 15 channels(1-15) should be in mfcr2_immediate_accept=no and the next 15 (17-31) should be in mfcr2_immediate_accept=yes. As long as I have tested it, if the channel indicates Immediate Accept = no in the CLI, it receives calls but not send call, and if the channel indicates Immediate Accept = yes, it alow to send call but not receive. So what I basically have is channels from 17-21 unable to send calls. I have done hundred of tests, with many weird behaviors, invert the channels definition, split the channels definitions, etc.
In further tests I have these results:

If I set channels 1 to 10 with "mfcr2_immediate_accept=no" and 17 to 31 with "mfcr2_immediate_accept=yes" I can send the calls using channels 17 to 31.
If I set channels 1-14 with "mfcr2_immediate_accept=no" and 17 to 31 with "mfcr2_immediate_accept=yes" I can send calls using channels from 20 to 31.

If I invert the definitions in chan_dahdi.conf configuring outgoing channels first (17-31) and then incoming (1 - 15), they all appear as immediate = yes if I run the command mfcr2 show channels in asterisk CLI.

It seems like the definition of channels over the number 10 affects the channels 17 to 21 somehow.

chan_dahdi.conf:
{noformat}
[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
;group=1
callgroup=1
pickupgroup=1
immediate=no

group=1
context=from-trunk
signalling=mfcr2
mfcr2_variant=ve
mfcr2_get_ani_first=yes
mfcr2_max_ani=10
mfcr2_max_dnis=4
mfcr2_immediate_accept=no
mfcr2_category=national_subscriber
mfcr2_call_files=yes
mfcr2_logdir=cantv
mfcr2_logging=all
mfcr2_mfback_timeout=-1
;channel => 1-15,32-46
channel => 1-15

group=2
context=from-internal
signalling=mfcr2
mfcr2_variant=ve
mfcr2_get_ani_first=yes
mfcr2_immediate_accept=yes
mfcr2_dtmf_detection=1
mfcr2_dtmf_dialing=1
mfcr2_max_ani=10
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_logdir=cantv
mfcr2_logging=all
mfcr2_mfback_timeout=-1
channel => 17-31
{noformat}
Comments:By: Rusty Newton (rnewton) 2013-02-19 09:27:45.835-0600

Can you post your dahdi.conf as well? Please attach all files or debug output in a separate file using 'Attach Files'.


By: Rusty Newton (rnewton) 2013-02-19 14:34:07.174-0600

I'm not sure I could lab this up to completely reproduce it, but possibly I can try to reproduce as least the configuration parsing aspect of it.

In the meantime, I'm assigning this to Moises Silva, as he often looks into the MFC/R2 related issues.
By: Rafael Angulo (rafuchoucv) 2013-02-19 14:38:33.943-0600

/etc/modprobe.d/dahdi.conf
/etc/dahdi/system.conf
/etc/asterisk/dadhi-channels.conf
Wanpipe1.conf

By: Moises Silva (moy) 2013-02-20 10:18:56.328-0600

I'll have a look over the weekend
By: Rafael Angulo (rafuchoucv) 2013-04-02 13:51:06.929-0500

What is the real status of this bug? whose feedback is needed?

rafa
By: Moises Silva (moy) 2013-04-02 13:56:44.992-0500

This should still be assigned to me, if you can give me ssh to a machine where this happens and the source code is installed I should be able to fix it quickly, biggest issue for me here is find some time to install everything and try it
By: Mc GRATH Ricardo (ricardomcgrath) 2013-06-26 04:53:56.063-0500

Moises

Will these issue have a solution? or should have to provide on any installation an SSH for solving?

By: Moises Silva (moy) 2013-06-30 00:58:35.380-0500

I've found the problem in the config logic. Not sure how had not been caught before. Probably because most R2 links are fractional.

I'll make a patch tomorrow and ask you to try it.
By: Rafael Angulo (rafuchoucv) 2013-07-02 15:33:01.437-0500

Glad to hear you found the problem, let me know if there anything I can do to help, if you have the patch don't hesitate in sending it, I can try to set a test environment and try it.
By: Moises Silva (moy) 2013-07-02 23:25:34.275-0500

Can anyone try this patch (mfcr2-config-fix-1.8.patch)
By: Mc GRATH Ricardo (mcgrathr) 2013-07-04 07:37:59.185-0500

Hi Moises

I have tried and it seems channel alignment, and other parameters interpretation is working,  I couldn't make calling test, it need time according to parameters combination variants.