[Home]

Summary:ASTERISK-18417: app_alarmreceiver hanging forever in send_tone_burst/ast_waitfor()
Reporter:Kostas Liakakis (frap)Labels:
Date Opened:2011-09-05 06:49:40Date Closed:2012-09-05 11:04:07
Priority:MinorRegression?
Status:Closed/CompleteComponents:Applications/app_alarmreceiver
Versions:1.4.42 1.6.2.20 1.8.6.0 10.0.0-beta1 Frequency of
Occurrence
Constant
Related
Issues:
is related toASTERISK-16668 ACK tone interupted - Jitterbuffers do not function properly as AlarmReceiver App does not send RTP regularly
is related toASTERISK-16694 [patch] ACK tone not reliable on embedded platform with low CPU power
Environment:Fedora 15, kernel 2.6.40.3-0.fc15.i686 #1 SMPAttachments:
Description:Using alarmreceiver in all aforementioned Asterisk versions (plus the Fedora packaged 1.8.5.0) would answer the call but fail to send the initial handshake tone (1400Hz). Verbose output would look like this:
 == Using SIP RTP CoS mark 5
   -- Executing [9951@from-office:1] Ringing("SIP/alarm_panel-00000000", "") in new stack
   -- Executing [9951@from-office:2] Wait("SIP/alarm_panel-00000000", "6") in new stack
   -- Executing [9951@from-office:3] AlarmReceiver("SIP/alarm_panel-00000000", "") 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)

(it would wait at this stage interminently w/o playing anything to the connected handset, until I hanged up when it would just echo this: )

      > AlarmReceiver: App exiting...


Trying to add some log messages here and there I found out it would wait forever in send_tone_burst(), calling ast_waitfor(chan, -1). That was as far as I could get, the code in ast_waitfor_* was too tedious for me to follow... Seeing however that the code hasn't been modified in ages and given that I had the same setup working on an older Gentoo machine (which blew up recently, hence the new installation), I would dare say it is a kernel/libc/gcc change that revealed a race someplace...

Searching for a solution, I stumbled upon ASTERISK-16694 . The bug case is irrelevant, but the patch itself gets rid of proprietary send_tone_burst/make_tone_burst functions in favour of Asterisk's internal ast_playtones_*() ones. Voila... problem fixed!!!

Please consider applying ASTERISK-16694 soon.
Comments:By: Jean-Philippe Lord (jplord) 2012-08-16 07:53:13.300-0500

Hello Kostas Liakakis,

Can you go in ASTERISK-16694 and add a comment confirming you have tested and that issue got resolved.