Billing records are fair,
To get paid is quite bright,
You should really use ODBC;
Good-bye cdr_sqlite.
Microsoft did once push H.323,
Hell, we all remember NetMeeting.
But try to compile chan_h323 now
And you will take quite a beating.
The XMPP and SIP war was fierce,
And in the distant fray
Was birthed res_jabber/chan_jingle;
But neither to stay.
For everyone did care and chase what Google professed.
"Free Internet Calling" was what devotees cried,
But Google did change the specs so often
That the developers were happy the day chan_gtalk died.
And then there was that odd application
Dedicated to the Polish tongue.
app_saycountpl was subsumed by Say;
One could say its bell was rung.
To read and parse a file from the dialplan
You could (I guess) use an application.
app_readfile did fill that purpose, but I think
A function is perhaps better in its creation.
Barging is rude, I'm not sure why we do it.
Inwardly, the caller will probably sigh.
But if you really must do it,
Don't use app_dahdibarge, use ChanSpy.
We all despise the sound of tinny robots
It makes our queues so cold.
To control such an abomination
It's better to not use Wait/SetMusicOnHold.
It's often nice to know properties of a channel
It makes our calls right
We have a nice function called CHANNEL
And so SIPCHANINFO is sent off into the night.
And now things get odd;
Apparently one could delimit with a colon
Properties from the SIPPEER function!
Commas are in; all others are done.
Finally, a word on pipes and commas.
We're sorry. We can't say it enough.
But those compatibility options in asterisk.conf;
To maintain them forever was just too tough.
This patch removes:
* cdr_sqlite
* chan_gtalk
* chan_jingle
* chan_h323
* res_jabber
* app_saycountpl
* app_readfile
* app_dahdibarge
It removes the following applications/functions:
* WaitMusicOnHold
* SetMusicOnHold
* SIPCHANINFO
It removes the colon delimiter from the SIPPEER function.
Finally, it also removes all compatibility options that were configurable from
asterisk.conf, as these all applied to compatibility with Asterisk 1.4 systems.
Review: https://reviewboard.asterisk.org/r/3698/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When support for a realtime sorcery module was added in revision 386731, the
wrong property was accidentally used for setting the column name to be updated
in the database table. This patch fixes the typo.
(closes issue ASTERISK-23177)
Reported by: Denis
Tested by: Denis
Patches:
asterisk-23177-use-field-name.diff by Michael L. Young (license 5026)
........
Merged revisions 406311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406312 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
on incoming h.323 calls. Option can be set globally or per user section.
(closes issue ASTERISK-22020)
Reported by: Ross Beer
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
........
Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.
Review: https://reviewboard.asterisk.org/r/2879
........
Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since ast_hangup() is effectively a channel destructor, it should be a
void function.
* Make the few silly callers checking the return value no longer do so.
Only the CDR and CEL unit tests checked the return value.
* Make all callers take advantage of the NULL safe change and remove the
NULL check before the call.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A stray ast_cdr_setvar was missed in cdr_mysql (silly addons). This has now
been refactored to not set the property, as the property would have been set
on a run-time object that was already dispatched to the backend. The module
simply remembers the value it wanted to set and writes it to MySQL later
in the processing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391964 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
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change does the following:
1. Adds the sorcery realtime module
2. Adds unit tests for the sorcery realtime module
3. Changes the realtime core to use an ast_variable list instead of variadic arguments
4. Changes all realtime drivers to accept an ast_variable list
Review: https://reviewboard.asterisk.org/r/2424/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When retrieving the parking lots from a MySQL database table, the current order
is "filename, cat_metric desc, var_metric asc, category". If there are multiple
parking lots with the same cat_metric but different categories, everything is
being sorted on cat_metric first resulting in errors when loading the parking
lots.
This patch fixes the problem by sorting on the category field first, then the
cat_metric field.
(closes issue ASTERISK-21035)
Reported by: Alex Epshteyn
Patches:
asterisk-21035-orderby.diff Michael L. Young (license 5026)
........
Merged revisions 382942 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 382943 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There were several problems using variadic argument macros in res_config_mysql.
* Improper use of va_end. Multiple calls to va_end were possible resulting in
an unbalanced matching of va_start/va_end.
* Calls to va_arg after a possible encounter of a SENTINEL value.
This patch corrects those errors.
(closes issue ASTERISK-19451)
Reported by: wdoekes
patches:
ASTERISK-19451-1.8--2.diff uploaded by wdoekes (License 5674)
........
Merged revisions 382021 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 382022 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382023 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per the bluez API, in order to bind to the first available port, the rc_channel
field of the socket addressing structure used to bind the socket should be set
to 0. Previously, Asterisk had set the rc_channel field set to 1, causing it
to connect to whatever happens to be on port 1.
We could probably not explicitly set rc_channel to 0 since we memset the struct
earlier, but explicitly setting it will hopefully prevent someone from coming
in and setting it to some explicit port in the future.
(closes issue ASTERISK-16357)
Reported by: challado
Tested by: Alexander Heinz, Nikolay Ilduganov, benjamin, eliafino, David van Geyn
patches:
ASTERISK-16357.diff uploaded by Nikolay Ilduganov (license 6253)
........
Merged revisions 379342 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379343 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The parser for SMS messages would incorrectly parse out the from number.
The parsing would incorrectly start scanning for the from number at the
same index as the first double quote ("); this would inadvertently cause
it to treat the first double quote as the terminating double quote for
the from number as well.
The SMSSRC should now populate correctly.
(closes issue ASTERISK-16822)
Reported by: menschentier
Tested by: Jonas Falck
patches:
fixSMSSRC.patch uploaded by jonax (license 6320)
(closes issue ASTERISK-19153)
Reported by: Panos Gkikakis
patches:
sms-sender-fix.diff uploaded by roeften (license 5884)
........
Merged revisions 379178 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379179 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From the patch author:
"First this patch adds general support for busy detection. It also adds support
for the ECAM command at Sony Ericsson phones and also signals busy when only
early media was received but the call got not answered."
Review: https://reviewboard.asterisk.org/r/323
(closes issue ASTERISK-14527)
Reported by: Artem Makhutov
Tested by: Artem Makhutov
patches:
busy-full5.patch uploaded by artem (license 5757)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When parsing arguments, application entry points should not attempt to
directly modify the parameters to the function. This patch properly duplicates
the passed in parameters before attempting to parse them.
(issue ASTERISK-20658)
Reported by: wdoekes
patches:
issueA20658_sanitize_app_mysql.patch uploaded by wdoekes (license 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Removed call to ast_module_user_hangup_all() in res_config_mysql.c since
it is effectively a noop. No channels can attach a reference to that
module.
* Removed call to ast_module_user_hangup_all() in app_celgenuserevent.c.
The caller of unload_module() has already called it.
* Removed redundant channel module references in pbx_dundi.c. The
registered dialplan function callback dispatchers for the read/read2/write
callbacks already reference the module before calling.
* pbx_dundi: Moved unregistering CLI commands, DUNDi switch, and dialplan
functions to the first thing the unload_module() does. This will reduce
the chance of new channels using DUNDi services while the module is being
torn down.
........
Merged revisions 376657 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376658 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 376659 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376660 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
This patch allows you to specify a port number for the MySQL server.
It's useful if a MySQL server is running on a non-standard port.
Even though this module is deprecated in favor of func_odbc, someone
asked for this feature and it seems pretty harmless to add.
It has been tested using a number of combinations of with/without a
port number specified in the dialplan and changing the port number
for mysqld.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370534 65c4cc65-6c06-0410-ace0-fbb531ad65f3