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 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_dahdi |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) 1.6.2.13_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[7309]: 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. Configuration: cidsignalling=dtmf dtmfcidlevel=1250 cidstart=dtmf answeronpolarityswitch=yes hanguponpolarityswitch=yes polarityonanswerdelay=2000 | ||
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: nationalprefix=0 internationalprefix=00 echocancel=yes usecallerid=yes callerid=asreceived hidecallerid=no echotraining=800 echocancelwhenbridged=no threewaycalling=yes transfer=yes relaxdtmf=no group=3 callgroup=3 pickupgroup=3 signalling=fxo_ks language=es accountcode=FAX context=fax channel=12 group=1 callgroup=1 pickupgroup=1 signalling=fxs_ks language=es cidsignalling=dtmf dtmfcidlevel=400 cidstart=dtmf accountcode=PSTN answeronpolarityswitch=yes hanguponpolarityswitch=yes polarityonanswerdelay=2000 busydetect=no context=incoming channel=1,2,3,4,5 group=2 callgroup=2 pickupgroup=2 signalling=fxs_ks language=es cidsignalling=dtmf dtmfcidlevel=1250 cidstart=dtmf accountcode=TELULARS answeronpolarityswitch=yes hanguponpolarityswitch=yes polarityonanswerdelay=2000 busydetect=no context=incoming channel=6,7,8,9,10 By: Sebastian Gutierrez (sum) 2011-02-09 07:46:59.000-0600 Uploaded a patch for branch 1.6.2 (specifically 1.6.2.13), 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 [^1.6.2.13 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. Thanks 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. |