[Home]

Summary:ASTERISK-11151: REGRESSION: broken callerid
Reporter:meneault (meneault)Labels:
Date Opened:2008-01-04 12:09:57.000-0600Date Closed:2008-07-21 15:51:12
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 78227-revert-for-91983
( 1) id_rx
( 2) idna_rx
Description:I recently switched from a trunk 49XXX revision to a 80XXX and then to 91983 and callerid seems to be broken at least since revision 80XXX.

Callerid detection fails randomly (usually 1/4 calls) with:
in callerid_feed: Caller*ID failed checksum

****** ADDITIONAL INFORMATION ******

The issue is apparently due to commit 78227 to fskmodem.c:
"Change the fsk filter used in CID and TDD decode to an integer based implementation" by dbailey

I reverted the changes done by 78227 for the revision 91983 and everything runs fine.


Comments:By: meneault (meneault) 2008-01-04 12:19:46.000-0600

For information:
- this is not due to machine load because the CPU is 99% idle with more than 250MB of free memory.
- the issue happens randomly even with the same calling party on the same channel.

Fix:
As I said the fix is only to revert the changes of revision 78227.
See attached an example I made for revision 91983 (78227-revert-for-91983).

Note:
I guess dbailey made this change so as to compile on embedded systems where floating point is not available but I think that the integer filters have not the same frequency response than the older floating-point ones.
By: Kevin P. Fleming (kpfleming) 2008-01-11 17:43:48.000-0600

That is correct, they are not as sensitive in some ways.

Can you provide a ztmonitor capture of the incoming CLID audio from one of your failing channels? (in split tx/rx mode please). With that we can recreate the situation on our own systems and attempt to resolve it. Thanks.
By: meneault (meneault) 2008-01-13 12:25:46.000-0600

Here you have:
idna_rx : asterisk not running (only zaptel), CLID start at time 4,95s approx.
Content: short-ring/CLID/ring

id_rx : asterisk running, CLID start at time 2,64s approx.
Content: short-ring/CLID/answer

I forgot to mention but here we use V23 modulation CLID start after first short ring.

To recreate the situation use id_rx's CLID.
Try it various times, maybe starting decoding from different offsets as would chan_zap do. Because it may work once, twice but maybe not the third time.
By: jmls (jmls) 2008-05-03 14:16:24

ping. housekeeping
By: meneault (meneault) 2008-05-07 14:03:44

I didn't receive any feedbacks on the traces I sent.
I didn't test any further... Apparently the "problematic" commit has not been released on other branches than trunk so a few people may be concerned.

For me the solution is straight forward, keep old filters and new filters together  and let the choice be compile time with a simple define.
By: Digium Subversion (svnbot) 2008-07-21 15:51:03

Repository: asterisk
Revision: 132510

U   trunk/build_tools/cflags.xml
D   trunk/include/asterisk/fskmodem.h
A   trunk/include/asterisk/fskmodem_float.h
A   trunk/include/asterisk/fskmodem_int.h
U   trunk/main/callerid.c
D   trunk/main/fskmodem.c
A   trunk/main/fskmodem_float.c
A   trunk/main/fskmodem_int.c
U   trunk/main/tdd.c

------------------------------------------------------------------------
r132510 | tilghman | 2008-07-21 15:51:01 -0500 (Mon, 21 Jul 2008) | 5 lines

Optionally build integer-based routines for FSK tone decoding (but default
to the more accurate float-based routines).
(Closes issue ASTERISK-11151)
(Step 1 of 2)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=132510