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
answer during the specified timeout period. Prior to this change, there was a small chance
that the member name recorded in this case would be blank. Also prior to this change, if using
the ringall strategy, if no one answered the call during the specified timeout, the member name
listed in the queue log would randomly be one of the members that was rung.
(closes issue #11498, reported and tested by hloubser, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@95890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a queue uses the ringall strategy, it was possible through unfortunate coincidence for a single member at a given penalty level to
make app_queue think that all members at that penalty level were unavailable and cause the members at the
next penalty level to be rung. With this patch, we will only move to the next penalty level if ALL the members
at a given penalty level are unreachable.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@95095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
