| Summary: | ASTERISK-02224: [patch] Using a stream for MusicOnHold | ||
| Reporter: | vulture (vulture) | Labels: | |
| Date Opened: | 2004-08-14 19:48:00 | Date Closed: | 2008-01-15 15:06:44.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Resources/res_musiconhold |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) moh_stream_20sec_respawn.patch ( 1) moh_stream.patch | |
| Description: | This patch allows you to specify a stream in place of a directory for the MusicOnHold classes. ****** ADDITIONAL INFORMATION ****** If the directory specified contains a http:// or https:// then the whole directory portion will be passed straight to mpg123 as the argument to play. This will allow you to use a single instance of mpg123 in place of MP3Player() if you were to blackhole a caller into a MOH extension. Great for tele-marketers! ; Using a directory default => mp3:/var/lib/asterisk/mohmp3,-z ; Using a stream stream => mp3:http://myshoutcastserver.domain.com:8000/ ; Using a secure stream streamsecure => mp3:https://mysecureserver.domain.com:8000/ | ||
| Comments: | By: Brian West (bkw918) 2004-08-15 19:44:25 If the stream stops it will never restart have you tested this to make sure you have fixed this problem? By: vulture (vulture) 2004-08-16 04:26:56 I will have to check into that issue. This patch makes no other checks at the moment, simply looks for http:// or https:// and sends that dir string directly as the argument to play. I will have to look into both a) source server has no streamer/dj and b) source server looks like a blackhole. By: wsuff (wsuff) 2004-08-16 19:56:43 Best bet assuming Shoutcast using the structure you posted above in the original post is to use the /7.html which is a comma seperated representation of all the stats for the server including if it does have a source. I have the names of each field and have already parsed it for some other needs so I can contribute that info to the bug once I find it. By: Mark Spencer (markster) 2004-08-16 22:48:40 To confirm, do you have a disclaimer on file? By: vulture (vulture) 2004-08-17 02:29:22 Disclaimer is on file. After further checking on server blackholes or dj stops streaming, or no stream on connect I have found the following. Using mpg123-0.59r on Slackware 9.1 kerenl 2.4.26: Servers that have no repsonse on connect took a little over 3 minutes to fail, thus casuing asterisk to respawn mpg123 again. Process repeats. Servers that are not reachable and a icmp is thrown from a router will cause mpg123 to exit at that point. Process repeats. Servers that do not have a sc server running and send a tcp reset, mpg123 instantly fails and mpg123 is spawned again. Process repeats. Servers that have no dj will result in the same as no sc server running on box. Process repeats. Servers that loose their dj will result in a blank time where mpg123 is waiting for the stream to resume, then will timeout and exit. I think this timeout is dependant upon when the sc server is set to drop listeners when no dj is streaming. Process will be that same as no dj from that point on. Servers that become a blackhole after streaming has begun will have a 3 minute period before mpg123 exits. Process will be the same as if the server is simply a blackhole. End findings are that mpg123 will exit anywhere from immediatly to upto 3:30 depending on the problem between the sc server and mpg123 as the client. A simple 20 second sleep called after detecting that the mpg123 process has exited will solve the problem of flooding the network with connect requests, and also keep cpu utilization low when the stream is not up for one reason or another. ------------------ I made a mistake on stating the https:// would work. mpg123 does not do https://. My next patch will have the 20 second wait and only accept http:// or HTTP:// - This patch will come shortly. By: vulture (vulture) 2004-08-17 04:09:24 Patch is uploaded. I'm not sure how to put a check in that will carry though to the next respawn to indicate that moh class x has been spawned before and that the 20 second wait should kick in, so everytime it is spawned, a 20 second wait will occur before executing mpg123. This basically means that when asterisk first starts up, the moh will not start for 20 seconds. This should not be a major issue as once it is going, you won't have another 20 seconds (+ mpg123 timeout if applicable) of silence until mpg123 exits. Maybe somebody else can figure out how to easily add a tracker for each class so that the 20 second sleep kicks in when the class has been started, but not stopped or never started. By: Brian West (bkw918) 2004-08-20 21:32:46 I'm going to say it again and again... This patch is not needed [custom_exec] default => /usr/bin/mpg123,-q,-m,-f,8192,-s,--mono,-r,8000,-b,2048,http://1.2.3.4/live Asterisk can already this this... This is in res_musiconhold.c already no silly patch needed. bkw By: vulture (vulture) 2004-08-20 22:36:22 This patch can then be used to simplfy needing to specify every agument for the command to run by making the standard definition take a directory or a http stream url, thus saving people headaches. By: vulture (vulture) 2004-08-20 22:38:17 Also, keep in mind that this patch puts a 20 second delay before launching mpg123, thus limiting the spawning of mpg123 to 3 times per minute. This delay would be needed in the event that the stream is broken. By: Tilghman Lesher (tilghman) 2004-08-21 00:08:07 You may want to note that this idea has been submitted twice before: ASTERISK-410 ASTERISK-1332 By: Mark Spencer (markster) 2004-08-22 11:19:38 I like the way the patch makes it possible to stream from another server more easily than bkw_'s example of how to do it with current syntax. However, I'm not sold on the 20 second delay... I like the concept certainly of not slamming another server, but i don't want the initial 20 second delay. By: vulture (vulture) 2004-08-22 19:39:25 I do agree that having a 20 second delay on the initial spawn is not desired, however I'm at a loss on how to code a tracking variable in for each moh class, to track how many spawns have been done for that class, allowing the delay to be skipped the first time. The 20 second delay could also be changed and/or set in the .conf file. 10 or 15 seconds maybe better, but if the stream server is down, you would be increasing the spawn rate from 3/minute to 4-6. I'm not as worried about slamming the stream server with requests, as I am for having * respawning mpg123 as fast as it can. I think putting the spawn delay into the .conf and tracking the # of spwans for each class to skip the delay the first time would make this patch complete and a good improvement to moh and asterisk. If someone can help with a tracking variable code for each moh class, I can get the .conf variable for respawn_delay done. By: Tilghman Lesher (tilghman) 2004-08-22 21:31:14 Why not add an element to 'struct mohclass' of 'time_t lastspawn'? You could then use the lastspawn time to know whether or not you've spawned the specific instance of the class recently (within whatever timeframe, 20 seconds or otherwise) and not attempt to reconnect the stream in that case (or until lastspawn is at least 20 seconds into the past). You don't even really need to otherwise initialize the structure element, as it's already preset to 0, and a time of 0 is always far into the past. By: Mark Spencer (markster) 2004-09-04 01:38:14 Okay I think I came up with a reasonable way to get it to work. By: Digium Subversion (svnbot) 2008-01-15 15:06:44.000-0600 Repository: asterisk Revision: 3723 U trunk/res/res_musiconhold.c ------------------------------------------------------------------------ r3723 | markster | 2008-01-15 15:06:43 -0600 (Tue, 15 Jan 2008) | 2 lines Add stream support and permit minimum respawn time (bug ASTERISK-2224) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=3723 | ||