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
We were passing a 'struct inprocess **' and treating it like a 'struct inprocess *'
causing a segfault.
(closes issue #16921)
Reported by: whardier
Patches:
20100301_issue16921.patch uploaded by seanbright (license 71)
Tested by: whardier
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@249671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@240414 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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 0016524)
Reported by: kobaz
(closes issue 0016523)
Reported by: kobaz
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/456/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@239718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Similar to changes made to Queue(), when we have large numbers of conferences in
meetme.conf (1000s) and we use alloca()/strdupa(), we can blow out the stack and
crash, so instead just use a single fixed buffer.
(closes issue #16509)
Reported by: Kashif Raza
Patches:
20091223_16509.patch uploaded by seanbright (license 71)
Tested by: seanbright
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@236509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch ensures that when a conference user is muted that the accompanying
AMI Meetme talking off event is sent. Also, the meetme list output is updated
to show the muted user as unmonitored.
(closes issue #16247)
Reported by: dimas
Patches:
v3-16247.patch uploaded by dimas (license 88)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@234379 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update the documentation in ChanSpy and ExtenSpy to reflect that only a
single group can be specified to the g() option.
(closes issue #16420)
Reported by: diatonic
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@234094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
