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
Versions:1.4.42 10.0.0-beta1 Frequency of
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 #1 SMPAttachments:
Description:Using alarmreceiver in all aforementioned Asterisk versions (plus the Fedora packaged 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.