to prevent concurrent access of the same mailstream. This, along with trunk's
ability to configure TCP timeouts for IMAP storage will help to prevent
crashes and hangs when using voicemail with IMAP storage.
(closes issue #10487)
Reported by: ewilhelmsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@111049 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
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
password stored in the in-memory list, too (otherwise it doesn't really take
effect).
(closes issue #11809)
Reported by: davetroy
Patches:
fix_externpass.diff uploaded by davetroy (license 384)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@99777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. Add locking to the vm_state retrieval functions so that no linked list corruption occurs.
2. Make sure to always grab the persistent vm_state when mailstream access is necessary.
3. Correct an incorrect return value in the init_mailstream function.
(closes issue #11304, reported by dwhite)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@97192 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of crashing if a user had more than 256 messages in their voicemail. This patch kills two birds with
one stone by adding maxmsg support and also setting a hard limit on the number of messages at 255 so
that the crashes cannot happen.
(closes issue #11101, reported by Skavin, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
provided. This was due to the fact that the answering channel did not have an extension
set, so ast_parseable_goto would fail. This fix eliminates the call to ast_parseable_goto
on the answering channel since it is a wasteful call. The answering channel and the calling
channel are both directed to the same extension and context, just different priorities, so
we can just copy the values from the calling channel to the answering channel and increment
the answering channel's priority.
(closes issue #11382, reported by jon, patch by me with correction by jon)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91273 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since greetings are not retrieved from IMAP anyway, it is pointless to attempt storing them there.
(closes issue #11359, reported by spditner, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89999 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes the problem, with a multi-faceted approach. First, we
do our best to avoid these messages from being created in the first place,
and second, if that fails, we detect when the voicemail message is
zero-length and avoid exiting at that point.
Reported by: dtyoo
Patch by: gkloepfer,tilghman
(Closes issue #11083)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89540 65c4cc65-6c06-0410-ace0-fbb531ad65f3
was fixed by running Asterisk under valgrind.
(closes issue #10746, reported by arcivanov, patched by me)
*** IMPORTANT NOTE: We need to check to see if this same bug exists elsewhere.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
from being reallocated every time the queue is accessed.
I also removed a debug message I had accidentally left in on a previous commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82274 65c4cc65-6c06-0410-ace0-fbb531ad65f3
