[Home]

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-0600Date Closed:2012-02-16 07:24:25.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Utilities/General
Versions:Frequency of
Occurrence
Related
Issues:
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[24616] 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

streamnoblock: streamnoblock.o

line in utils/Makefile (no change to ALL_UTILS)

but needs

 <member name="streamnoblock">
       <defaultenabled>no</defaultenabled>
 </member>

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

  int s;

removed to eliminate a compiler warning for an unused variable.

/john


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 1.8.1.1 for a while, I find that (at least on my configuration) these messages have stopped, and moh lasts at least as long as 1.8.1.1 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.

Thank you,
Vladimir
By: John Covert (jcovert) 2011-03-01 00:03:30.000-0600

Vladimir,

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

John,

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.

-Vladimir
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.