Summary:	ASTERISK-14937: v23 caller id detection (UK) less than 100%
Reporter:	trouble dog (troublebot)	Labels:
Date Opened:	2009-10-05 06:48:42	Date Closed:	2015-02-25 19:41:11.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_dahdi
Versions:		Frequency of Occurrence
Related Issues:	is related to ASTERISK-23488 Logic error in callerid checksum processing
Environment:		Attachments:	( 0) clid66.out
Description:	Around 1 in 100 will fail with callerid.c: No start bit found in fsk data After implementation of polarity detection in wcfxo.c I initially believed there was an issue with my implementation or the hardware (X100P SE). I setup enhanced logging and data capture and discovered that this was not the case. There is a certain amount of noise present most of which could be removed with a band pass filter, which I believe should help detection rates. I do not believe the noise is inherent in the line, most of the noise can be characterised as low frequency noise (mentioned in si3034 spec as dc offset) and 4khz squeal. I have the raw data captured directly from wcfxo if there is any interest in improving this. ****** ADDITIONAL INFORMATION ****** Steps to reproduce Repeatedly dialing my PSTN line via sip trunk e.g. RetryDial(|15|-1|...|15|d)
Comments:	By: trouble dog (troublebot) 2009-10-05 06:53:42 I have uploaded a capture of a failed detection clid66.out from asterisk log [Oct  4 18:27:08] ERROR[14809] callerid.c: No start bit found in fsk data. from sys log Oct  4 18:27:08 asterisk **TRIPPED POLARITY DETECTION! Oct  4 18:27:08 asterisk **SEND POLARITY EVENT Oct  4 18:27:08 asterisk %Callno=66, min=1228,max=1228,total=0,offset=1228,samples=5 Oct  4 18:27:08 asterisk %Callno=66, min=1228,max=1491,total=263,offset=1359,samples=15 Oct  4 18:27:08 asterisk %Callno=66, min=-32768,max=3443,total=36211,offset=-14663,samples=25 Oct  4 18:27:08 asterisk %Callno=66, min=-32768,max=3977,total=36745,offset=-14396,samples=35 Oct  4 18:27:08 asterisk %Callno=66, min=-32768,max=3977,total=36745,offset=-14396,samples=45 Oct  4 18:27:08 asterisk %Callno=66, min=-32768,max=3977,total=36745,offset=-14396,samples=50 Oct  4 18:27:09 asterisk %Callno=66, min=-32768,max=32767,total=65535,offset=-1,samples=550 Oct  4 18:27:09 asterisk %Callno=66, min=-32768,max=32767,total=65535,offset=-1,samples=1050 Oct  4 18:27:10 asterisk RING! Oct  4 18:27:26 asterisk **SQUELCHED! By: Leif Madsen (lmadsen) 2009-10-05 10:34:58 I have moved this to Channels/chan_dahdi as I believe that is where this would need to be resolved, but it is possible it could be as low as the hardware drivers? By: David Woolley (davidw) 2009-10-06 16:50:40 Although I'm not a DSP programmer, I think the basic problem is that algorithms are being used that are designed to handle relatively long telephony indication tones, but are being asked to handle tones that last for less than 1ms and consists of as little as 1.1 complete cycles. It is, in fact, fundamentally based on band pass filters, so ought to reject signals at the extreme ends of the spectrum.  What I think the algorithm is is to run IIR filters on the two nominal tone frequencies, and of length 7, then run another filter on the difference (of the squares), to try and average the result.  For tones that are not sub-multiples of 8kHz, this probably works well, if you can average over many cycles, but I don't see it working well for very short tones. Again, I'm not an expert on DSP, and particularly not on FSK modems, but I suspect, for this case, you have to take advantage of the continuous phase nature of the modulation, if one wants high quality decoding. Also, there doesn't seem to be any real advantage in using more than 1 signalling unit of data in the filters, so I think that FIR filters would be as good. I suspect it is the IIR filters that are having trouble with the start bit, as they will have seen a long run of data in one signalling state before the start bit. Note this means I think the problem is in main/fskcmodem_*.c. By: Leif Madsen (lmadsen) 2009-10-07 09:20:58 davidw: thanks for the feedback! By: David Woolley (davidw) 2009-10-08 17:50:04 This is too far from my company's area of interest for me to spend much time on, but if someone wants to experiment, the two possible strategies I would investigate, for the V.23 tones, are: Use length 7 FIR filters, with complex coefficients (a+b*z+c*z**2....+g*z**6).  I suspect the best values are exp(2*pi*f*t*i), for t from -3/8000 s to +3/8000 s.  I have a suspicion that there is no need to apply a windowing function here.  You may need to apply a frequency dependent overall correction. (z**n means the input delayed by n samples). Take the modulus of each result, and take the difference of these.  When it crosses a certain positive threshold in the positive direction, toggle the output one way, and do the opposite on crossing the corresponding negative threshold. As a rather different method, threshold the time between successive zero crossings against 1/3600th of a second. By: Russ Meyerriecks (rmeyerriecks) 2014-03-19 12:37:45.839-0500 This looks very similar to the callerid issue that I just closed: ASTERISK-23488 In my debugging I would also see the "No start bit found in fsk data" after the CID checksum was failed, the second ring was placed, and then the retry logic interrupted by the call pickup. By: Matt Jordan (mjordan) 2015-02-25 19:41:06.637-0600 Since there's a good chance that [~rmeyerriecks] solved this issue, I'm going to close this out as "most likely fixed" :-) Either way, it would be good for someone to reproduce this issue on a supported version of Asterisk that is past the versions fixed in ASTERISK-23488, namely 11.9.0 and any 13.x release. By: Matt Jordan (mjordan) 2015-02-25 19:41:34.382-0600 Note: if someone does reproduce this in a version of Asterisk containing Russ's fix, please comment here and I'll reopen the issue.