summaryrefslogtreecommitdiff
path: root/res/res_mwi_external.c
AgeCommit message (Collapse)Author
2018-01-24Remove redundant module checks and references.Corey Farrell
This removes references that are no longer needed due to automatic references created by module dependencies. In addition this removes most calls to ast_module_check as they were checking modules which are listed as dependencies. Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e
2016-10-27Remove ASTERISK_REGISTER_FILE.Corey Farrell
ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes all traces of it. Previously exported symbols removed: * __ast_register_file * __ast_unregister_file * ast_complete_source_filename This also removes the mtx_prof static variable that was declared when MTX_PROFILE was enabled. This variable was only used in lock.c so it is now initialized in that file only. ASTERISK-26480 #close Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
2016-01-04voicemail: Move app_voicemail / res_mwi_external conflict to runtimeGeorge Joseph
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
2015-04-13git migration: Refactor the ASTERISK_FILE_VERSION macroMatt Jordan
Git does not support the ability to replace a token with a version string during check-in. While it does have support for replacing a token on clone, this is somewhat sub-optimal: the token is replaced with the object hash, which is not particularly easy for human consumption. What's more, in practice, the source file version was often not terribly useful. Generally, when triaging bugs, the overall version of Asterisk is far more useful than an individual SVN version of a file. As a result, this patch removes Asterisk's support for showing source file versions. Specifically, it does the following: * Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and remove passing the version in with the macro. Other facilities than 'core show file version' make use of the file names, such as setting a debug level only on a specific file. As such, the act of registering source files with the Asterisk core still has use. The macro rename now reflects the new macro purpose. * main/asterisk: - Refactor the file_version structure to reflect that it no longer tracks a version field. - Remove the "core show file version" CLI command. Without the file version, it is no longer useful. - Remove the ast_file_version_find function. The file version is no longer tracked. - Rename ast_register_file_version/ast_unregister_file_version to ast_register_file/ast_unregister_file, respectively. * main/manager: Remove value from the Version key of the ModuleCheck Action. The actual key itself has not been removed, as doing so would absolutely constitute a backwards incompatible change. However, since the file version is no longer tracked, there is no need to attempt to include it in the Version key. * UPGRADE: Add notes for: - Modification to the ModuleCheck AMI Action - Removal of the "core show file version" CLI command Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
2014-07-25Add module support level to ast_module_info structure. Print it in CLI ↵Mark Michelson
"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
2014-04-02Prevent duplicate sorcery wizards from being applied to sorcery object types.Mark Michelson
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
2014-03-17Revert changes to sorcery that accidentally got committed.Mark Michelson
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
2014-03-17Fix stuck channel in ARI through the introduction of synchronous bridge actions.Mark Michelson
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
2014-03-14res_mwi_external: Clear the stasis cache entry when the external MWI is deleted.Richard Mudgett
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
2014-01-06External MWI core support.Richard Mudgett
* 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