If a channel involved in a bridge was using SLIN audio, then translation
paths were not guaranteed to be set up properly since in all likelihood
the number of translation steps was only 1.
This patch enforces the transcode_via_slin behavior if transcode_via_slin
or generic_plc is enabled and one of the formats to make compatible is
SLIN.
AST-352
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@278618 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For SIP channels configured with the progressinband option on, the ringback was
being immediately stopped. This problem was due to ast_prod being moved for a
deadlock fix in 259858. Prodding the channel after setting up the generator
triggered the check in ast_write to stop the generator. The fix here should
write the frame the same as was done before the call to ast_prod was moved.
(closes issue #17372)
Reported by: tech_admin
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@275665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A recent check was added to ensure that we did not erroneously
detect duplicate DTMF when we received packets out of order.
The problem was that the check did not account for the fact that
the seqno of an RTP stream will roll over back to 0 after hitting
65535. Now, we have a secondary check that will ensure that the
seqno rolling over will not cause us to stop accepting DTMF.
(closes issue #17571)
Reported by: mdeneen
Patches:
rtp_seqno_rollover.patch uploaded by mmichelson (license 60)
Tested by: richardf, maxochoa, JJCinAZ
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@274157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If memory allocation fails in ast_strdup(), don't return a partially
initialized datastore. Bad things may happen.
(related to ABE-2415)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@273565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue here was that the frame created when adjusting for PLC had no offset
to its audio data. If this frame were translated to another format prior to
being sent out an RTP socket, all went well because the translation code would
put an appropriate offset into the frame. However, if the SLIN audio were not
translated before being sent out the RTP socket, bad things would happen.
Specifically, the ast_rtp_raw_write makes the assumption that the frame has
at least enough of an offset that it can accommodate an RTP header. This was
not the case. As such, data was being written prior to the allocation, likely
corrupting the data the memory allocator had written. Thus when the time came
to free the data, all hell broke loose. ....Well, Asterisk crashed at least.
The fix was just what one would expect. Offset the data in the frame by a reasonable
amount. The method I used is a bit odd since the data in the frame is 16 bit integers
and not bytes. I left a big ol' comment about it. This can be improved on if someone
is interested. I was more interested in getting the crash resolved.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This eliminates the annoying <beep> on the console.
(closes issue #17477)
Reported by: jvandal
Patches:
20100610__issue17477.diff.txt uploaded by tilghman (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269635 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the init script as-is currently, it could cause issues on Debian
such as high CPU usage. This fix has worked for several people so I'm
implementing the change. We now handle color displays properly.
(closes issue #16784)
Reported by: pabelanger
Patches:
20100530__issue16784__2.diff.txt uploaded by tilghman (license 14)
Tested by: pabelanger, tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Uses the VT100 method of clearing the line from the cursor position to the
end of the line: Esc-0K
(closes issue #17160)
Reported by: coolmig
Patches:
20100531__issue17160.diff.txt uploaded by tilghman (license 14)
Tested by: coolmig
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266585 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If you call signal() in a Solaris signal handler, instead of just resetting
the signal handler, it causes the signal to refire, because the signal is not
marked as handled prior to the signal handler being called. This effectively
causes Solaris to immediately exceed the threadstack in recursive signal
handlers and crash.
(closes issue #17000)
Reported by: rmcgilvr
Patches:
20100526__issue17000.diff.txt uploaded by tilghman (license 14)
Tested by: rmcgilvr
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266142 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r265320 | twilson | 2010-05-24 14:06:40 -0500 (Mon, 24 May 2010) | 14 lines
Add the FullyBooted AMI event
It is possible to connect to the manager interface before all Asterisk modules
are loaded. To ensure that an application does not send AMI actions that might
require a module that has not yet loaded, the application can listen for the
FullyBooted manager event. It will be sent upon connection if all modules have
been loaded, or as soon as loading is complete. The event:
Event: FullyBooted
Privilege: system,all
Status: Fully Booted
Review: https://reviewboard.asterisk.org/r/639/
........
r265467 | twilson | 2010-05-24 17:21:58 -0500 (Mon, 24 May 2010) | 1 line
Merge the rest of the FullyBooted patch
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@265570 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
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
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
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
