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
"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
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
for a caller to go out of turn if autofill were enabled and callers ahead in the queue were attempting
to call a member. This change fixes this.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@101216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
potentially spy on. However, if there were no matching channels, it would beep
at you over and over, which is pretty annoying. Now, it will only beep once in
the case that there are no channels to spy on, but it will still beep again once
it reaches the beginning of the channel list again.
(closes issue #11738, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@99923 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
if a user either removes or comments one of these options and reloads their queues, the
option will not reset to its default, instead maintaining the value from prior to the
reload.
Thanks to John Bigelow for pointing this error out to me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@98733 65c4cc65-6c06-0410-ace0-fbb531ad65f3
used (which also happen to be some the biggest/ugliest functions too) to document first. I'm pretty
new to doxygen so criticism is welcome.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@97304 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
