[Home]

Summary:ASTERISK-03855: [patch] ast_waitstream does not close the stream.
Reporter:Anthony Minessale (anthm)Labels:
Date Opened:2005-04-04 09:14:56Date Closed:2011-06-07 14:10:42
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) file.c.diff
Description:If you call ast_waitstream and interrupt the stream with a dtmf digit the function returns , stopping the sound but it does not close the stream meaning the read/write format is still setup to play the file so if you do this while playing a file in a different codec than your current native format you are stuck in the readformat of the file you were playing generating lots o' "Huh?  A GSM frame that isn't a multiple of 33 or 65 bytes long from (null) (320)?" warnings and no audio.

I'm pretty sure this one will fix a pretty decent sized list of "random" errors.




****** ADDITIONAL INFORMATION ******

Disclaimer on file.
anthmct@yahoo.com
Comments:By: Mark Spencer (markster) 2005-04-04 09:22:21

This is not a but, because if you look at the digit and decide you want to keep going, you can simply continue waiting stream.
By: Anthony Minessale (anthm) 2005-04-04 09:56:23

<$.02>
Then , the callers of this function should know that because there are a ton of places that happily expect the sound to stop playing and make no attempt to close the stream, if you interrupt the waitstream you suddenly inherit the responsibility to close the stream which is not an absoloute so that kind of asyncronous stuff leads to bugs.
</$.02>
By: Anthony Minessale (anthm) 2005-04-04 09:56:53

just wanted to note my opinion
By: Brian West (bkw918) 2005-04-06 21:09:33

I do feel this is a bug and could very well be the cause of 2519.

/b
By: Mark Spencer (markster) 2005-04-07 13:34:00

The correct fix here is to find places where waitstream is called and stopstream isn't and fix them, or to create a new ast_waitandstopstream (or related) function.
By: Kevin P. Fleming (kpfleming) 2005-04-13 01:15:35

I agree, the sequence goes this like:

ast_streamfile()
ast_waitstream(...)

The caller of waitstream should _already_ be aware that they have responsibility for that stream to be closed. In fact, they can safely call ast_stopstream() even if ast_waitstream() did it for them because the stream ran out, so there's no need to even make it conditional.

Can you point to any specific cases you've seen where stopstream() is not being called as it should be?
By: Kevin P. Fleming (kpfleming) 2005-04-20 12:00:05

* bump *
By: Kevin P. Fleming (kpfleming) 2005-04-29 19:44:11

I sense a lack of desire to pursue this one... If there are specific cases that need wait+stop semantics, then let's create an API for that purpose, without changing the existing APIs.