the urgent messages are not in their own folder but are actually "flagged" messages
in the INBOX.
(closes issue #12659)
Reported by: jaroth
Patches:
urgentfolder_v2.patch uploaded by jaroth (license 50)
Tested by: jaroth
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@116594 f38db490-d61c-443f-a65b-d21fe96a405b
of platform/compiler-dependent warnings when handing
struct timeval fields, both reading and printing them.
It is a lost battle to handle the different ways struct timeval
is handled on the various platforms and compilers, so try
to be pragmatic and go through int/long which are universally
supported.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@116557 f38db490-d61c-443f-a65b-d21fe96a405b
press DTMF digits to switch between spying modes. Pressing 4 activates spy mode,
pressing 5 activates whisper mode, and pressing 6 activates barge mode. Use of
this feature overrides the normal operation of DTMF numbers.
This feature is courtesy of Switchvox.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@116522 f38db490-d61c-443f-a65b-d21fe96a405b
The behavior in 1.4 was that it would use the current context if an exitcontext existed.
(closes issue #12605)
Reported by: kenjreno
Patches:
12605-starexit.diff uploaded by qwell (license 4)
Tested by: file
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@116407 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r116088 | mmichelson | 2008-05-13 18:47:49 -0500 (Tue, 13 May 2008) | 12 lines
A change to the way channel locks are handled when DEBUG_CHANNEL_LOCKS is defined.
After debugging a deadlock, it was noticed that when DEBUG_CHANNEL_LOCKS
is enabled in menuselect, the actual origin of channel locks is obscured
by the fact that all channel locks appear to happen in the function
ast_channel_lock(). This code change redefines ast_channel_lock to be a
macro which maps to __ast_channel_lock(), which then relays the proper
file name, line number, and function name information to the core lock
functions so that this information will be displayed in the case that
there is some sort of locking error or core show locks is issued.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@116089 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r116038 | russell | 2008-05-13 16:17:23 -0500 (Tue, 13 May 2008) | 24 lines
Fix a deadlock involving channel autoservice and chan_local that was debugged
and fixed by mmichelson and me.
We observed a system that had a bunch of threads stuck in ast_autoservice_stop().
The reason these threads were waiting around is because this function waits to
ensure that the channel list in the autoservice thread gets rebuilt before the
stop() function returns. However, the autoservice thread was also locked, so
the autoservice channel list was never getting rebuilt.
The autoservice thread was stuck waiting for the channel lock on a local channel.
However, the local channel was locked by a thread that was stuck in the autoservice
stop function.
It turned out that the issue came down to the local_queue_frame() function in
chan_local. This function assumed that one of the channels passed in as an
argument was locked when called. However, that was not always the case. There
were multiple cases in which this channel was not locked when the function was
called. We fixed up chan_local to indicate to this function whether this channel
was locked or not. The previous assumption had caused local_queue_frame() to
improperly return with the channel locked, where it would then never get unlocked.
(closes issue #12584)
(related to issue #12603)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@116039 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r115990 | russell | 2008-05-13 16:05:57 -0500 (Tue, 13 May 2008) | 5 lines
Fix an issue that I noticed in autoservice while mmichelson and I were debugging
a different problem. I noticed that it was theoretically possible for two threads
to attempt to start the autoservice thread at the same time. This change makes the
process of starting the autoservice thread, thread-safe.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@116001 f38db490-d61c-443f-a65b-d21fe96a405b
Asterisk, and includes possible support (to be contributed) for various other
distributions.
(closes issue #10523)
Reported by: tzafrir
Patches:
install_prereq_2 uploaded by tzafrir (license 46)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@115813 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r115735 | mmichelson | 2008-05-12 12:51:14 -0500 (Mon, 12 May 2008) | 7 lines
If a thread holds no locks, do not print any information on the thread when issuing
a core show locks command. This will help to de-clutter output somewhat.
Russell said it would be fine to place this improvement in the 1.4 branch, so that's
why it's going here too.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@115737 f38db490-d61c-443f-a65b-d21fe96a405b
