|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:40||Date Closed:||2012-09-05 11:04:07|
|Versions:||1.4.42 184.108.40.206 220.127.116.11 10.0.0-beta1||Frequency of|
|Environment:||Fedora 15, kernel 18.104.22.168-0.fc15.i686 #1 SMP||Attachments:|
|Description:||Using alarmreceiver in all aforementioned Asterisk versions (plus the Fedora packaged 22.214.171.124) 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.