asterisk

Commit Graph

Author	SHA1	Message	Date
George Joseph	4ec85a9f07	voicemail: Move app_voicemail / res_mwi_external conflict to runtime The menuselect conflict between app_voicemail and res_mwi_external makes it hard to package 1 version of Asterisk. There no actual build dependencies between the 2 so moving this check to runtime seems like a better solution. The ast_vm_register and ast_vm_greeter_register functions in app.c were modified to return AST_MODULE_LOAD_DECLINE instead of -1 if there is already a voicemail module registered. The modules' load_module functions were then modified to return DECLINE instead of -1 to the loader. Since -1 is interpreted by the loader as AST_MODULE_LOAD_FAILURE, the modules were incorrectly causing Asterisk to stop so this needed to be cleaned up anyway. Now you can build both and use modules.conf to decide which voicemail implementation to load. The default menuselect options still build app_voicemail and not res_mwi_external but if both ARE built, res_mwi_external will load first and become the voicemail provider unless modules.conf rules prevent it. This is noted in CHANGES. Change-Id: I7d98d4e8a3b87b8df9e51c2608f0da6ddfb89247	10 years ago
Mark Michelson	dcf1ad14da	Add module support level to ast_module_info structure. Print it in CLI "module show" . ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	eefcb79bfb	Prevent duplicate sorcery wizards from being applied to sorcery object types. This commit contains several changes to sorcery: 1) Application of sorcery configuration based on module name is automatically performed when sorcery is opened for a module. 2) Sorcery will not attempt to apply the same wizard to an object type more than once. 3) Sorcery gives more exact results when attempting to apply a wizard, whether as the default or based on configuration. Sorcery unit tests still pass for me after making these changes. Review: https://reviewboard.asterisk.org/r/3326 ........ Merged revisions 411159 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411656 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	eba91d2a98	Revert changes to sorcery that accidentally got committed. These changes were still up for review and have not been approved yet. I must have had the changes in my working copy when making a different change. ........ Merged revisions 410696 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410699 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	d44aefeef4	Fix stuck channel in ARI through the introduction of synchronous bridge actions. Playing back a file to a channel in an ARI bridge would attempt to wait until the playback concluded before returning. The method used involved signaling the waiting thread in the ARI custom playback function. The problem with this is that there were some corner cases that were not accounted for: * If a bridge channel could not be found, then we never would attempt the playback but would still attempt to wait for the playback to complete. * If the bridge playfile action failed to queue, we would still attempt to wait for the playback to complete. * If the bridge playfile action were queued but some circumstance caused the playback not to occur (the bridge dies, the channel is removed from the bridge), then we would never be notified. The solution to this is to move the waiting logic into the bridge code. A new bridge API function is added to queue a synchronous action on a bridge. The waiting thread is notified when the queued frame has been freed, either due to an error occurring or due to successful playback. As a failsafe, the waiting thread has a 10 minute timeout just in case there is a frame leak somewhere. Review: https://reviewboard.asterisk.org/r/3338 ........ Merged revisions 410673 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410684 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	66718a06f7	res_mwi_external: Clear the stasis cache entry when the external MWI is deleted. One of the things missing when external MWI support was added was the ability to clear the stasis cache entry of deleted external MWI mailboxes. Review: https://reviewboard.asterisk.org/r/3325/ ........ Merged revisions 410555 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410557 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	9fa171e547	External MWI core support. * The core external MWI resource provides for MWI message counts persistence using sorcery. With sorcery, the user is able to configure which sorcery wizzard backend to use if the default astdb is not desired. * The core external MWI resoruce provides some debugging CLI commands enabled by defining MWI_DEBUG_CLI. The debugging CLI commands are: "mwi delete all", "mwi delete like <regex>", "mwi delete mailbox <mailbox>", "mwi list all", "mwi list like <regex>", "mwi show mailbox <mailbox>", and "mwi update mailbox <mailbox> [<new> [<old>]]". (closes issue AFS-43) Review: https://reviewboard.asterisk.org/r/3061/ ........ Merged revisions 404952 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404953 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago

7 Commits (a66fa4db24553d6ec6c8978c528081a94b1715a1)