[asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.

[Scott Griepentrog]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4444/#review14533
-----------------------------------------------------------


Tested with a looped tdm board generating various DR patterns and confirmed to resolve CID detection problem.  Ran out of time to validate DR detection, will attempt later.

- Scott Griepentrog


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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150224/a786a907/attachment-0001.html>