Summary:ASTERISK-12260: retrydial hangs up when using a silent soundfile as anouncement
Reporter:snyfer (snyfer)Labels:
Date Opened:2008-06-26 03:22:11Date Closed:2010-09-26 11:38:40
Versions:Frequency of
is related toASTERISK-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
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

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


 == 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

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.