https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105116 | russell | 2008-02-28 16:23:05 -0600 (Thu, 28 Feb 2008) | 8 lines
Fix a bug in the lock tracking code that was discovered by mmichelson. The issue
is that if the lock history array was full, then the functions to mark a lock as
acquired or not would adjust the stats for whatever lock is at the end of the array,
which may not be itself. So, do a sanity check to make sure that we're updating
lock info for the proper lock.
(This explains the bizarre stats on lock #63 in BE-396, thanks Mark!)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105059 | mmichelson | 2008-02-28 14:11:57 -0600 (Thu, 28 Feb 2008) | 6 lines
When using autofill, members who are in use should be counted towards the
number of available members to call if ringinuse is set to yes.
Thanks to jmls who brought this issue up on IRC
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105061 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104841 | mmichelson | 2008-02-27 15:49:20 -0600 (Wed, 27 Feb 2008) | 17 lines
Two fixes:
1. Make the list of ast_dial_channels a lockable list. This is because in some cases,
the ast_dial may exist in multiple threads due to asynchronous execution of its application, and
I found some cases where race conditions could exist.
2. Check in ast_dial_join to be sure that the channel still exists before attempting to lock it, since
it could have gotten hung up but the is_running_app flag on the ast_dial_channel may not have been
cleared yet.
(closes issue #12038)
Reported by: jvandal
Patches:
12038v2.patch uploaded by putnopvut (license 60)
Tested by: jvandal
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105005 | qwell | 2008-02-28 13:20:10 -0600 (Thu, 28 Feb 2008) | 9 lines
Make pbx_exec pass an empty string into applications, if we get NULL.
This protects against possible segfaults in applications that may try
to use data before checking length (ast_strdupa'ing it, for example)
(closes issue #12100)
Reported by: foxfire
Patches:
12100-nullappargs.diff uploaded by qwell (license 4)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104593 | kpfleming | 2008-02-27 10:53:06 -0600 (Wed, 27 Feb 2008) | 8 lines
fallback to standard English prompts properly when using new prompt directory layout
(closes issue #11831)
Reported by: IgorG
Patches:
fallbacken.v1.diff uploaded by IgorG (license 20) (modified by me to improve code and conform rest of function to coding guidelines)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104594 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r104591 | russell | 2008-02-27 10:45:00 -0600 (Wed, 27 Feb 2008) | 4 lines
When we receive a known alarm, make sure that the unknown alarm flag is not still
set to make sure that when we come back out of alarm, it gets reported in the log
and manager interface (after discussion with tzafrir on the -dev list)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
that if we keep this in the tree, it will be much easier to keep up to date.
The page on asterisk.org just links to this on svn.digium.com/view
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104419 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r104332 | russell | 2008-02-26 18:54:29 -0600 (Tue, 26 Feb 2008) | 5 lines
Zaptel 1.4 now exposes FXO battery state as an alarm. However, Asterisk 1.4
does not know what to do with these alarms. Only Asterisk 1.6 cares about it.
So, if we get an unknown alarm in chan_zap, don't generate confusing log messages
about it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
automatically generated file like it used to be. This still needs to be there
for modules that have to check it to compile against multiple asterisk versions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104132 | qwell | 2008-02-26 10:08:44 -0600 (Tue, 26 Feb 2008) | 9 lines
Fix a very bizarre issue we were seeing with our buildbot when using a DESTDIR that
wasn't an absolute path (such as DESTDIR=~/asterisk-1.4).
Apparently what was happening, was that some of the targets were being expanded to
the full path, so $@ ended up being /root/asterisk-1.4/[...]/ rather than ~/asterisk-1.4/[...]/
It appears that this may be a new "feature" in GNU make.
(*cough* http://en.wikipedia.org/wiki/Principle_of_least_surprise *cough*)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104119 | russell | 2008-02-25 18:25:29 -0600 (Mon, 25 Feb 2008) | 33 lines
Merge changes from team/russell/smdi-1.4
This commit brings in a significant set of changes to the SMDI support in Asterisk.
There were a number of bugs in the current implementation, most notably being that
it was very likely on busy systems to pop off the wrong message from the SMDI message
queue. So, this set of changes fixes the issues discovered as well as introducing
some new ways to use the SMDI support which are required to avoid the bugs with
grabbing the wrong message off of the queue.
This code introduces a new interface to SMDI, with two dialplan functions. First,
you get an SMDI message in the dialplan using SMDI_MSG_RETRIEVE() and then you access
details in the message using the SMDI_MSG() function. A side benefit of this is that
it now supports more than just chan_zap.
For example, with this implementation, you can have some FXO lines being terminated
on a SIP gateway, but the SMDI link in Asterisk.
Another issue with the current implementation is that it is quite common that the
station ID that comes in on the SMDI link is not necessarily the same as the Asterisk
voicemail box. There are now additional directives in the smdi.conf configuration
file which let you map SMDI station IDs to Asterisk voicemail boxes.
Yet another issue with the current SMDI support was related to MWI reporting over
the SMDI link. The current code could only report a MWI change when the change
was made by someone calling into voicemail. If the change was made by some other
entity (such as with IMAP storage, or with a web interface of some kind), then the
MWI change would never be sent. The SMDI module can now poll for MWI changes if
configured to do so.
This work was inspired by and primarily done for the University of Pennsylvania.
(also related to issue #9260)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Russell Bryant
Mark Michelson
Jason Parker
Tilghman Lesher
Joshua Colp
Kevin P. Fleming
Steve Murphy
Olle Johansson