|Summary:||ASTERISK-16468: [patch] DTMF CallerID failing wirh dtmfcidlevel with high value|
|Reporter:||Sebastian Gutierrez (sum)||Labels:|
|Date Opened:||2011-02-08 14:51:46.000-0600||Date Closed:||2016-10-27 09:58:13|
|Environment:||Attachments:||( 0) 184.108.40.206_DTMF_CallerID.patch|
( 1) 1.6.2-DTMF-per-channel.patch
|Description:||After some time working ok this message start to show up on the console:|
WARNING: chan_dahdi.c:9831 do_monitor: Read failed with -1: Unknown error 500
after this calls starts to hangup at the middle of a call.
|Comments:||By: Sebastian Gutierrez (sum) 2011-02-08 16:36:45.000-0600|
the problem seems to be that dtmfcidlevel is set globally and I have 2 different carriers that need diferent configuration, one of them uses telular bases with energy save this make the dtmfcidlevel to be a higher value to work properly, but the other lines need a lower value (values: 1250 and 400), I will make a patch that make dtmfcidlevel configured by channel as soon as possible and test it, if someone has any suggestion or think the problem is other, let me know.
By: Richard Mudgett (rmudgett) 2011-02-08 17:11:14.000-0600
I think dtmfcidlevel and mwilevel *should* be made per channel for the reason you state.
However, I don't think this is the reason for the calls dropping. It may have something to do with the mwimonitor_fsk and mwimonitoractive flags. Do you have mwimonitor set in your configuration?
By: Sebastian Gutierrez (sum) 2011-02-09 05:29:07.000-0600
this is my config file:
By: Sebastian Gutierrez (sum) 2011-02-09 07:46:59.000-0600
Uploaded a patch for branch 1.6.2 (specifically 220.127.116.11), is togheter with the previous patch of chan_dahdi for dtmf callerid, this is for starter I may need some help to do it in trunk because of the sig_analog file
By: Sebastian Gutierrez (sum) 2011-02-28 13:11:29.000-0600
I've added a new patch done from the last version of 1.6.2 branch right now, as I'm moving from svn to mercurial, this patch is generated from a clone repository of the svn 1.6.2 branch of asterisk, I'm not sure if this is usefull as it is for merge directly with the svn source (I think it should), this way is easier to have my patches that are not commited by the asterisk community along with the new upcoming changes.
By: Sebastian Gutierrez (sum) 2011-03-18 12:15:50
si there anything else I can do to move this issue forward? thanks
By: Sebastian Gutierrez (sum) 2011-05-15 22:36:54
as a response for rmudgett this patch solves the issue I had of calls that were hangup without a reason, the stability of the system is far better, due to diferent carriers needs diferent configs and depending on the dtmfcidlevel if is a wrong value you have false tries to detect dtmf cid (dtmf cid timeout) and the channel is busy in a prering state, this could be one after the other or every X seconds depending on the value this is when dtmfcidlevel is lower than the expected value, the other chance is a higher dtmfcidlevel make some calls no to be answered.
By: Sebastian Gutierrez (sum) 2012-05-18 15:35:16.688-0500
this was really necesary to make the configuration per channel basis, I could rework the patch to other version if needed to move this issue forward and close it, now that has been open for more than a year.
By: Sebastian Gutierrez (sum) 2012-07-11 19:45:16.365-0500
this issue has been on hold for a long time now, I´m on branch 10 right now, should I make a patch for it??? would it be considered??
By: Richard Mudgett (rmudgett) 2012-07-12 13:02:12.228-0500
The part of the first patch [^18.104.22.168 DTMF CallerID.patch] to add CID_START_DTMF_NOALERT is a new feature no matter how you consider it. That patch must be made for trunk.
The second patch [^1.6.2-DTMF-per-channel.patch] which just makes dtmfcidlevel per channel could be considered a bug fix or a new feature depending upon how you view it. I think it is more a new feature than a bug though since it changes the behavior of an existing option. It would also be best to make it for trunk.
By: Sebastian Gutierrez (sum) 2012-07-12 13:09:00.735-0500
The second patch is what Im talking about, I really think is a bug fix, I dont think would change the behavior on existing instalations if you have defined globally then will set them all with that value, if you have it per channel then will set different for different channels, is you do have configured different values now wont work so it wont break anything.
By: Sebastian Gutierrez (sum) 2016-10-27 09:58:14.054-0500
as it was not approved Im closing this.