----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4444/#review14537 -----------------------------------------------------------
Assuming Scott's testing goes well, I'll click the Ship It! button. /branches/11/channels/chan_dahdi.c <https://reviewboard.asterisk.org/r/4444/#comment25090> Nitpick: while you're cleaning this area up, spaces around '/' would be nice: if (analog_p->ringt < analog_p->ringt_base / 2) { } - Matt Jordan On Feb. 23, 2015, 6:51 p.m., rmudgett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4444/ > ----------------------------------------------------------- > > (Updated Feb. 23, 2015, 6:51 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24825 > https://issues.asterisk.org/jira/browse/ASTERISK-24825 > > > Repository: Asterisk > > > Description > ------- > > The distinctive ring feature interferes with detecting Caller ID and > appears to have been broken for years. What happens is if you have a > ring-ring cadence as used in the UK you get too many DAHDI events for the > distinctive ring pattern array and Caller ID detection is aborted. I > think when Zapata/DAHDI added the ring begin event it broke distinctive > ring. More events happen than before and the code does no filtering of > which event times are recorded in the pattern array. > > * Made distinctive ring only record the ringt count when the ring ends > instead of on just any DAHDI event. Distinctive ring can be ring, > ring-ring, ring-ring-ring, or different ring durations for the up to three > rings. > > * Fixed the distinctive ring detection enable (chan_dahdi.conf option > usedistinctiveringdetection) to be per port instead of somewhat per port > and somewhat global. This has been broken since v1.8. > > * Fixed using the default distinctive ring context when the detected > pattern does not match any configured dringX patterns. The default > context did not get set when the previous call was a matched distinctive > ring pattern and the current call is not matched. This has been broken > since v1.8. > > * Made distinctive ring have no effect on Caller ID detection when it is > disabled. Caller ID detection just monitors for 10 seconds before giving > up. > > * Fixed leak of struct callerid_state memory when a polarity reversal > during Caller ID detection causes the incoming call to be aborted. > > > Diffs > ----- > > /branches/11/channels/sig_analog.c 432173 > /branches/11/channels/sig_analog.h 432173 > /branches/11/channels/chan_dahdi.c 432173 > /branches/11/UPGRADE.txt 432173 > > Diff: https://reviewboard.asterisk.org/r/4444/diff/ > > > Testing > ------- > > Tested the following scenarios for US (ring) and UK (ring-ring) ring cadences: > 1) usedistinctiveringdetection=no > 2) usedistinctiveringdetection=yes with distinctiveringaftercid=no > 3) usedistinctiveringdetection=yes with distinctiveringaftercid=yes > > * Caller-ID was detected for each call > * The configured distinctive ring dringX pattern was detected and the > specified context set. > > > Thanks, > > rmudgett > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
