[Home]

Summary:ASTERISK-17107: [patch] "Caller*ID failed checksum" on Wildcard TDM2400P and TDM410
Reporter:Kevin Scott Adams (nivek)Labels:
Date Opened:2010-12-14 16:12:50.000-0600Date Closed:2011-03-14 11:55:31
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) callerid.c.1.patch
( 1) callerid.c.2.patch
Description:Receiving message "Caller*ID failed checksum" on every call.  Changing "cidrw_gain" did nothing.  Other cid-based parameters did nothing.
Tested line using a analog phone with the Caller ID feature and received caller id.


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

Digging deeper into Asterisk found that the error exists in main/callerid.c.
Commented out the failure logic of cid->sawflag=5 in the switch statement and behold...Caller ID works.
Few debug statements showed me that the logic was working up to that point and then noticed the statement
if (b > 0xff)
  continue;
Well my 'b' was always '> 0xff' for the checksum via my debug statement.

Uploading 2 patches that worked but don't know which is the correct way of doing it.

Comments:By: Kevin Scott Adams (nivek) 2010-12-14 16:16:14.000-0600

I am running x86_64 CentOS 5.5, if that makes a difference.

Was able to reproduce and patch on 1.6.2.

By: Kevin Scott Adams (nivek) 2010-12-14 16:21:25.000-0600

Patch 1 makes sure the current cid->sawflag is 5 before striping off the higher bits of the variable 'b'.
Patch 2 just does it for every 'b' it sees that is > 0xff.

By: Richard Mudgett (rmudgett) 2011-03-02 13:44:04.000-0600

Bit 8 of 'b' is set when parity error.
Bit 9 of 'b' is set when framing error.

I think that your 'b' value looked like 0x02xx where bit 9 was set.
Am I correct in what your 'b' value looked like?

If only bits 8 or 9 are set then your first patch is better because the checksum is the last character in the message and we can tolerate a framing/parity error there.  The checksum character validates the message.

A framing error in the checksum could be because:
1) The sender did not send a full stop bit.
2) The sender cut off the FSK carrier too soon.
3) The sender opted to send zero of the specified zero to 10 trailing mark bits and round-off errors in the code resulted in the code not being where it thought it was in the demodulated bit stream.

By: Digium Subversion (svnbot) 2011-03-14 11:38:26

Repository: asterisk
Revision: 310633

U   branches/1.4/main/callerid.c

------------------------------------------------------------------------
r310633 | rmudgett | 2011-03-14 11:38:25 -0500 (Mon, 14 Mar 2011) | 25 lines

"Caller*ID failed checksum" on Wildcard TDM2400P and TDM410

The last character in the caller id message is getting a framing error.

The checksum is the last character in the message.  A framing error in the
checksum could be because:
1) The sender did not send a full stop bit.
2) The sender cut off the FSK carrier too soon.
3) The sender opted to send zero of the specified zero to 10 trailing mark
bits and round-off errors in the code resulted in the code not being where
it thought it was in the demodulated bit stream.

Bit 8 of 'b' is set when parity error.
Bit 9 of 'b' is set when framing error.

Made ignore the framing and parity error bits if the errored character is
the checksum.  We can tolerate a framing/parity error there.  The checksum
character validates the message.

(closes issue ASTERISK-17107)
Reported by: nivek
Patches:
     callerid.c.1.patch uploaded by nivek (license 636) (with modifications)
Tested by: nivek

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

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

By: Digium Subversion (svnbot) 2011-03-14 11:47:55

Repository: asterisk
Revision: 310635

_U  branches/1.6.2/
U   branches/1.6.2/main/callerid.c

------------------------------------------------------------------------
r310635 | rmudgett | 2011-03-14 11:47:55 -0500 (Mon, 14 Mar 2011) | 32 lines

