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
From reviewboard
Background:
A Digium customer discovered a somewhat odd bug. The setup is that parties A
and B are bridged, and party A places party B on hold. While party B is
listening to hold music, he mashes a bunch of DTMF. Party A takes party
B off hold while this is happening, but party B continues to hear hold
music. I could reproduce this about 1 in 5 times.
The issue:
When DTMF features are enabled and a user presses keys, the channel that
the DTMF is streamed to is placed in an ast_safe_sleep for 100 ms, the
duration of the emulated tone. If an AST_CONTROL_UNHOLD frame is read
from the channel during the sleep, the frame is dropped. Thus the
unhold indication is never made to the channel that was originally placed
on hold.
The fix:
Originally, I discussed with Kevin possible ways of fixing the specific
problem reported. However, we determined that the same type of problem
could happen in other situations where ast_safe_sleep() is used. Using
autoservice as a model, I modified ast_safe_sleep_conditional() to
defer specific frame types so they can be re-queued once the sleep has
finished. I made a common function for determining if a frame should
be deferred so that there are not two identical switch blocks to
maintain.
Review: https://reviewboard.asterisk.org/r/674/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@264996 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Several callers of ast_callerid_parse() do not initialize the name
parameter before calling thus there is the potential to use an
uninitialized pointer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@264820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reason for ensuring DAHDI 2.3 or above is that this version ensures that
a timer is always available, whereas in previous versions, it was possible
for DAHDI to be loaded, but have no drivers to actually generate timing. If
internal_timing was turned on in this circumstance, a complete lack of audio
would result. This is the reason why internal_timing was not on by default.
However, now that DAHDI ensures the availability of a timer, there is no
reason for this setting to be off (and in fact, it solves a great many initial
user problems).
(closes issue #15932)
Reported by: dimas
Patches:
20100519__issue15932.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@264248 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
When using strsep, if one of the list of specified separators is not found,
it is the first parameter to strsep which is now NULL, not the pointer returned
by strsep.
This issue isn't especially severe in that the worst it is likely to do is waste
some cycles when a device with no '/' and no ':' is passed to ast_device_state.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@263639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Version field in the cookies we're setting contain quotes around the version
number which is not compatible with RFC2109 and breaks some implementations.
(closes issue #17231)
Reported by: ecarruda
Patches:
manager_rfc2109-trunk-v1.patch uploaded by ecarruda (license 559)
manager_rfc2109-1.6.2-v1.patch uploaded by ecarruda (license 559)
Tested by: ecarruda, russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@263456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The latest version of the core sounds files 1.4.19 now includes the missing
queue-minute sound file which is called by app_queue but which has been
missing.
(closes issue #17123)
Reported by: n8ideas
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@263374 65c4cc65-6c06-0410-ace0-fbb531ad65f3
dahdi_compat.h was not being included in channel.c when used with
Zaptel and wasn't in file.c at all.
(closes issue #15250)
Reported by: mneuhauser
Patches:
dahdi_compat.patch uploaded by mneuhauser (license 425)
Tested by: IgorG
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@263112 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
The sed syntax that was used wasn't actually valid, causing some versions to
choke. This is the method that is used in 1.6.x+ for similar changes.
(closes issue #16696)
Reported by: bklang
Patches:
16696-sedfix.diff uploaded by qwell (license 4)
Tested by: qwell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@262421 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
The needringing bit was being read in dahdi_read after answering thereby
setting the state to ringing from up. This clears needringing upon answering
so that is no longer possible.
(closes issue #17067)
Reported by: tzafrir
Patches:
needringing.diff uploaded by tzafrir (license 46)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@260434 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In res_musiconhold.c, there are several places where a channel's
stream's existence is checked prior to calling ast_closestream on it. The issue
here is that in several cases, the channel was not locked while checking the
stream. The result was that if two threads checked the state of the channel's
stream at approximately the same time, then there could be a situation where
both threads attempt to call ast_closestream on the channel's stream. The result
here is that the refcount for the stream would go below 0, resulting in a crash.
I have added proper channel locking to res_musiconhold.c to ensure that
we do not try to check chan->stream without the channel locked. A Digium customer
has been using this patch for several weeks and has not had any crashes since
applying the patch.
ABE-2147
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@260345 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code handling DTMF CallerID drops digits on long CallerID numbers and
may timeout waiting for the first ring with shorter numbers.
The DTMF emulation mode was not turned off when processing DTMF CallerID.
When the emulation code gets behind in processing the DTMF digits it can
skip a digit.
For shorter numbers, the timeout may have been too short. I increased it
from 2 seconds to 4 seconds. Four seconds is a typical time between rings
for many countries.
(closes issue #16460)
Reported by: sum
Patches:
issue16460.patch uploaded by rmudgett (license 664)
issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
Tested by: sum, rmudgett
Review: https://reviewboard.asterisk.org/r/634/
JIRA SWP-562
JIRA AST-334
JIRA SWP-901
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@260195 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The middle_frame in the audiohook_write_list function was
being freed if a audiohook manipulator returned a failure.
This is incorrect logic. This patch resolves this and
adds detailed descriptions of how this function should work
and why manipulator failures must be ignored.
(closes issue #17052)
Reported by: dvossel
Tested by: dvossel
(closes issue #16196)
Reported by: atis
Review: https://reviewboard.asterisk.org/r/623/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@260049 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Issue_1.
In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan,
and pvt->owner. Proper deadlock avoidance is done when the channel to hangup
is the outbound chan_local channel, but when it is not the outbound channel we
have an issue... We attempt to do deadlock avoidance only on the tech pvt, when
both the tech pvt and the pvt->owner are locked coming into that loop. By
never giving up the pvt->owner channel deadlock avoidance is not entirely possible.
This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt
when trying to get the pvt->chan lock.
Issue_2.
ast_prod() is used in ast_activate_generator() to queue a frame on the channel
and make the channel's read function get called. This function is used in
ast_activate_generator() while the channel is locked, which mean's the channel
will have a lock both from the generator code and the frame_queue code by the
time it gets to chan_local.c's local_queue_frame code... local_queue_frame
contains some of the same crazy deadlock avoidance that local_hangup requires,
and this recursive lock prevents that deadlock avoidance from happening correctly.
This patch removes ast_prod() from the channel lock so only one lock is held during
the local_queue_frame function.
(closes issue #17185)
Reported by: schmoozecom
Patches:
issue_17185_v1.diff uploaded by dvossel (license 671)
issue_17185_v2.diff uploaded by dvossel (license 671)
Tested by: schmoozecom, GameGamer43
Review: https://reviewboard.asterisk.org/r/631/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@259858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Updating config.guess because after installing Ubuntu Server 9.10 and
running all the update scripts, running ./configure would not continue
because it was unable to determine what kind of system I had. After
updating config.guess things started working again.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@259852 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Solaris `id` doesn't support the -u argument. Instead of figuring out how to
fix this to work on Solaris, I decided to check why it was necessary and where
else it was used. It was only used in one place, and it hasn't been needed
for a very long time (I question whether it was ever needed).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@259748 65c4cc65-6c06-0410-ace0-fbb531ad65f3
"WARNING[28406]: chan_dahdi.c:6873 ss_thread: CallerID feed failed: Success"
Changed the warning to "Failed to decode CallerID on channel 'name'". The
message before it is likely more specific about why the CallerID decode
failed.
SWP-501
AST-283
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@259531 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Add additional sounds prompts for say_enumeration
* Update the English conference sounds prompts so they are better
quality and all sound more consistent
* Clean up the core-sounds-XX.txt and extra-sounds-XX.txt files to
include all present sound files
Both core (en, fr, es) and extra (en, fr) sounds files have been updated.
(closes issue #16200)
Reported by: murf
(closes issue #17137)
Reported by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@259526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since AC_PATH_TOOL is equiv to AC_CHECK_TOOL when path isn't specified, and
AC_PATH_TOOLS doesn't exist, we'll just switch to AC_CHECK_TOOLS.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@259352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Issue #7321 implements a new chan_dahdi configuration option. However, a
change mentioned in the issue was never implemented. This is the change
that will allow the feature to work.
I added a note to chan_dahdi.conf.sample about the feature.
(closes issue #17143)
Reported by: djensen99
Patches:
diff.txt uploaded by djensen99 (license NA) (One line change)
Tested by: djensen99
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@259270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
No Newchannel manager event will be fired for channels that are
allocated to not match a registered technology type. Thus bogus
channels allocated solely for variable substitution or CDR
operations do not result in a Newchannel event.
(closes issue #16957)
Reported by: atis
Review: https://reviewboard.asterisk.org/r/601
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@259018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
Richard Mudgett
Matthew Nicholson
Tilghman Lesher
Alec L Davis
Jeff Peeler
Leif Madsen
David Vossel
Jason Parker
Paul Belanger
Tim Ringenbach