| Summary: | ASTERISK-02154: [request] res_musiconhold be reload enabled | ||
| Reporter: | Steven Sokol (ssokol) | Labels: | |
| Date Opened: | 2004-07-30 17:43:57 | Date Closed: | 2011-06-07 14:05:27 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | The MOH resource does not appear to include code to handle a reload request. I can add new directories to the /var/lib/asterisk/mohmp3/ folder and load MP3s, add a new entry in the classes section of the musiconhold.conf file, and yet the system will not recognize the new class until it is _RESTARTED_ not reloaded. ****** ADDITIONAL INFORMATION ****** A quick perusal of the code leads me to believe that applications (including resources like MOH and Monitor) lack the ability to be reloaded (unlike the channels interface which includes a reload command). This becomes someting of a problem for my Virtual PBX configuration as the administrator needs to be able to create new classes on the fly (or at least without requiring a restart of the system). Any thoughts on how to handle this? Can we make each MOH class a virtual channel, and use the res_musiconhold to connect with the proper moh channel? | ||
| Comments: | By: Brian West (bkw918) 2004-08-12 19:30:32 Really no way to fix this without major changes. By: twisted (twisted) 2004-08-24 13:44:19 Since MOH is spawned off as child processes (mpg123), making MOH reloadable, and the changes made effective immediately, would require us to kill the children and restart them. I don't see this being a clean method of handling this... Any other suggestions? By: Brian West (bkw918) 2004-08-25 16:12:37 SOON MY PRETTY!!!! By: twisted (twisted) 2004-10-01 11:53:14 over 1 month w/o activity. Closing. Feel free to re-open later. | ||