|Summary:||ASTERISK-16929: [patch] streamplayer-like utility, but for anything that comes out of a shell pipe|
|Reporter:||Michel Belleau (malaiwah)||Labels:|
|Date Opened:||2010-11-08 10:40:58.000-0600||Date Closed:||2012-02-16 07:24:25.000-0600|
|Environment:||Attachments:||( 0) patch_streamnoblock.txt|
|Description:||streamplayer Asterisk utility can only be used for raw TCP streams.|
I just adapted the utility to be useful with anything that comes from a shell pipe and added it to my "pipe chain" for my streaming music-on-hold. The utility takes input from stdin (in 2k blocks) and sends it to stdout only if the write would not block. As explained in streamplayer, Asterisk blocks writes to stdout when it does not need the MOH source, but streaming mpg123/sox I use would still be outputting data.
This effectively gets rid of the error I had in my Asterisk at various intervals depending on music-on-hold usage:
[Nov 8 09:31:17] NOTICE res_musiconhold.c: Request to schedule in the past?!?!
****** ADDITIONAL INFORMATION ******
Here is the content of the script I'm using for my Streaming MP3 music-on-hold. Notice at the last pipe in the chain, the "streamnoblock" utility takes the streaming output from the sox/mpg123 and makes sure to discard it if Asterisk do not want it right away (blocked writes to stdout).
/usr/bin/mpg123 -q -s http://localhost:8000/stream | sox -t raw -s -r 44100 -4 - -s -r 8000 -2 -c 1 -t raw - | streamnoblock
|Comments:||By: Leif Madsen (lmadsen) 2010-11-18 14:18:35.000-0600|
Is this an application, or something that should just go into contrib/scripts/ ?
By: John Covert (jcovert) 2010-12-27 22:01:34.000-0600
This builds a utility that goes into /usr/sbin/ (or other appropriate destination). In 1.8, it needs ONLY the
line in utils/Makefile (no change to ALL_UTILS)
added to menuselect-tree just before the similar lines for "streamplayer" to make it selectable (and off by default) in the Utilities menu.
It also needs the line
removed to eliminate a compiler warning for an unused variable.
By: John Covert (jcovert) 2011-01-11 20:45:17.000-0600
When I first saw this, I said, "Oh, cool. A way to end the problem I had been having in 1.6 with the "schedule in past" messages and moh eventually (within 24 hours) stopping until a restart of asterisk.
After running with 18.104.22.168 for a while, I find that (at least on my configuration) these messages have stopped, and moh lasts at least as long as 22.214.171.124 has stayed up.
Has something fundamentally changed that would make something like this unnecessary?
By: Vladimir Mikhelson (vmikhelson) 2011-02-28 23:51:16.000-0600
@jcovert. Is your experience still positive with the streamnoblock utility? I am also seeing these "schedule in the past" messages and having some other strange problems with streaming MOH.
By: John Covert (jcovert) 2011-03-01 00:03:30.000-0600
I actually found that with 1.8.x I did not need to use it. So although I initially was interested in it and built it for 1.8.x, I found that it was
unnecessary, and have not been using it.
By: Vladimir Mikhelson (vmikhelson) 2011-03-01 01:37:50.000-0600
Thank you for the reply.
I was just thinking it may fix this "Request to schedule in the past?!?!" error message. The message is associated with a temporary streaming pause which resolves itself after some period of silence. At least this is what I see in my environment.
I also needed to pre-load the res_musiconhold.so in modules.conf otherwise streaming would not work. This one is related to res_timing_dahdi.so. It has to be loaded after the res_musiconhold.so for streaming to work.
By: Matt Jordan (mjordan) 2012-01-31 15:52:09.670-0600
Is this application still useful as a workaround for MOH behaviors in Asterisk 1.8? Based on the previous comments, it appears as if there is no longer a use case for this in Asterisk.
By: Leif Madsen (lmadsen) 2012-02-16 07:24:17.661-0600
I'm going to close this issue, with thanks, but it appears as though versions of Asterisk 1.8+ no longer require this functionality to be handled separate of vanilla Asterisk.