| Summary: | ASTERISK-20218: Alarmreceiver DTMF strings not recieved correctly from alarm-panel->SPA-PAP2->asterisk | ||||||||
| Reporter: | john (hossiken) | Labels: | |||||||
| Date Opened: | 2012-08-12 17:04:03 | Date Closed: | 2012-08-14 17:03:33 | ||||||
| Priority: | Major | Regression? | |||||||
| Status: | Closed/Complete | Components: | Core/Channels | ||||||
| Versions: | 1.8.13.1 | Frequency of Occurrence | Constant | ||||||
| Related Issues: |
| ||||||||
| Environment: | Gentoo - Kernel: 2.6.35-gentoo-r12 #3 SMP Tue Nov 30 04:20:56 PST 2010 i686 Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel | Attachments: | ( 0) PA2P.rtf | ||||||
| Description: | Updated asterisk (gentoo package) 1.8.3-rcX to (gentoo package) 1.8.13.1 and alarmreceiver broke: (NonZero CheckSum & Incomplete string errors). Setup: alarm-panel(ADT home system)->SPA-PAP2->asterisk Tried: 1)Simplified configs (removed all trunks and other BS) to just PAP2 sip.conf client and alarmreceiver in extentions.conf (no change) 2)Tried just about every combination of settings in the SPA-PAP2 and sip.conf dtmfmode= (auto, rf?, inband, info...) 3)Logging.conf set: console => notice,warning,error,dtmf,debug (is dtmf turned off or non existent in 1.8.3?) 4)chan_dahdi.conf added relaxdtmf=yes under [channels] (full restart of asterisk - no change) 5)compiled from source 1.8.15.0 & 10.7.0 (no change) 6)full day of trying almost all combinations of above (exhausting!) Debugging: 1)1.8.15.0 (This is with old/original settings (sip & PAP2)): {code} AlarmReceiver: Setting read and write formats to ULAW > AlarmReceiver: Answering channel > AlarmReceiver: Waiting for connection to stabilize > AlarmReceiver: Waiting for first event from panel > AlarmReceiver: Sending 1400Hz 100ms burst (ACK) > AlarmReceiver: Sending 2300Hz 100ms burst (ACK) > AlarmReceiver: DTMF Digit Timeout on SIP/sip-sipura2-fax-line1-00000002 == AlarmReceiver: Incomplete string: , trying again... > AlarmReceiver: Sending 1400Hz 100ms burst (ACK) > AlarmReceiver: Sending 2300Hz 100ms burst (ACK) > AlarmReceiver: DTMF Digit Timeout on SIP/sip-sipura2-fax-line1-00000002 == AlarmReceiver: Incomplete string: , trying again... > AlarmReceiver: Sending 1400Hz 100ms burst (ACK) > AlarmReceiver: Sending 2300Hz 100ms burst (ACK) {code} Followed by a wall of DTMF debug (see INFO section below DTMF dbug) 2)randomly I would get back (inside the wall of DTMF debug) these lines: {code} == AlarmReceiver: Received Event 8106118106180061 == AlarmReceiver: Nonzero checksum {code} clearly the event numbers are wrong they should look (see below 'what works') What Works: revert to 1.8.3(source) + old/original configs + old/original SPA-PAP2 settings. (works every time) Output:{code} -- Executing [18XXXXXX@alarm-in:1] Ringing("SIP/sip-sipura2-fax-line1-00000007", "") in new stack -- Executing [18XXXXX@alarm-in:2] AlarmReceiver("SIP/sip-sipura2-fax-line1-00000007", "") in new stack > AlarmReceiver: Setting read and write formats to ULAW > AlarmReceiver: Answering channel > AlarmReceiver: Waiting for connection to stabilize > AlarmReceiver: Waiting for first event from panel > AlarmReceiver: Sending 1400Hz 100ms burst (ACK) > AlarmReceiver: Sending 2300Hz 100ms burst (ACK) == AlarmReceiver: Received Event 3609181131000061 == AlarmReceiver: Received Event 360918313100006B == AlarmReceiver: Received Event 3609181406000034 > AlarmReceiver: App exiting... {code} I am willing to walk up the release tree to see exactly what release breaks the alarmreceiver if this bug is not trashed. Can do packet dumps if it will help. Willing to try patches if it helps. ///////////////////////////////////////////////////////////////////////////// // RAW INFO: sip.conf: {code} [sip-sipura2-fax-line1] type=friend callerid="FAX Admin" <287> username=sip-sipura2-fax-line1 secret=xxxxxxxxxxxx host=dynamic canreinvite=yes ;dtmfmode=rfc2833 context=alarm-in dtmfmode = inband dtmf = inband ;disallow=all ;allow=alaw,ulaw {code} extentions.conf: {code} ;I changed extension to 1234567 [alarm-in] exten => 1234567,1,Ringing(); ;exten => 1234567,2,Wait(6); ;exten => 1234567,3,SayNumber(${EXTEN},c); exten => 1234567,2,AlarmReceiver; exten => 1234567,n,Hangup {code} DTMF debug on failed attempts 1.8.15.0 getting about 100 lines of this before app exits (NOTE: no dtmf debug output on 1.8.3-working version): {code} [Aug 12 14:30:12] DTMF[818]: channel.c:4067 __ast_read: DTMF end '1' has duration 40 but want minimum 80, emulating on SIP/sip-sipura2-fax-line1-00000002 [Aug 12 14:30:12] DTMF[818]: channel.c:4167 __ast_read: DTMF end emulation of '1' queued on SIP/sip-sipura2-fax-line1-00000002 [Aug 12 14:30:14] DTMF[818]: channel.c:4090 __ast_read: DTMF begin '1' received on SIP/sip-sipura2-fax-line1-00000002 [Aug 12 14:30:14] DTMF[818]: channel.c:4100 __ast_read: DTMF begin passthrough '1' on SIP/sip-sipura2-fax-line1-00000002 [Aug 12 14:30:14] DTMF[818]: channel.c:4005 __ast_read: DTMF end '1' received on SIP/sip-sipura2-fax-line1-00000002, duration 0 ms [Aug 12 14:30:14] DTMF[818]: channel.c:4045 __ast_read: DTMF end accepted with begin '1' on SIP/sip-sipura2-fax-line1-00000002 [Aug 12 14:30:14] DTMF[818]: channel.c:4060 __ast_read: DTMF end '1' detected to have actual duration 59 on the wire, emulation will be triggered on SIP/sip-sipura2-fax-line1-00000002 {code} | ||||||||
| Comments: | By: john (hossiken) 2012-08-12 17:10:47.296-0500 PA2P settings By: john (hossiken) 2012-08-13 13:10:58.894-0500 Update: I tried to apply the patch from [ASTERISK-19610|https://issues.asterisk.org/jira/browse/ASTERISK-19610] to 1.8.15.0 source but the revisions of source/patch did not match. I tried manually applying the patch but the '}' did not match up and I'm not strong enough with this code to place them properly. I then got brave and copied dsp.c (1.8.3) to (1.8.15.0) source and clean recompiled 1.8.15.0. The result is a WORKING!! 1.8.15.0-(?beta) alarmreceiver. Thanks Jean-Philippe Lord! It appears that the problem is in dsp.c 1.8.10rc1 - Now(1.8.15.0) (dsp.c stopped being able to decode a quick DTMF sequence). I would think this is going to impact a lot of users. The troubling thing to me is that in some cases users will not realize they have incurred this bug for some time.... took me 2 weeks to realize my alarm was no longer working :( By: Rusty Newton (rnewton) 2012-08-14 17:03:33.130-0500 John, thanks for reporting this issue and in such detail with good troubleshooting. I've closed it as duplicate of ASTERISK-19610 , but all of your info will certainly help the developers looking into it. If anyone needs additional information from you, this report will be re-opened. Until then you can watch ASTERISK-19610 and help test any patches that come out on there. Thanks again! If you have any questions, re-open the ticket or ask in #asterisk-bugs | ||||||||