Re: [asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r// --- (Updated March 6, 2015, 1:52 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 432530 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 432422 /branches/11/channels/sig_analog.h 432422 /branches/11/channels/chan_dahdi.c 432422 /branches/11/UPGRADE.txt 432422 Diff: https://reviewboard.asterisk.org/r//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
Re: [asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r//#review14593 --- Ship it! Problems with CID detection resolved by swapping out hardware (other random Dahdi failures were being seen). Problem with distinctive ring detection on my TDM400P board is a limitation of either the hardware or the lower level Dahdi driver not being able to detect and/or signal for an OFF ring shorter period of 200ms. DR3 and DR6 work correctly as they have 400ms OFF periods. Effectively, the other DR patterns are signalled as one continuous ring due to use of only 200ms OFF. Since the distictive ring detection issues I'm encountering are not the fault of chan_dahdi, sig_analog, or these improvements, I'm good with this. - Scott Griepentrog On March 2, 2015, 3:18 p.m., rmudgett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r// --- (Updated March 2, 2015, 3:18 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 432422 /branches/11/channels/sig_analog.h 432422 /branches/11/channels/chan_dahdi.c 432422 /branches/11/UPGRADE.txt 432422 Diff: https://reviewboard.asterisk.org/r//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
Re: [asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r// --- (Updated March 2, 2015, 3:18 p.m.) Review request for Asterisk Developers. Changes --- Made not stop searching for CID even if the distinctive ring pattern gets filled. Some lengthy patterns fill the pattern and would abort detecting the caller id. 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 (updated) - /branches/11/channels/sig_analog.c 432422 /branches/11/channels/sig_analog.h 432422 /branches/11/channels/chan_dahdi.c 432422 /branches/11/UPGRADE.txt 432422 Diff: https://reviewboard.asterisk.org/r//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
Re: [asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
On Feb. 27, 2015, 9:39 a.m., Scott Griepentrog wrote: I updated the chan_dahdi [channels] configuration with cadences matching the Bellcore spec and retested for both CID detection and DR pattern recognition. Results are certain patterns (especially DR2, DR4, and DR5) exhibit failure rate on CID detection approaching 50%. As the DR1 pattern has a 0% failure rate, I'm confident that it's still a remaining DR problem. Additionally, the DR pattern numbers (#,#,#) are inconsistent for certain cadences. DR2 for example may be 359,297,259, sometimes 359,0,0, sometimes 297,0,0. The inconsistent DR patterns may or may not be related to the CID failure, although there appears to be a correlation. There may be leftover artifacts on CID detection between calls, as repeating a failed call tends to correlate to another failure. Scott Griepentrog wrote: I forgot to paste in my cadences: usedistinctiveringdetection=yes ;Bellcore-r1: ;60(2/4) cadence=2000,-4000 ;Bellcore-r2: ;60(.3/.2,1/.2,.3/4) cadence=300,200,1000,200,300,-4000 ;Bellcore-r3: ;60(.8/.4,.8/4) cadence=800,400,800,-4000 ;Bellcore-r4: ;60(.4/.2,.3/.2,.8/4) cadence=400,200,300,200,800,-4000 ;Bellcore-r5: ;60(.2/.2,.2/.2,.2/.2,1/4) cadence=200,200,200,200,200,200,1000,-4000 ;Bellcore-r6: ;60(.2/.4,.2/.4,.2/4) cadence=200,400,200,400,200,-4000 ;Bellcore-r7: ;60(.4/.2,.4/.2,.4/4) cadence=400,200,400,200,400,-4000 ;Bellcore-r8: ;60(0.25/9.75) cadence=250,-9750 I had an error in my cadence configuration. For the testing above I was actually running: cadence=125,125,2000,-4000 cadence=250,250,500,1000,250,250,500,-4000 cadence=125,125,125,125,125,-4000 cadence=1000,500,2500,-5000 cadence=1000,1000,1000,1000,-4000 cadence=500,500,1000,2000,2000,-4000 Once corrected to proper bellcore set below, I still encountered ~50% CID failure and 75% dring detection failure (i.e. all 3 numbers 0 on patterns dr1). cadence 'r1' added: 2000,-4000 cadence 'r2' added: 300,200,1000,200,300,-4000 cadence 'r3' added: 800,400,800,-4000 cadence 'r4' added: 400,200,300,200,800,-4000 cadence 'r5' added: 200,200,200,200,200,200,1000,-4000 cadence 'r6' added: 200,400,200,400,200,-4000 cadence 'r7' added: 400,200,400,200,400,-4000 cadence 'r8' added: 250,-9750 - Scott --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r//#review14562 --- 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// --- (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//diff/ Testing --- Tested the
Re: [asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r//#review14562 --- I updated the chan_dahdi [channels] configuration with cadences matching the Bellcore spec and retested for both CID detection and DR pattern recognition. Results are certain patterns (especially DR2, DR4, and DR5) exhibit failure rate on CID detection approaching 50%. As the DR1 pattern has a 0% failure rate, I'm confident that it's still a remaining DR problem. Additionally, the DR pattern numbers (#,#,#) are inconsistent for certain cadences. DR2 for example may be 359,297,259, sometimes 359,0,0, sometimes 297,0,0. The inconsistent DR patterns may or may not be related to the CID failure, although there appears to be a correlation. There may be leftover artifacts on CID detection between calls, as repeating a failed call tends to correlate to another failure. - 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// --- (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//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
Re: [asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
On Feb. 27, 2015, 9:39 a.m., Scott Griepentrog wrote: I updated the chan_dahdi [channels] configuration with cadences matching the Bellcore spec and retested for both CID detection and DR pattern recognition. Results are certain patterns (especially DR2, DR4, and DR5) exhibit failure rate on CID detection approaching 50%. As the DR1 pattern has a 0% failure rate, I'm confident that it's still a remaining DR problem. Additionally, the DR pattern numbers (#,#,#) are inconsistent for certain cadences. DR2 for example may be 359,297,259, sometimes 359,0,0, sometimes 297,0,0. The inconsistent DR patterns may or may not be related to the CID failure, although there appears to be a correlation. There may be leftover artifacts on CID detection between calls, as repeating a failed call tends to correlate to another failure. I forgot to paste in my cadences: usedistinctiveringdetection=yes ;Bellcore-r1: ;60(2/4) cadence=2000,-4000 ;Bellcore-r2: ;60(.3/.2,1/.2,.3/4) cadence=300,200,1000,200,300,-4000 ;Bellcore-r3: ;60(.8/.4,.8/4) cadence=800,400,800,-4000 ;Bellcore-r4: ;60(.4/.2,.3/.2,.8/4) cadence=400,200,300,200,800,-4000 ;Bellcore-r5: ;60(.2/.2,.2/.2,.2/.2,1/4) cadence=200,200,200,200,200,200,1000,-4000 ;Bellcore-r6: ;60(.2/.4,.2/.4,.2/4) cadence=200,400,200,400,200,-4000 ;Bellcore-r7: ;60(.4/.2,.4/.2,.4/4) cadence=400,200,400,200,400,-4000 ;Bellcore-r8: ;60(0.25/9.75) cadence=250,-9750 - Scott --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r//#review14562 --- 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// --- (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//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
Re: [asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r//#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// --- (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//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
Re: [asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
On Feb. 24, 2015, 5:35 p.m., Kevin Harwell wrote: /branches/11/channels/chan_dahdi.c, lines 1965-1967 https://reviewboard.asterisk.org/r//diff/2/?file=71580#file71580line1965 Since you rearranged the 'ring - range' check should it be '' instead of '='? Otherwise it is different than before. rmudgett wrote: It is not different than before. Before it was: if (x = ring + range x = ring - range) Now it is: if (ring - range = x x = ring + range) The code now better expreses that x is between two points on a number line. A = x = B ooops yeah I misread it. You are right! - Kevin --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r//#review14538 --- 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// --- (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//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
Re: [asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r// --- (Updated Feb. 23, 2015, 6:51 p.m.) Review request for Asterisk Developers. Changes --- Add UPGRADE.txt change notice. 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 (updated) - /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//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
[asterisk-dev] [Code Review] 4444: chan_dahdi/sig_analog: Fix distinctive ring detection to suck less.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r// --- 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 Diff: https://reviewboard.asterisk.org/r//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
