> 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/4444/#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/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
