https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r296000 | russell | 2010-11-24 10:48:39 -0600 (Wed, 24 Nov 2010) | 38 lines
Handle failures building translation paths more effectively.
The problem scenario occurred on a heavily loaded system that was using the
codec_dahdi module and exceeded the hardware transcoding capacity. The failure
mode at that point was not good. The report came in to us as an Asterisk
lock-up. The "core show locks" shows a ton of threads locked up (but no
obvious deadlock). Upon deeper investigation, when the system is in this
state, the CPU was maxed out. The CPU was being consumed by the Asterisk
logger spewing messages on every audio frame for calls set up after transcoder
capacity was reached.
The purpose of this patch is to make Asterisk handle failures to create a
translation path in a more graceful manner. If we can't translate, then the
call just needs to be dropped, as it's not going to work. These are the
changes:
1) In set_format() of channel.c (which is called by set_read_format() and
set_write_format()), it was ignoring if ast_translator_build_path() failed and
returned NULL. It now pays attention to that case and returns a result
reflecting failure. With this change in place, the bridging code will
immediately detect a failure and end the bridge instead of proceeding to try to
bridge frames that can't be translated and making channel drivers freak out by
sending them frames in a format they weren't expecting.
2) In ast_indicate_data() of channel.c, failure of ast_playtones_start() was
ignored. It is now reflected in the return value of the function. This didn't
turn out to have any affect on the bug, but seemed like a good change to leave
in.
3) In app_dial(), when only sending a call to a single endpoint, it will
attempt to do some bridging of its own of early audio. It uses
make_compatible() when it's going to do this. However, it ignored failure from
make compatible. So, even with the fix from #1, if there was early audio going
through app_dial, there would still be a period of invalid frames passing
through. After detecting failure here, Dial() exits.
ABE-2658
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@296001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.
Note that if the CLI command were done on the channel call leg associated
with B it works.
This regression was a result of the fix for issue #16946
(https://reviewboard.asterisk.org/r/740/).
The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.
The struct ast_channel._softhangup code is a mess. The variable is used
for several purposes that do not necessarily result in the call being hung
up. I have added doxygen comments to describe how the various _softhangup
bits are used. I have corrected all the places where the variable was
tested in a non-bit oriented manner.
The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.
JIRA SWP-2470
JIRA SWP-2489
(closes issue #18171)
Reported by: SantaFox
(closes issue #18185)
Reported by: kwemheuer
(closes issue #18211)
Reported by: zahir_koradia
(closes issue #18230)
Reported by: vmarrone
(closes issue #18299)
Reported by: mbrevda
(closes issue #18322)
Reported by: nerbos
Review: https://reviewboard.asterisk.org/r/1013/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@295843 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r294903 | jpeeler | 2010-11-12 14:49:09 -0600 (Fri, 12 Nov 2010) | 16 lines
Fix regression causing abort in voicemail after opening a mailbox with no mesgs.
In order to be more safe, some error handling code was changed to respect more
error conditions including the potential memory allocation failure for deleted
and heard message tracking introduced in 293004. However, last_message_index
returns -1 for zero messages (perhaps as expected) and was triggering the
stricter error checking. Because last_message_index is only called directly
in one place, just return 0 from open_mailbox (for file based storage) when no
messages are detected unless a real error has occurred.
(closes issue #18240)
Reported by: leobrown
Patches:
bug18240.1-6-2.diff.txt uploaded by alecdavis (license 585)
Tested by: pabelanger
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@294904 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r293004 | jpeeler | 2010-10-25 17:55:28 -0500 (Mon, 25 Oct 2010) | 29 lines
Fix inprocess_container in voicemail to correctly restrict max messages.
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.6.2@293118 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r292223 | jpeeler | 2010-10-18 16:50:30 -0500 (Mon, 18 Oct 2010) | 11 lines
Fix improper operator key acceptance and clean up temp recording files.
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.6.2@292226 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289873 | tilghman | 2010-10-01 23:42:08 -0500 (Fri, 01 Oct 2010) | 8 lines
When forwarding a message, a prepend means that the filesystem will always have a better copy.
(closes issue #17803)
Reported by: dpetersen
Patches:
20100923__issue17803.diff.txt uploaded by tilghman (license 14)
Tested by: dpetersen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@289874 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289424 | russell | 2010-09-30 10:34:29 -0500 (Thu, 30 Sep 2010) | 8 lines
Fix a crash in app_sms.
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.6.2@289425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r287758 | bbryant | 2010-09-20 19:57:08 -0400 (Mon, 20 Sep 2010) | 16 lines
Fix misvalidation of meetme pins in conjunction with the 'a' MeetMe flag.
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.6.2@287759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286941 | jpeeler | 2010-09-15 15:08:52 -0500 (Wed, 15 Sep 2010) | 7 lines
Ensure mailbox is not filled to capacity before doing message forwarding.
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.6.2@286998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) After we close FD, we should not be trying to write to it.
2) Call _exit(0), not exit(0), to avoid running shutdown routines in a child.
3) Use endian, not processor, detection to ensure bytes are written in the correct order.
(closes issue #15706)
Reported by: modelnine
Patches:
asterisk-1.6.1.1-festival-debug.patch uploaded by modelnine (license 865)
Tested by: gmartinez
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@284280 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r279206 | rmudgett | 2010-07-23 16:56:44 -0500 (Fri, 23 Jul 2010) | 7 lines
SIP promiscuous redirect could fail to dial the redirect.
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.6.2@279207 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r278463 | tilghman | 2010-07-21 10:56:05 -0500 (Wed, 21 Jul 2010) | 11 lines
Ensure realtime conferences are treated the same as static conferences when trying to find an empty one.
Also, parse the useropts properly, when retrieving from realtime, and add them
to the existing flags.
(closes issue #17502)
Reported by: kenji
Patches:
20100720__issue17502.diff.txt uploaded by tilghman (license 14)
Tested by: kenji
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@278464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r277488 | jpeeler | 2010-07-16 16:16:08 -0500 (Fri, 16 Jul 2010) | 10 lines
Fix reporting estimated queue hold time.
Just say the number of seconds (after minutes) rather than doing some incorrect
calculation with respect to minutes.
(closes issue #17498)
Reported by: corruptor
Patches:
holdesecs_bug.diff uploaded by corruptor (license 253)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@277489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r276074 | jpeeler | 2010-07-13 12:37:40 -0500 (Tue, 13 Jul 2010) | 19 lines
Merged revisions 275773 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275773 | jpeeler | 2010-07-12 15:34:51 -0500 (Mon, 12 Jul 2010) | 12 lines
Make user removals and traversals thread safe in meetme.
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.6.2@276121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r273522 | jpeeler | 2010-07-01 15:28:15 -0500 (Thu, 01 Jul 2010) | 21 lines
Merged revisions 273474 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r273474 | jpeeler | 2010-07-01 15:19:16 -0500 (Thu, 01 Jul 2010) | 14 lines
Allow admin user to join conference without using admin mode and no user pin.
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.6.2@273529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r273355 | jpeeler | 2010-07-01 10:12:31 -0500 (Thu, 01 Jul 2010) | 19 lines
Merged revisions 273354 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r273354 | jpeeler | 2010-07-01 10:05:43 -0500 (Thu, 01 Jul 2010) | 12 lines
Ensure channel placed in meetme in ringing state is properly hung up.
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.6.2@273356 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r272368 | mnicholson | 2010-06-23 17:36:49 -0500 (Wed, 23 Jun 2010) | 16 lines
Merged revisions 272367 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
This version of the patch only adds AgentComplete for attended transfers. It was already present for blind transfers.
........
r272367 | mnicholson | 2010-06-23 17:33:51 -0500 (Wed, 23 Jun 2010) | 8 lines
Send AgentComplete manager events in the event of blind and attended transfers.
(closes issue #16819)
Reported by: elbriga
Patches:
app_queue.diff uploaded by elbriga (license 482)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@272369 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r272257 | pabelanger | 2010-06-23 17:00:00 -0400 (Wed, 23 Jun 2010) | 19 lines
Merged revisions 272255 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r272255 | pabelanger | 2010-06-23 16:57:01 -0400 (Wed, 23 Jun 2010) | 12 lines
First caller into a dynamic conference now enter pin once.
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.6.2@272258 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r272109 | twilson | 2010-06-23 12:21:40 -0500 (Wed, 23 Jun 2010) | 12 lines
Make sure reload updates SLA config
Even if there are no stations or trunks defined, we need to start the sla
thread to make sure we get the reload event. Also, when doing a reload we need
to remove the existing trunks and stations or they end up hanging around.
(closes issue #16818)
Reported by: mbonin
Patches:
sla_reload.patch uploaded by twilson (license 396)
Tested by: twilson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@272124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
This review request is for the patch on issue 17081.
A user reported that he saw increasing numbers of allocations stemming
from app_queue.c when he would run the "queue show" CLI command. The
user reported that he was using approximately 40 realtime queues and
as he ran the CLI command more and more, the memory usage would shoot up.
As it turns out, there was a memory leak and a separate usage of memory
that, while not really a leak, was very irresponsible.
Both memory problems can be attributed to the function init_queue(). When
the "queue show" command is run, all realtime queues have the init_queue()
function called on the in-memory queue. The idea is to place the queue in
its default state and then overwrite options specified in the realtime backend
as we read them.
The first problem, the memory leak, had to do with the fact that the string
field for the name of the first periodic announcement file was being re-created
every time init_queue was called. This patch corrects the behavior by only
calling ast_str_create if the memory has not already been allocated.
The other problem is a bit more complicated. The majority of the strings
in the call_queue structure were changed to use the ast_string_fields API
for 1.6.0 and beyond. init_queue resets all string fields on the queue to
their default values. Then, later in the realtime queue loading process,
these string fields are set to their configured values.
For those unfamiliar with string fields, frequent resizing of a string like
this is not what the string fields API is designed for. The result of this
constant resizing is that as the queue gets loaded, eventually space for
the string runs out and so a new memory pool, at twice the size of the
previously allocated one, is created for the string fields. The reporter
of issue 17081 wrote a script that ran the "queue show" CLI command 2100
times. By the end, each of his 40 queues was taking about a megabyte of
memory apiece just for their string fields.
My fix for this problem is to revert the call_queue structure from using
string fields. In my patch here, I have moved the queue back to using
fixed-sized buffers. I ran the script provided by the reporter of 17081
and determined that I no longer saw the steadily-increasing memory usage
that I had seen before applying the patch.
(closes issue #17081)
Reported by: wliegel
Patches:
17081v2.patch uploaded by mmichelson (license 60)
Tested by: wliegel, mmichelson
Review: https://reviewboard.asterisk.org/r/651/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@265172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r265090 | mmichelson | 2010-05-21 16:08:51 -0500 (Fri, 21 May 2010) | 15 lines
Merged revisions 265089 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r265089 | mmichelson | 2010-05-21 15:59:14 -0500 (Fri, 21 May 2010) | 8 lines
Don't hang up on a queue caller if the file we attempt to play does not exist.
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.6.2@265091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r263807 | jpeeler | 2010-05-18 14:27:34 -0500 (Tue, 18 May 2010) | 17 lines
Merged revisions 263769 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r263769 | jpeeler | 2010-05-18 13:54:58 -0500 (Tue, 18 May 2010) | 10 lines
Modify directory name reading to be interrupted with operator or pound escape.
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.6.2@263809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r262744 | dvossel | 2010-05-12 13:01:20 -0500 (Wed, 12 May 2010) | 17 lines
Merged revisions 262662 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r262662 | dvossel | 2010-05-12 12:00:04 -0500 (Wed, 12 May 2010) | 11 lines
fixes app_meetme dsp error
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.6.2@262746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r261736 | jpeeler | 2010-05-06 15:11:53 -0500 (Thu, 06 May 2010) | 15 lines
Merged revisions 261735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r261735 | jpeeler | 2010-05-06 15:10:59 -0500 (Thu, 06 May 2010) | 8 lines
Only allow the operator key to be accepted after leaving a voicemail.
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.6.2@261739 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r260924 | jpeeler | 2010-05-04 13:51:28 -0500 (Tue, 04 May 2010) | 18 lines
Merged revisions 260923 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260923 | jpeeler | 2010-05-04 13:46:46 -0500 (Tue, 04 May 2010) | 12 lines
Voicemail transfer to operator should occur immediately, not after main menu.
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.6.2@260927 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r258433 | jpeeler | 2010-04-21 16:56:09 -0500 (Wed, 21 Apr 2010) | 15 lines
Merged revisions 258432 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r258432 | jpeeler | 2010-04-21 16:45:36 -0500 (Wed, 21 Apr 2010) | 8 lines
Fix looping forever when no input received in certain voicemail menu scenarios.
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.6.2@258436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r258065 | jpeeler | 2010-04-20 12:06:19 -0500 (Tue, 20 Apr 2010) | 17 lines
Merged revisions 258029 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r258029 | jpeeler | 2010-04-20 11:16:33 -0500 (Tue, 20 Apr 2010) | 11 lines
Play correct prompt when voicemail store failure occurs after attempted forward.
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.6.2@258108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r257713 | dhubbard | 2010-04-16 16:22:30 -0500 (Fri, 16 Apr 2010) | 28 lines
Merged revisions 257686 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257686 | dhubbard | 2010-04-16 16:15:43 -0500 (Fri, 16 Apr 2010) | 21 lines
Make the mixmonitor thread process audio frames faster
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.6.2@257740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r255592 | tilghman | 2010-03-31 14:13:02 -0500 (Wed, 31 Mar 2010) | 22 lines
Recorded merge of revisions 255591 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r255591 | tilghman | 2010-03-31 14:09:46 -0500 (Wed, 31 Mar 2010) | 15 lines
Ensure line terminators in email are consistent.
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.6.2@255676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r251877 | tilghman | 2010-03-11 14:25:02 -0600 (Thu, 11 Mar 2010) | 8 lines
If the argument to the system application is quoted, ensure we remove the quotes before trying to execute.
(closes issue #16842)
Reported by: ip-rob
Patches:
20100310__issue16842.diff.txt uploaded by tilghman (license 14)
Tested by: ip-rob
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@251879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r251680 | lmadsen | 2010-03-10 14:53:43 -0600 (Wed, 10 Mar 2010) | 10 lines
Be less ambiguous in Record() app docs.
For some reason the documentation for the 'k' application in trunk
and 1.6.2 is different than 1.6.0 and 1.6.1, so I'm setting them all
to match. The wording in 1.6.2 and trunk was ambiguous, so you could
interpret the wording the mean that recording would continue upon hangup
indefinitely, or you could interpret it to mean that the recorded
data would not be discarded upon hangup. This change makes it clear
we mean the latter, and not the former.
Came from a discussion in #asterisk on IRC.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@251683 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:
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.6.2@249844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r249187 | tilghman | 2010-02-26 12:41:57 -0600 (Fri, 26 Feb 2010) | 18 lines
Cleanups to fix bugs in the VM count API functions.
- Urgent voicemails were not attached, because the attachment code looked in the wrong folder.
- Urgent voicemails were sometimes counted twice when displaying the count of new messages.
- Backends were inconsistent as to which voicemails each API counted.
(closes issue #15654)
Reported by: tomo1657
Patches:
20100225__issue15654.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
(closes issue #16448)
Reported by: hevad
Review: https://reviewboard.asterisk.org/r/525/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@249190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r245680 | kpfleming | 2010-02-09 10:24:52 -0600 (Tue, 09 Feb 2010) | 8 lines
Don't offer MMR or JBIG transcoding during T.38 negotiation.
After further discussion with Steve Underwood, we should not (yet) be offering
to receive MMR or JBIG transcoded streams from T.38 endpoints. A future spandsp
release will support those features, and then they can be enabled during
negotiation
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@245683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r244393 | tilghman | 2010-02-02 14:32:29 -0600 (Tue, 02 Feb 2010) | 18 lines
Properly respect GOSUB_RESULT as to what to do with the master channel.
Previously, we would parse GOSUB_RESULT, but not actually do anything with it.
(closes issue #16686)
Reported by: bklang
Patches:
app_dial-respect-gosub_result.patch uploaded by bklang (license 919)
(with modifications)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@244395 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r240415 | tilghman | 2010-01-15 14:54:24 -0600 (Fri, 15 Jan 2010) | 22 lines
Merged revisions 240414 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r240414 | tilghman | 2010-01-15 14:52:27 -0600 (Fri, 15 Jan 2010) | 15 lines
Disallow leaving more than maxmsg voicemails.
This is a possibility because our previous method assumed that no messages are
left in parallel, which is not a safe assumption. Due to the vmu structure
duplication, it was necessary to track in-process messages via a separate
structure. If at some point, we switch vmu to an ao2-reference-counted
structure, which would eliminate the prior noted duplication of structures,
then we could incorporate this new in-process structure directly into vmu.
(closes issue #16271)
Reported by: sohosys
Patches:
20100108__issue16271.diff.txt uploaded by tilghman (license 14)
20100108__issue16271__trunk.diff.txt uploaded by tilghman (license 14)
20100108__issue16271__1.6.0.diff.txt uploaded by tilghman (license 14)
Tested by: jsutton
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@240418 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r239712 | dvossel | 2010-01-13 10:31:14 -0600 (Wed, 13 Jan 2010) | 24 lines
add silence gen to wait apps
asterisk.conf's 'transmit_silence' option existed before
this patch, but was limited to only generating silence
while recording and sending DTMF. Now enabling the
transmit_silence option generates silence during wait
times as well.
To achieve this, ast_safe_sleep has been modified to
generate silence anytime no other generators are present
and transmit_silence is enabled. Wait apps not using
ast_safe_sleep now generate silence when transmit_silence
is enabled as well.
(closes issue #16524)
Reported by: kobaz
(closes issue #16523)
Reported by: kobaz
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/456/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@239713 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Russell Bryant
Richard Mudgett
Jeff Peeler
Paul Belanger
David Vossel
Tilghman Lesher
Brett Bryant
Terry Wilson
Jean Galarneau
Sean Bright
Matthew Nicholson
Tzafrir Cohen
Mark Michelson
Dwayne M. Hubbard
Leif Madsen
Alec L Davis
Kevin P. Fleming