[asterisk-dev] [Code Review] MeetMe MusicOnHold (M(class)) option doesn't respect class under certain conditions.

[Mark Michelson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1844/#review5933
-----------------------------------------------------------



/branches/1.8/apps/app_meetme.c
<https://reviewboard.asterisk.org/r/1844/#comment10885>

    Does this also need to be changed?


- Mark


On April 4, 2012, 9:48 a.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1844/
> -----------------------------------------------------------
> 
> (Updated April 4, 2012, 9:48 a.m.)
> 
> 
> Review request for Asterisk Developers, Mark Michelson and Matt Jordan.
> 
> 
> Summary
> -------
> 
> When starting MeetMe with M(<class_here>), MusicOnHold starts and then immediately stops with the proper class. It plays a chime and then it enters the code that was changed and starts MusicOnHold without respecting the requested MOH class (goes to default).
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/apps/app_meetme.c 361087 
> 
> Diff: https://reviewboard.asterisk.org/r/1844/diff
> 
> 
> Testing
> -------
> 
> I confirmed that this patch works with the following scenarios:
> 
> music on hold set to an alternate class eg. MeetMe(<confno>,M(exampleclass))
> The specified class is played when MOH starts up again.
> 
> music on hold set with no class specified eg. MeetMe(<confno>,M)
> Default MusicOnHold Class used
> 
> music on hold set to invalid class eg. MeetMe(<confno>,M(notlistedclass))
> Displays an error message saying music on hold class couldn't be found and uses the default instead.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120404/2f21b240/attachment.htm>