Summary:	ASTERISK-12260: retrydial hangs up when using a silent soundfile as anouncement
Reporter:	snyfer (snyfer)	Labels:
Date Opened:	2008-06-26 03:22:11	Date Closed:	2010-09-26 11:38:40
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:		Frequency of Occurrence
Related Issues:	is related to ASTERISK-18994 playback of file format without seeking is broken
Environment:		Attachments:	( 0) bug12929.patch ( 1) silent.tgz
Description:	Hi tis is not a big problem and we do not need it at all. But I think this is a bug: When we call retrydial(silent,1,2,xxx,15,g) and silent is a completely silent soundfile, retrydial hangs up after the called partie hangs up. when we change the file to a "normal" soundfile it works fine. Maybe asterisk is checking or waiting for any bytes from the soundfile? Just to let you know. best regards Martin
Comments:	By: Joshua C. Colp (jcolp) 2008-07-02 21:38:10 Can you please provide complete console output of this happening, and is the silent file an included one - or your own? Does the file actually exist? By: snyfer (snyfer) 2008-07-06 23:59:55 Hi,                     here the log of the problem. The soundfile is existing. It is not an included one. It is our own file and is completely silent. This is why it has 0 bytes. It is an .ulaw file. produced same way as the low noice file but silent. I try to attach teh silent file. The second test is with a silent file wich is not really silent but very low noice. So we cannot here something but the file has not 0 Bytes. This works. Please note: This seems to be the same Problem as in ap_queues Issue ID:                   12924 Logs:  == Using SIP RTP CoS mark 5    -- Executing [124@from-inside-43422760300:1] RetryDial("SIP/mts-0827e8b0", "dicore/silent,1,1,SIP/MTSprivat,20,g") in new stack  == Using SIP RTP CoS mark 5    -- Called MTSprivat    -- SIP/MTSprivat-082085d0 is ringing    -- SIP/MTSprivat-082085d0 answered SIP/mts-0827e8b0    -- Packet2Packet bridging SIP/mts-0827e8b0 and SIP/MTSprivat-082085d0    -- <SIP/mts-0827e8b0> Playing 'dicore/silent.ulaw' (language 'de') ###we do not hear this anymore###   -- Started music on hold, class 'default', on channel 'SIP/mts-0827e8b0'    -- Stopped music on hold on SIP/mts-0827e8b0  == Spawn extension (from-inside-43422760300, 124, 1) exited non-zero on 'SIP/mts-0827e8b0'    -- Executing [h@from-inside-43422760300:1] Hangup("SIP/mts-0827e8b0", "") in new stack  == Spawn extension (from-inside-43422760300, h, 1) exited non-zero on 'SIP/mts-0827e8b0' #Test with a very low noice file:  == Using SIP RTP CoS mark 5    -- Executing [123@from-inside-43422760300:1] RetryDial("SIP/mts-08216b00", "stille,1,1,SIP/MTSprivat,20,g") in new stack  == Using SIP RTP CoS mark 5    -- Called MTSprivat    -- SIP/MTSprivat-08298af0 is ringing    -- SIP/MTSprivat-08298af0 answered SIP/mts-08216b00    -- Packet2Packet bridging SIP/mts-08216b00 and SIP/MTSprivat-08298af0    -- <SIP/mts-08216b00> Playing 'stille.ulaw' (language 'de')    -- Started music on hold, class 'default', on channel 'SIP/mts-08216b00'    -- Stopped music on hold on SIP/mts-08216b00    -- Executing [123@from-inside-43422760300:2] Playback("SIP/mts-08216b00", "callforthinking") in new stack    -- <SIP/mts-08216b00> Playing 'callforthinking.slin' (language 'de')    -- Auto fallthrough, channel 'SIP/mts-08216b00' status is 'ANSWER'    -- Executing [h@from-inside-43422760300:1] Hangup("SIP/mts-08216b00", "") in new stack  == Spawn extension (from-inside-43422760300, h, 1) exited non-zero on 'SIP/mts-08216b00' #Test end Hope this helps a little bit. best regards Martin By: Jeff Peeler (jpeeler) 2008-11-19 19:50:56.000-0600 I'm attaching this patch mainly so that others can review the approach taken. What I really wanted to do was just return that the file was empty via return code in ast_filehelper, but ast_openstream_full returns NULL for failure and the stream for success. The opening of the file stream is successful since the file exists though. In this case, ast_playstream was returning FSREAD_FAILURE because there was no data to return. I'm assuming that creating a new field in ast_filestream just for the purposes of flagging a zero length file is probably not justified. By: Jeff Peeler (jpeeler) 2008-11-20 11:46:47.000-0600 Manually closing bug. Fixed trunk in r158062 and in 1.6.1 r158069.