Merged revisions 310633 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r310633 | rmudgett | 2011-03-14 11:38:24 -0500 (Mon, 14 Mar 2011) | 25 lines
 
 "Caller*ID failed checksum" on Wildcard TDM2400P and TDM410
 
 The last character in the caller id message is getting a framing error.
 
 The checksum is the last character in the message.  A framing error in the
 checksum could be because:
 1) The sender did not send a full stop bit.
 2) The sender cut off the FSK carrier too soon.
 3) The sender opted to send zero of the specified zero to 10 trailing mark
 bits and round-off errors in the code resulted in the code not being where
 it thought it was in the demodulated bit stream.
 
 Bit 8 of 'b' is set when parity error.
 Bit 9 of 'b' is set when framing error.
 
 Made ignore the framing and parity error bits if the errored character is
 the checksum.  We can tolerate a framing/parity error there.  The checksum
 character validates the message.
 
 (closes issue ASTERISK-17107)
 Reported by: nivek
 Patches:
       callerid.c.1.patch uploaded by nivek (license 636) (with modifications)
 Tested by: nivek
........

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

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

By: Digium Subversion (svnbot) 2011-03-14 11:51:00

Repository: asterisk
Revision: 310636

_U  branches/1.8/
U   branches/1.8/main/callerid.c

------------------------------------------------------------------------
r310636 | rmudgett | 2011-03-14 11:50:59 -0500 (Mon, 14 Mar 2011) | 39 lines

Merged revisions 310635 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r310635 | rmudgett | 2011-03-14 11:47:54 -0500 (Mon, 14 Mar 2011) | 32 lines
 
 Merged revisions 310633 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r310633 | rmudgett | 2011-03-14 11:38:24 -0500 (Mon, 14 Mar 2011) | 25 lines
   
   "Caller*ID failed checksum" on Wildcard TDM2400P and TDM410
   
   The last character in the caller id message is getting a framing error.
   
   The checksum is the last character in the message.  A framing error in the
   checksum could be because:
   1) The sender did not send a full stop bit.
   2) The sender cut off the FSK carrier too soon.
   3) The sender opted to send zero of the specified zero to 10 trailing mark
   bits and round-off errors in the code resulted in the code not being where
   it thought it was in the demodulated bit stream.
   
   Bit 8 of 'b' is set when parity error.
   Bit 9 of 'b' is set when framing error.
   
   Made ignore the framing and parity error bits if the errored character is
   the checksum.  We can tolerate a framing/parity error there.  The checksum
   character validates the message.
   
   (closes issue ASTERISK-17107)
   Reported by: nivek
   Patches:
         callerid.c.1.patch uploaded by nivek (license 636) (with modifications)
   Tested by: nivek
 ........
................

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

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

By: Digium Subversion (svnbot) 2011-03-14 11:55:31

Repository: asterisk
Revision: 310637

_U  trunk/
U   trunk/main/callerid.c

------------------------------------------------------------------------
r310637 | rmudgett | 2011-03-14 11:55:30 -0500 (Mon, 14 Mar 2011) | 46 lines

Merged revisions 310636 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r310636 | rmudgett | 2011-03-14 11:50:59 -0500 (Mon, 14 Mar 2011) | 39 lines
 
 Merged revisions 310635 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r310635 | rmudgett | 2011-03-14 11:47:54 -0500 (Mon, 14 Mar 2011) | 32 lines
   
   Merged revisions 310633 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r310633 | rmudgett | 2011-03-14 11:38:24 -0500 (Mon, 14 Mar 2011) | 25 lines
     
     "Caller*ID failed checksum" on Wildcard TDM2400P and TDM410
     
     The last character in the caller id message is getting a framing error.
     
     The checksum is the last character in the message.  A framing error in the
     checksum could be because:
     1) The sender did not send a full stop bit.
     2) The sender cut off the FSK carrier too soon.
     3) The sender opted to send zero of the specified zero to 10 trailing mark
     bits and round-off errors in the code resulted in the code not being where
     it thought it was in the demodulated bit stream.
     
     Bit 8 of 'b' is set when parity error.
     Bit 9 of 'b' is set when framing error.
     
     Made ignore the framing and parity error bits if the errored character is
     the checksum.  We can tolerate a framing/parity error there.  The checksum
     character validates the message.
     
     (closes issue ASTERISK-17107)
     Reported by: nivek
     Patches:
           callerid.c.1.patch uploaded by nivek (license 636) (with modifications)
     Tested by: nivek
   ........
 ................
................

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

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