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-0600 | Date Closed: | 2013-07-11 11:35:01 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | 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.5 | Attachments: | ( 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. |