[Home]

Summary:ASTERISK-00410: [patch] Allow mp3 streams to be played for MOH
Reporter:Tilghman Lesher (tilghman)Labels:
Date Opened:2003-10-21 11:28:26Date Closed:2011-06-07 14:05:02
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) moh__stream__20031021.diff
Description:Instead of specifying files, this patch allows a URL to be placed in musiconhold.conf to specify a source for a stream.

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

To use, enter the configuration as follows:

vocaltrance => mp3:/var/lib/asterisk/empty,http://64.236.34.161:80/stream/1065

You'll obviously need to create the empty directory /var/lib/asterisk/empty.
Comments:By: John Todd (jtodd) 2003-10-21 20:35:32

Excellent!  Tilghman is my hero.

edited on: 10-21-03 20:34
By: John Todd (jtodd) 2003-10-21 20:48:46

OK, take that cape and mask back from Tilghman; he gets no Hero prize yet.  I tested this, and it doesn't work with my RH7.2 system.  I tried with a known-operational MP3 stream:

http://205.188.234.129:8024/

I did a "touch /var/lib/asterisk/empty" to create the empty file.

default => mp3:/var/lib/asterisk/empty,http://205.188.234.129:8024

I tried with a trailing "/" and without; same results (mpg123 is fussy about that sometimes.)  Normal hold music still works fine (file-based) if I comment out the streaming line and put in:

default => quietmp3:/var/lib/asterisk/mohmp3,-z

I even tried with the exact same string that is shown in the Additional Information area (substituting "default" for "vocaltrance") and nothing.  No attempts to send any packets to 64.236.34.161, either, so it's not getting to that point.
By: Tilghman Lesher (tilghman) 2003-10-21 22:08:27

touch(1) doesn't create an empty directory; it creates an empty file.  rm that file, mkdir /var/lib/asterisk/empty and it will work.
By: John Todd (jtodd) 2003-10-22 02:01:44

OK, it works fine.  I didn't realize that "empty" needed to be a directory; I just thought it was a place holder.

This patch is tested and works fine.  Whee!
By: John Todd (jtodd) 2003-10-22 02:17:43

I really like this patch.  There are some shortcomings, none of which should prevent this from getting added to CVS:

1) If the stream dies (network outage, streaming server failure, etc.) does the MOH process try to re-initiate another connection?

2) The stream is always streaming.  The moment you start up *, it starts pulling down a stream.  Maybe it would be handy if this was started/stopped if there was nobody using the MOH features (that probably would solve #1, as well, since the TCP session would be re-established every time someone tried to access the MOH system if there was no current stream active)  

1 & 2 may be impossible to solve within the confines of *'s programming, given that mpg123 is currently used for audio decoding.
By: florian (florian) 2003-10-22 03:29:24

Well, that would start the discussion (again?) about why mpg123 is running at all if there is no-one on hold. After all, doing the fork() from ast_moh_start and possibly killing it from ast_moh_stop ?
By: Brian West (bkw918) 2003-11-06 23:42:44.000-0600

moh doesn't eat much if any CPU.  I flatline on 0.00 0.00 0.00 when the box sits idle.  Plus we don't wanna be like other companies that start the hold music with the same song everytime you call in and put on hold.  Thats cheesy.  I use a MusicOnHold Extension for testing all the time also.

bkw
By: florian (florian) 2003-11-07 03:29:10.000-0600

a simple -z option would deal with that if you'd like. Besides, tell me if I'm wrong, but I get the impression MOH starts a new thread with music every time anyway (or at least, everytime I use MOH it does not drop into a running track, it starts a track. Therefore, the point of MOH running in background seems unnessecary ?
By: Brian West (bkw918) 2003-11-07 09:52:57.000-0600

Florian,
     If we don't have a common stream to feed MOH from then we must have a stream and mpg123 running for each call on hold.  If you have 23 calls on hold then you have 23 mpg123 processes if you try to start one every time someone is put on hold.  Right or Wrong?  Thats how I see it.  The current MOH setup works great.  If it isn't broken... don't fix it. :P
By: florian (florian) 2003-11-07 10:19:03.000-0600

Hmmyes, true enough. It does however pose minor issues (if a stream is running all the time, it will cost more data traffic and might cause bandwidth issues in some cases) which is why I was wondering about the design considerations behind the current setup. However, this is getting more and more off-topic :-)
By: Brian West (bkw918) 2003-11-07 10:26:15.000-0600

The neat thing about this concept is that you can have a cluster of * machines all using the same music on hold stream from another server on the same lan.  Then its irrelevant about bandwidth usage.  I was speakin in the sense of playing MOH from disk and not streaming.  The resource hit isn't much if any at all.
By: oliver (oliver) 2003-11-21 16:55:44.000-0600

Yo,

Just to let you know I gave this patch a spin as well.  Seems to work great over here.  BTW: When nobody is listening to the MOH, the mpg123 seems to be sitting idle and not pulling the stream or pushing audio, just like it doesn't continue further into an MP3 if nobody is listening.  I tested this with tcpdump.  There didn't seem to be any streaming going on with MOH sitting idle.


 Grtz,

    Oliver
By: Brian West (bkw918) 2003-11-21 16:58:06.000-0600

Yep it behaves the same way on files too. :P
By: oliver (oliver) 2003-12-03 19:08:00.000-0600

Yo,

I discovered a small problem with MP3-streams.  They start playing the first time a channel gets connected to MOH, but get interrupted in the way I described above as soon as no more channels are listening to MOH.  An unfortunate side-effect is that in this case, mpg123 seems to lose the stream after a short time.  The next channel connecting to MOH will hear the part of the stream that was still in mpg123's buffer, after which the audio gets cut off.  Only restarting Asterisk or killing the mpg123-processes (after which Asterisk spawns fresh ones, which re-connect to the stream) will reliably get the stream back.

Maybe this patch could be modified to kill and restart mpg123 if the MOH-source is a stream, has been idle with no channels listening and a new channel connects to it.

In short: Check the number of listeners each time a new channel connects to MOH.  If there are 0 listeners and the MOH-source is a stream, restart mpg123 to allow it to re-connect.


   Grtz,

      Oliver

edited on: 12-03-03 19:03
By: mlh (mlh) 2004-01-19 10:41:10.000-0600

Will this be put into CVS
By: Tilghman Lesher (tilghman) 2004-01-19 11:27:11.000-0600

Probably not.  Not until the previous shortcomings have been addressed, if at all.  I made the patch on a whim, knowing the capability of mpg123 to stream data from the web, but I haven't had time to address those shortcomings.  Perhaps somebody else would like to try their hand at enhancing the patch to meet the outstanding issues?
By: Olle Johansson (oej) 2004-03-22 11:05:02.000-0600

Good patch, but not ready for cvs. If you're interested in seing it being finished and put into CVS contact the developer (Corydon on IRC) to make an agreement. A decent bounty and it will be fixed.