[asterisk-bugs] [Asterisk 0017807]: Music on hold doesn't recover very cleanly when it can't play a file

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Sep 9 12:23:29 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17807 
====================================================================== 
Reported By:                kshumard
Assigned To:                bbryant
====================================================================== 
Project:                    Asterisk
Issue ID:                   17807
Category:                   Resources/res_musiconhold
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
JIRA:                       SWP-2016 
Regression:                 No 
Reviewboard Link:           https://reviewboard.asterisk.org/r/910/ 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-08-06 11:35 CDT
Last Modified:              2010-09-09 12:23 CDT
====================================================================== 
Summary:                    Music on hold doesn't recover very cleanly when it
can't play a file
Description: 
I found that MOH using default files misbehaved in 1.8.0-beta1 because of a
dot in the filenames of the LICENSE, CHANGES, and CREDITS files. I see that
this has been fixed in 1.8.0-beta2 by renaming those files so they don't
include a dot. But this uncovered something else that it wouldn't hurt to
address.

When res_musiconhold can't play a file in one of its classes, it stops
musiconhold and just waits indefinitely.

I suggest that a cleaner way to handle this would be to skip the file it
can't play (and perhaps remove it from the musicclass) and continue on to
try to play the next file in the class. As it is, MOH stops and there's
just dead air on the channel until it's hungup or taken off hold or
whatever. Logging a warning and playing another file is IMO a saner/cleaner
way to fail.
====================================================================== 

---------------------------------------------------------------------- 
 (0126778) svnbot (reporter) - 2010-09-09 12:23
 https://issues.asterisk.org/view.php?id=17807#c126778 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 285640

_U  branches/1.8/
U   branches/1.8/res/res_musiconhold.c

------------------------------------------------------------------------
r285640 | bbryant | 2010-09-09 12:23:29 -0500 (Thu, 09 Sep 2010) | 21
lines

Merged revisions 285639 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
  r285639 | bbryant | 2010-09-09 13:22:25 -0400 (Thu, 09 Sep 2010) | 14
lines
  
  Merged revisions 285638 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r285638 | bbryant | 2010-09-09 13:20:17 -0400 (Thu, 09 Sep 2010) | 7
lines
    
    Fixes an issue with MOH where it doesn't recover cleanly when it can't
play a file and would just stop, instead of continuing to find the next
playable file in the MOH class.
    
    (closes issue https://issues.asterisk.org/view.php?id=17807)
    Reported by: kshumard
    
    Review: https://reviewboard.asterisk.org/r/910/
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=285640 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-09 12:23 svnbot         Checkin                                      
2010-09-09 12:23 svnbot         Note Added: 0126778                          
======================================================================




More information about the asterisk-bugs mailing list