[Asterisk-bugs] [Asterisk 0010123]: MusicOnHold() drops the channel if the specified class does not exist

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10123 
====================================================================== 
Reported By:                blitzrage
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10123
Category:                   Resources/res_musiconhold
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.5 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             07-05-2007 14:37 CDT
Last Modified:              07-05-2007 15:11 CDT
====================================================================== 
Summary:                    MusicOnHold() drops the channel if the specified
class does not exist
Description: 
Subject pretty much says it all. Easiest fix is probably just to fall back
to the 'default' MoH class. This would also assume 'default' existed,
although if it didn't, then we can just drop the channel... or
alternatively, continue on in the dialplan (with the former being preferred
I guess since it won't change any behaviour)
====================================================================== 

---------------------------------------------------------------------- 
 juggie - 07-05-07 15:11  
---------------------------------------------------------------------- 
What happening is ast_moh_start does its whole fallback procedure where it
checks for a number of different levels of the music on hold class setting,
however when it does this it doesn't check to see if the class actually
exists.  Now granted this is *MOSTLY* user error.  But since blitzrage
apparently has a user for it i'll post this patch tomorrow morning,
essentially rather then just taking the first setting we find (or default
if we get that far) we'll actually check to ensure the moh class exists and
keep falling through if it indeed does not. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-05-07 15:11  juggie         Note Added: 0066557                          
======================================================================