Age | Commit message (Collapse) | Author |
|
Change-Id: I873c1c6d00f447269bd841494459efccdd2c19c0
|
|
I guess nobody uses templates with AST_CONFIG because today if you have a
context that inherits from a template and you call AST_CONFIG on the context,
you'll get the value from the template even if you've overridden it in the
context. This is because AST_CONFIG only gets the first occurrence which is
always from the template.
This patch adds an optional 'index' parameter to AST_CONFIG which lets you
specify the exact occurrence to retrieve, or '-1' to retrieve the last.
The default behavior is the current behavior.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4313/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430315 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When you call the CONFIG dialplan function with the name of a variable that
doesn't exist in the target context you get an ERROR. This does nothing but
clutter up the logs with messages that may be perfectly acceptable. Just
because a variable wasn't in the context doesn't mean it's an error. Maybei
t's optional or just needs to be defaulted or ignored.
This patch changes the log level from ERROR to DEBUG. If a dialplan developer
wants to debug their dialplan they still canby setting the console debug level
as needed.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3919/
........
Merged revisions 421327 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 421328 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 421329 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The AST_CONFIG dialplan function defined in func_config.c allocates its
config file list entries using ast_malloc. List entry allocations
destined for use with Asterisk's linked list API must be ast_calloc()d
or otherwise initialized so that list pointers are set to NULL. These
uses of ast_malloc have been replaced by ast_calloc to prevent
dereferencing of uninitialized pointer values when traversing the list.
(closes issue ASTERISK-22483)
Reported by: Brian Scott
........
Merged revisions 400694 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400697 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 400701 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.10
................
r328247 | lmadsen | 2011-07-14 16:25:31 -0400 (Thu, 14 Jul 2011) | 14 lines
Merged revisions 328209 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r328209 | lmadsen | 2011-07-14 16:13:06 -0400 (Thu, 14 Jul 2011) | 6 lines
Introduce <support_level> tags in MODULEINFO.
This change introduces MODULEINFO into many modules in Asterisk in order to show
the community support level for those modules. This is used by changes committed
to menuselect by Russell Bryant recently (r917 in menuselect). More information about
the support level types and what they mean is available on the wiki at
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@328259 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This commit introduces the first phase of an effort to manage documentation of the
interfaces in Asterisk in an XML format. Currently, a new format is available for
applications and dialplan functions. A good number of conversions to the new format
are also included.
For more information, see the following message to asterisk-dev:
http://lists.digium.com/pipermail/asterisk-dev/2008-October/034968.html
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
when a file is invalid from when a file is missing. This is most important when
we have two configuration files. Consider the following example:
Old system:
sip.conf users.conf Old result New result
======== ========== ========== ==========
Missing Missing SIP doesn't load SIP doesn't load
Missing OK SIP doesn't load SIP doesn't load
Missing Invalid SIP doesn't load SIP doesn't load
OK Missing SIP loads SIP loads
OK OK SIP loads SIP loads
OK Invalid SIP loads incompletely SIP doesn't load
Invalid Missing SIP doesn't load SIP doesn't load
Invalid OK SIP doesn't load SIP doesn't load
Invalid Invalid SIP doesn't load SIP doesn't load
So in the case when users.conf doesn't load because there's a typo that
disrupts the syntax, we may only partially load users, instead of failing with
an error, which may cause some calls not to get processed. Worse yet, the old
system would do this with no indication that anything was even wrong.
(closes issue #10690)
Reported by: dtyoo
Patches:
20080716__bug10690.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142992 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #13176)
Reported by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
- Remove some magic in unload_module that isn't needed. Module use counts
already ensure that the function isn't going to be in use at this point.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
a variable from an Asterisk configuration file in the dialplan, or anywhere
else where dialplan functions can be used.
(Inspired by a discussion with Tilghman and Pari)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|