The comparison function logic was off, so the number of sessions for a given
mailbox were not being incremented properly. This problem caused the maximum
number of messages per folder to not be respected when simultaneously leaving
multiple voicemails just below the threshold.
These problems should be fixed by the above, but just in case:
Fixed resequence_mailbox to rely on the actual number of detected number of
files in a directory rather than just assuming only 10 messages more than the
maximum had been left. Also if more messages than the maximum are deleted they
are actually removed now.
The second purpose of this commit should have been separated out probably, but
is related to the above. Again, if the number of messages in a given voicemail
folder exceeds the maximum set limit make sure to allocate enough space for the
deleted and heard index tracking array.
A few random fixes:
There was a forgotten decrement of the inprocess count in imap_store_file.
When using IMAP storage, do not look in the directory where file based storage
messages may still reside and influence the message count.
Ensure to use only the first format in sendmail.
ABE-2516
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@293004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a fix for when pressing the operator key after recording an unavailable,
busy, name, or temporary message in mailbox options. The operator key should not
be accepted here, but should be allowed during the message recording. If the
operator key is pressed during ensure the file is saved or deleted as
apporopriate. Also, ensure removal of temporary recorded files after an early
hang up or when message acceptance confirmation times out.
ABE-2518
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@292223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since the data being passed to the generator callback is on the stack of the
SMS() application, we must ensure that the generator is stopped before the
application exits.
ABE-2587
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@289424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the 'a' MeetMe flag and having a user and admin pin setup for your
conference, using the user pin would gain you admin priviledges. Also, when no
user pin was set, an admin pin was, the 'a' MeetMe flag wasn't used, and the
user tried to enter a conference then they were still prompted for a pin and
forced to hit #.
(closes issue #17908)
Reported by: kuj
Patches:
pins_2.patch uploaded by kuj (license 1111)
Tested by: kuj
Review: [full review board URL with trailing slash]
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@287758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Specifically, before prompting to record a prepended message the capacity is
checked first. If the mailbox is full the extension will be reprompted.
ABE-2517
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@286941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_fileexists returns -1 for error and 0 for a non-existant file. The existing
code treated missing files as though they were existed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@284881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_channel was created with one variable to ast_request() but the
call to ast_call() that initiates the outgoing call was using a different
variable. The two variables are not equivalent if the call_forward string
included a channel technology specifier. e.g., SIP/200
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@279206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using app_amd with SIP providers that have silence
suppression on, the iTotalTime count increases exponentially.
(closes issue #17656)
Reported by: juls
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@277182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Race conditions present in meetme involving the user list where a lack of
locking has the potential for a user to be removed during a traversal or as in
the case of the reporter after checking if the list is empty could cause a
crash. Fixing this was done by convering the userlist to an ao2 container.
(closes issue #17390)
Reported by: Vince
Review: https://reviewboard.asterisk.org/r/746/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@275773 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Configuring the conference in meetme.conf like the following:
conf => 2345,,6666
did not prompt for pin when used without admin mode. This meant that the
conference could not be joined as an admin even if the user knew the correct
pin. The original bug report was submitted claiming that the blank user pin
should deny entry into the conference. I think a better way to handle this
would be with a feature enhancement that used the following syntax:
conf => 2345,X,6666 - where X denotes no acceptable pin allowed
(closes issue #15704)
Reported by: modelnine
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@273474 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An outgoing channel placed in meetme while still ringing which was then hung up
would not exit meetme and the channel was not properly destroyed. Specifically
checking for this scenario by looking at the appropriate control frames resolves
the issue.
(closes issue #15871)
Reported by: Ivan
Patches:
meetme_congestion_trunk_v2.patch uploaded by Ivan (license 229)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@273354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If MeetMe is configured to use dynamic conference
numbers, then the first caller (which creates the
conference) had to enter the PIN number twice.
(closes issue #15878)
Reported by: shawkris
Patches:
issue15878.patch uploaded by pabelanger (license 224)
Tested by: pabelanger
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@272255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
At times, the "Member" field was not specified during the event.
It's there now.
(closes issue #15638)
Reported by: elbriga
Patches:
patchAppQueueAgentComplete.diff uploaded by elbriga (license 482)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This also fixes a documentation mistake in file.h that made my original attempt
to correct this problem not work correctly.
(closes issue #17061)
Reported by: RoadKill
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@265089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the case of accidentally entering the wrong first three letters for the
reading, users could be very frustrated if the name listing is very long. This
allows interrupting the reading by pressing 0 or #. 0 will attempt to execute
a configured operator (o) extension and # will exit and proceed in the
dialplan.
ABE-2200
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@263769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We attempted to detect silence after translating a frame
from signed linear. This caused a flooding of errors. To
resolve this the code to detect silence was moved before the
translation.
(closes issue #17133)
Reported by: jsdyer
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@262662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Or rather disallow the operator key from being accepted when not offered,
such as after finishing a recording from within the mailbox options menu.
ABE-2121
SWP-1267
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@261735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After finishing a recording from within the mailbox options menu, pressing 0
exhibited strange behavior with operator=yes turned on. Pressing 0 was not
even advertised as an option and the options from the vm-saveoper prompt:
"Press 1 to accept this recording. Otherwise, please continue to hold" did
not function correctly. While this of course could be fixed, it didn't really
seem to make sense even if it was working properly.
ABE-2121
SWP-1267
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@261698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There were two scenarios in the advanced options that while using the
operator=yes and review=yes options, the transfer occurred only after exiting
the main menu (after sending a reply or leaving a message for an extension).
Now after the audio is processed for the reply or message the transfer occurs
immediately as expected.
ABE-2107
ABE-2108
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@260923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Specifically, prompting for an extension (when leaving or forwarding a message)
or when prompting for a digit (when saving a message or changing folders).
ABE-2122
SWP-1268
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@258432 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a user's mailbox was full and a message was attempted to be forwarded to
said box, warnings on the console would indicate failure. However, the played
prompt was that of success (vm-msgsaved). Now storage failure is taken into
account and the correct prompt (vm-mailboxfull) is played when appropriate.
ABE-2123
SWP-1262
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@258029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mantis issue 17078 reports MixMonitor recordings have shorter durations than
the call duration. This was because the mixmonitor thread was not processing
frames from the audiohook fast enough. The mixmonitor thread would slowly fall
behind the most recent audio frame and when the channel hangs up, the mixmonitor
thread would exit without processing the same number of frames as the channel;
leaving the mixmonitor recording shorter than actual call duration.
This revision fixes this issue by moving the ast_audiohook_trigger_wait() and
the subsequent audiohook.status check into the block where the
ast_audiohook_read_frame() function returns NULL.
(closes issue #17078)
Reported by: geoff2010
Patches:
dw-M17078.patch uploaded by dhubbard (license 733)
Tested by: dhubbard, geoff2010
Review: https://reviewboard.asterisk.org/r/611/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@257686 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes an issue with certain Mail Transport Agents, where attachments are not
interpreted correctly.
(closes issue #16557)
Reported by: jcovert
Patches:
20100308__issue16557__1.4.diff.txt uploaded by tilghman (license 14)
20100308__issue16557__1.6.0.diff.txt uploaded by tilghman (license 14)
20100308__issue16557__trunk.diff.txt uploaded by tilghman (license 14)
Tested by: ebroad, zktech
Reviewboard: https://reviewboard.asterisk.org/r/544/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@255591 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when called from a ISDN channel, null frames prevent '#' exit.
Now only echo back VOICE and DTMF frames
(issue #16880)
Reported by: alecdavis
Patches:
based on echo_exit_1-6-1.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@249845 65c4cc65-6c06-0410-ace0-fbb531ad65f3
