These macros have been documented as legacy for a long time but are
still used in new code because they exist. Remove all references to:
* ao2_container_alloc_options
* ao2_t_container_alloc_options
* ao2_t_container_alloc
These macro's are also removed. Only ao2_container_alloc remains due to
it's use in over 100 places.
Change-Id: I1a26258b5bf3deb081aaeed11a0baa175c933c7a
* acl (named_acl.c)
* cdr
* cel
* ccss
* dnsmgr
* dsp
* enum
* extconfig (config.c)
* features
* http
* indications
* logger
* manager
* plc
* sounds
* udptl
These modules are now loaded at appropriate time by the module loader.
Unlike loadable modules these use AST_MODULE_LOAD_FAILURE on error so
the module loader will abort startup on failure of these modules.
Some of these modules are still initialized or shutdown from outside the
module loader. logger.c is initialized very early and shutdown very
late, manager.c is initialized by the module loader but is shutdown by
the Asterisk core (too much uses it without holding references).
Change-Id: I371a9a45064f20026c492623ea8062d02a1ab97f
When built-in components of Asterisk fail to start they cause the
Asterisk startup to abort. In these cases only the most critical
cleanup should be performed - closing databases and terminating
proceses. These cleanups are registered using ast_register_atexit, all
other cleanups should not be run during startup abort.
The main reason for this change is that these cleanup procedures are
untestable from the partially initialized states, if they fail it could
prevent us from ever running the critical cleanup with ast_run_atexits.
Create separate initialization for dns_core.c to be run unconditionally
during startup instead of being initialized by the first dns resolver to
be registered. This ensures that 'sched' is initialized before it can be
potentially used.
Replace ast_register_atexit with ast_register_cleanup in media_cache.c.
There is no reason for this cleanup to happen unconditionally.
Change-Id: Iecc2df98008b21509925ff16740bd5fa29527db3
Remove nearly all use of regex from ACO users. Still remaining:
* app_confbridge has a legitamate use of option name regex.
* ast_sorcery_object_fields_register is implemented with regex, all
callers use simple prefix based regex. I haven't decided the best
way to fix this in both 13/15 and master.
Change-Id: Ib5ed478218d8a661ace4d2eaaea98b59a897974b
The xferfailsound was read from the channel at the beginning of the transfer,
and that value is "cached" for the duration of the transfer. Therefore, changing
the xferfailsound on the channel using the FEATURE() dialplan function does
nothing once the transfer is under way.
This makes it so the transfer code instead gets the xferfailsound configuration
options from the channel when it is actually going to be used.
This patch also fixes a potential memory leak of the props object as well as
making sure the condition variable gets initialized before being destroyed.
ASTERISK-25696 #close
Change-Id: Ic726b0f54ef588bd9c9c67f4b0e4d787934f85e4
There are times when a configuration option should not have documentation.
1. Some options are registered with a particular object merely as a warning to
users. These options aren't even really 'deprecated' - which has its own
separate API call - they are actually provided by a different configuration
file. The options are merely registered so that the user gets a warning that
a different configuration file provides the item.
2. Some object types - most notably some used by modules that use sorcery - are
completely internal and should never be shown to the user.
3. Sorcery itself has several 'hidden' fields that should never be shown to a
user.
This patch updates the configuration framework and sorcery with additional API
calls that allow a module to register types as internal and options as not
requiring documentation. This bypasses the XML documentation checking.
This patch also re-enables the strict XML documentation checking in trunk, as
well as updates some documentation that was missing.
Review: https://reviewboard.asterisk.org/r/2785/
(closes issue ASTERISK-22359)
Reported by: Matt Jordan
(closes issue ASTERISK-22112)
Reported by: Rusty Newton
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This greatly modifies the operation of DTMF attended transfers so that
the full range of options from features.conf applies.
In addition, a new option has been added that allows for a transferer
to switch between bridges during a transfer before completing the
transfer.
(closes issue ASTERISK-21543)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2654
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395151 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In addition to porting those features, they now enjoy greater feature parity
with one another. Specifically, AutoMixMon now has a start and stop
message that can be specified with TOUCH_MIXMONITOR_MESSAGE_START and
TOUCH_MIXMONITOR_MESSAGE_STOP.
(closes issue ASTERISK-21553)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2620/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The options should not be registered multiple times. Instead, the configuration just needs
to be reprocessed by the config framework. This also exposed that we were not properly telling
the config framework to treat the configuration processing with the "reload" semantics when
a reload occurred. Both of these errors are fixed now.
Thanks to Richard Mudgett for discovering the leak.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
People who use the features.conf.sample file from Asterisk 11 and before in trunk were
given a rude awakening when features configuration changes were made. Because it uses the
config framework and the config framework is strict about what is accepted and what isn't,
people that had parking options configured found that Asterisk no longer started. This is
because parking options are currently handled in res_parking.conf instead of features.conf.
This fix seeks to create a temporary band-aid fix for the problem, but having parking options
from the general section be passed to a handler that will simply print that the option is no
longer supported. This will not cause Asterisk to exit.
The fix only applies to options in the general section. There are two main reasons for this:
1) The sample features.conf file only has parking options in the general section. There are no
configured parking lots. Therefore it's not quite as "urgent" to get the parking lot parsing
fixed.
2) The plan is to move parking configuration back from res_parking.conf to features.conf. When
that happens, the parking lots will also be addressed at that time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Change applicationmap and featuregroup to replace duplicate config items
rather than reject them.
* Remove some unneeded warning messages when getting the applicationmap
allows duplicates from DYNAMIC_FEATURES.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390803 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When reading from a config file, it's important to reject duplicates. Otherwise,
featuregroups will have ambiguity when pointing to applicationmap items. However,
when constructing the channel's current applicationmap, we don't care about duplicate
names since it's the DTMF that identifies a feature, not the name.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Features configuration is handled in its own API in
features_config.h and features_config.c. This way, features
configuration is accessible to anything that needs it.
In addition, features configuration has been altered to
be more channel-oriented. Most callers of features API
code will be supplying a channel so that the individual
channel's settings will be acquired rather than the global
setting.
Missing from this commit is XML documentation for the
features configuration. That will be handled in a separate
commit.
Review: https://reviewboard.asterisk.org/r/2578/
(issue ASTERISK-21542)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390751 65c4cc65-6c06-0410-ace0-fbb531ad65f3