This patch adds microsecond precision when inserting a CEL record into a table
with an "eventtime" column of type timestamp, instead of second precision. The
documentation (configs/cel_odbc.conf.sample) was already saying that the
eventtime column included microseconds precision, but that was not the case.
Also, without this patch, if you had a table with an "eventtime" column of
type varchar, you had millisecond precision. With this patch, you also get
microsecond precision in this case.
Review: https://reviewboard.asterisk.org/r/3980
ASTERISK-24283 #close
Reported by: Etienne Lessard
patches:
cel_odbc_time_precision.patch uploaded by Etienne Lessard (License 6394)
........
Merged revisions 427952 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 427953 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427954 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This gets rid of most old libc free/malloc/realloc and replaces them
with ast_free and friends. When compiling with MALLOC_DEBUG you'll
notice it when you're mistakenly using one of the libc variants. For
the legacy cases you can define WRAP_LIBC_MALLOC before including
asterisk.h.
Even better would be if the errors were also enabled when compiling
without MALLOC_DEBUG, but that's a slightly more invasive header
file change.
Those compiling addons/format_mp3 will need to rerun
./contrib/scripts/get_mp3_source.sh.
ASTERISK-24348 #related
Review: https://reviewboard.asterisk.org/r/4015/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for the PostgreSQL application_name connection setting.
When the appropriate PostgreSQL module's configuration is set with an
application name, the name will be passed to PostgreSQL on connection and
displayed in the database's pg_stat_activity view, as well as in CSV logs. This
aids in managing which applications/servers are connected to a PostgreSQL
database, as well as tracing the activity of those connections.
Review: https://reviewboard.asterisk.org/r/3591
ASTERISK-23737 #close
Reported by: Gergely Domodi
patches:
pgsql_application_name.patch uploaded by Gergely Domodi (License 6610)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses some aesthetic issues in Asterisk. These are all just
minor tweaks to improve the look of the CLI when used in a variety of
settings. Specifically:
* A number of chatty verbose messages were removed or demoted to DEBUG
messages. Verbose messages with a verbosity level of 5 or higher were -
if kept as verbose messages - demoted to level 4. Several messages
that were emitted at verbose level 3 were demoted to 4, as announcement
of dialplan applications being executed occur at level 3 (and so the
effects of those applications should generally be less).
* Some verbose messages that only appear when their respective 'debug'
options are enabled were bumped up to always be displayed.
* Prefix/timestamping of verbose messages were moved to the verboser
handlers. This was done to prevent duplication of prefixes when the
timestamp option (-T) is used with the CLI.
* Verbose magic is removed from messages before being emitted to
non-verboser handlers. This prevents the magic in multi-line verbose
messages (such as SIP debug traces or the output of DumpChan) from
being written to files.
* _Slightly_ better support for the "light background" option (-W) was
added. This includes using ast_term_quit in the output of XML
documentation help, as well as changing the "Asterisk Ready" prompt to
bright green on the default background (which stands a better chance of
being displayed properly than bright white).
Review: https://reviewboard.asterisk.org/r/3547/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Upon reload the module unconditionally "unloaded" the module (freeing memory
and setting pointers to NULL) and then when attempting a "load" if the config
file had not changed then nothing would be reinitialized.
By moving the "unload" to occur conditionally (reload only) after an attempted
configuration load, but before module "loading" alleviates the issue. The module
now loads/unloads/reloads correctly.
(closes issue ASTERISK-22871)
Reported by: Matteo
........
Merged revisions 404857 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 404858 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 404859 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404860 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A deadlock can happen between a thread unloading or reloading the cel_pgsql
module and the core_event_dispatcher taskprocessor thread. Description of
what is happening:
Thread 1 (for example, a netconsole thread):
a "module reload cel_pgsql" is launched
the thread enter the "my_unload_module" function (cel_pgsql.c)
the thread acquire the write lock on psql_columns
the thread enter the "ast_event_unsubscribe" function (event.c)
the thread try to acquire the write lock on ast_event_subs[sub->type]
Thread 2 (core_event_dispatcher taskprocessor thread):
the taskprocessor pop a CEL event
the thread enter the "handle_event" function (event.c)
the thread acquire the read lock on ast_event_subs[sub->type]
the thread callback the "pgsql_log" function (cel_pgsql.c), since it's a subscriber of CEL events
the thread try to acquire a read lock on psql_columns
(closes issue ASTERISK-22854)
Reported by: Etienne Lessard
Patches:
cel_pgsql_fix_deadlock_event.patch uploaded by hexanol (license 6394)
........
Merged revisions 404603 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 404604 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 404605 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the initial push to update Asterisk's CDR engine for the new
bridging framework. This patch guts the existing CDR engine and builds the new
on top of messages coming across Stasis. As changes in channel state and bridge
state are detected, CDRs are built and dispatched accordingly. This
fundamentally changes CDRs in a few ways.
(1) CDRs are now *very* reflective of the actual state of channels and bridges.
This means CDRs track well with what an actual channel is doing - which
is useful in transfer scenarios (which were previously difficult to pin
down). It does, however, mean that CDRs cannot be 'fooled'. Previous
behavior in Asterisk allowed for CDR applications, channels, and other
properties to be spoofed in parts of the code - this no longer works.
(2) CDRs have defined behavior in multi-party scenarios. This behavior will not
be what everyone wants, but it is a defined behavior and as such, it is
predictable.
(3) The CDR manipulation functions and applications have been overhauled. Major
changes have been made to ResetCDR and ForkCDR in particular. Many of the
options for these two applications no longer made any sense with the new
framework and the (slightly) more immutable nature of CDRs.
There are a plethora of other changes. For a full description of CDR behavior,
see the CDR specification on the Asterisk wiki.
(closes issue ASTERISK-21196)
Review: https://reviewboard.asterisk.org/r/2486/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update title that was left behind many years ago. Used revision 6596 as my guide for what it should be.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Whitespace, doc-blocks, spelling, case, missing and incorrect tags.
* Add cleanup to Makefile for the Doxygen configuration update
* Start updating Doxygen configuration for cleaner output
* Enable inclusion of configuration files into documentation
* remove mantisworkflow...
* update documentation README
* Add markup to Tilghman's email and talk with him about updating his email, he knows...
* no code changes on this commit other than the mentioned Makefile change
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Doxygen updates including mistakes, misspellings, missing parameters, updates for Doxygen style. Some missing txt file links are removed but their content or essense will be included in some later updates. A majority of the txt files were removed in the 1.6 era but never noted. The HR and EXTREF are simple changes that make the documentation more compatable with more versions of Doxygen.
Further updates coming.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
PQClear is not called when the result object of a call to PQExec has a
status of PGRES_COMMAND_OK. Interestingly enough, the off nominal case was
handled properly, so this memory leak only occurred when CEL records were
successfully written.
This patch properly clears the result in the nominal code path.
(closes issue ASTERISK-19991)
Reported by: Etienne Lessard
Tested by: Etienne Lessard
patches:
mem_leak_cel_pgsql.patch uploaded by Etienne Lessard (license #6394)
........
Merged revisions 372158 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 372165 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372175 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CEL eventtype field for ODBC and PGSQL backends should be USER_DEFINED
instead of the user defined event name supplied by the CELGenUserEvent
application. If the field is output as a number, the user defined name
does not have a value and is always output as 21 for USER_DEFINED and the
userdeftype field would be required to supply the user defined name.
The following CEL backends (cel_odbc, cel_pgsql, cel_custom, cel_manager,
and cel_sqlite3_custom) can be independently configured to remove this
inconsistency.
* Allows cel_manager, cel_custom, and cel_sqlite3_custom to behave the
same way.
(closes issue ASTERISK-17189)
Reported by: Bryant Zimmerman
Review: https://reviewboard.asterisk.org/r/1669/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@353648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Multiple revisions 350555,350571
........
r350555 | rmudgett | 2012-01-13 11:12:51 -0600 (Fri, 13 Jan 2012) | 12 lines
Add missing CEL logging fields to various CEL backends.
* Add missing eventextra to cel_psql.c and cel_odbc.c.
* Add missing PeerAccount and EventExtra to cel_manager.c.
* Add missing userdeftype support for cel_custom.conf.sample and
cel_sqlite3_custom.conf.sample.
(closes issue ASTERISK-17190)
Reported by: Bryant Zimmerman
........
r350571 | rmudgett | 2012-01-13 11:23:57 -0600 (Fri, 13 Jan 2012) | 8 lines
Use compatible names for event extra data for various CEL backends.
* Change eventextra to extra in cel_psql.c and cel_odbc.c.
* Change EventExtra to Extra in cel_manager.c.
(issue ASTERISK-17190)
........
Merged revisions 350555,350571 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 350585 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350605 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a table is created by some other application and the primary key is not
named "AcctId", cel/cel_sqlite3_custom.c will always try to create the
table and fail because it already exists.
* Change the SQL table query to not require AcctId as the primary key.
(closes issue ASTERISK-18963)
Reported by: socketpair
Patches:
fix.patch (license #6337) patch uploaded by socketpair
........
Merged revisions 349819 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 349820 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There were a number of issues in cel_pgsql's pgsql_log method:
* If either sql or sql2 could not be allocated, the method would return while
the pgsql_lock was still locked
* If the execution of the log statement succeeded, the sql and sql2 structs
were never free'd
* Reconnection successes were logged as ERRORs. In general, the severity of
several logging statements was reduced
(closes issue ASTERISK-18879)
Reported by: Niolas Bouliane
Tested by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1624/
........
Merged revisions 348888 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 348889 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@348890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r337974 | rmudgett | 2011-09-26 14:35:23 -0500 (Mon, 26 Sep 2011) | 37 lines
Merged revisions 337973 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r337973 | rmudgett | 2011-09-26 14:30:39 -0500 (Mon, 26 Sep 2011) | 30 lines
Fix deadlock when using dummy channels.
Dummy channels created by ast_dummy_channel_alloc() should be destoyed by
ast_channel_unref(). Using ast_channel_release() needlessly grabs the
channel container lock and can cause a deadlock as a result.
* Analyzed use of ast_dummy_channel_alloc() and made use
ast_channel_unref() when done with the dummy channel. (Primary reason for
the reported deadlock.)
* Made app_dial.c:dial_exec_full() not call ast_call() holding any channel
locks. Chan_local could not perform deadlock avoidance correctly.
(Potential deadlock exposed by this issue. Secondary reason for the
reported deadlock since the held lock was part of the deadlock chain.)
* Fixed some uses of ast_dummy_channel_alloc() not checking the returned
channel pointer for failure.
* Fixed some potential chan=NULL pointer usage in func_odbc.c. Protected
by testing the bogus_chan value.
* Fixed needlessly clearing a 1024 char auto array when setting the first
char to zero is enough in manager.c:action_getvar().
(closes issue ASTERISK-18613)
Reported by: Thomas Arimont
Patches:
jira_asterisk_18613_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Thomas Arimont
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r321926 | rmudgett | 2011-06-03 17:09:36 -0500 (Fri, 03 Jun 2011) | 18 lines
Asterisk crash when unloading cdr_radius/cel_radius.
The rc_openlog() API call is passed a string that is used by openlog() to
format log messages. The openlog() does not copy the string it just keeps
a pointer to it. When the module is unloaded, the string is gone from
memory. Depending upon module load order and if the other module then has
an error, a crash happens.
* Pass rc_openlog() a strdup'd string with the understanding that there
will be a small memory leak if the cdr_radius/cel_radius modules are
unloaded.
* Call rc_destroy() to free the rc handle memory when the module is
unloaded.
JIRA AST-483
JIRA SWP-3062
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@321927 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Change the documented pgsql schema to use "timestamp" instead of "time",
as the latter is only a time without a date.
Added some missing columns for cel's pgsql schema, and corrected spelling
on some others. Updated cel's uniqueid size to be the same as the cdr.
Added id column to cel's pgsql schema and updated code to allow unknown
columns to get their default value instead of forcing 0 or empty string.
Added microseconds to the timestamp cel logs to pgsql.
Review: https://reviewboard.asterisk.org/r/734
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276349 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CEL is the new system for logging channel events. This was inspired after
facing many problems trying to represent what is possible to happen to a call
in Asterisk using CDR records. For more information on CEL, see the built in
HTML or PDF documentation generated from the files in doc/tex/.
Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
work developing this code. Also, thanks to Matt Nicholson (mnicholson) and
Sean Bright (seanbright) for their assistance in the final push to get this
code ready for Asterisk trunk.
Review: https://reviewboard.asterisk.org/r/239/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3