(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/branches/1.4@104593 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@104591 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@104332 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@104132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@104119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pointers to channels that are being spied upon. It was very likely that a
crash would occur if the channel being spied upon hung up. This was because
the current ast_channel handling _requires_ that the object is locked or else
it could disappear at any time (except in the owning channel thread). So, this
patch uses some channel datastore magic on the spied upon channel to be able to
detect if and when the channel goes away.
(closes issue #11877)
(patch written by me, but thanks to kpfleming for the idea, and to file for review)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
failed to lock don't sit around in the history. When a lock is first locked,
this checks to see if the last lock in the list was one that was failed to be
locked. If it is, then that was a lock that we're no longer sitting in a trylock
loop trying to lock, so just remove it.
(inspired by issue #11712)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104102 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Specifically, this fixes using #include and #exec in extconfig.conf.
This was basically caused because the config file itself raises the include level to 1.
I opted not to raise the include limit, because recursion here could cause very bizarre behavior.
Pointed out, and tested by jmls
(closes issue #12064)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
which event was received. What actually was happening was that it was reporting the number of bytes returned
from a call to read().
Thanks to Jared Smith for bringing the issue up on IRC
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104026 65c4cc65-6c06-0410-ace0-fbb531ad65f3
"dead" realtime queue. Since from the user's perspective, the queue
does exist, we shouldn't tell them we couldn't find the queue. Instead
since it is a dead queue, report a 0 waiting count
This issue was brought up on IRC by jmls
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103956 65c4cc65-6c06-0410-ace0-fbb531ad65f3
was created properly. Unfortunately this led to a segfault in the situation where an unknown format was
specified in voicemail.conf and a voicemail was recorded. Now, we first check to be sure that the stream
was written correctly or else assume a zero duration.
(closes issue #12021)
Reported by: jakep
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103786 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in bridge code. When that happens, we crash. Delay the RTP destruction until
the bridge is ended.
(closes issue #11960)
Reported by: norman
Patches:
20080215__bug11960__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: norman
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
could lead to a looped list, meaning it will traverse forever.
(closes issue #11818)
Reported by: michael-fig
Patches:
11818.patch uploaded by putnopvut (license 60)
Tested by: michael-fig
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AST_MODULE_LOAD_DECLINE, log a message indicating that the module is not fully
initialized and must be initialized using "module load".
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103728 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now if a directory is specified, then we will search that directory for
a source installation of the IMAP toolkit. If none is found, then we will
use that directory as the basis for detecting a package installation of
the IMAP c-client. If that check fails, then configure will fail.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now, if a source directory is specified with the --with-imap option, and a valid
source installation is not detected there, then configure will fail and will not
check for a package installation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk with IMAP support, you would use the --with-imap configure switch in one of the following
two ways:
--with-imap=/some/directory would look in the directory specified for a UW IMAP source installation
--with-imap would assume that you had imap-2004g installed in .. relative to the Asterisk source
With this set of changes the two above options still work the same, but there are two new behaviors, too.
--with-imap=system will assume that you have -libc-client.so where you store your shared objects and will
attempt to find c-client headers in your include path either in the imap or c-client directory.
If either of the two original methods of specifying the imap option should fail, then the check for --with-imap
=system will be performed in addition. It is only after this "system" check that failure can happen.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
