Masquerading a channel means that the src of the audio is potentially
changing, so send a SRCCHANGE so that RTP-based media streams can get
a new SSRC generated to reflect the change. Original patch by addix
(along with lots of testing--thanks!).
(closes issue #17007)
Reported by: addix
Patches:
1001-reset-SSRC-original-channel.diff uploaded by addix (license 1006)
srcchange.diff uploaded by twilson (license 396)
Tested by: addix, twilson
Review: https://reviewboard.asterisk.org/r/862/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@282430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change causes the SSRC to change right before the channels are bridged,
which is what used to happen. It seems that fixes were made to attempt limiting
SSRC changes, targeted mainly at sending DTMF. DTMF is not affecting the SSRC
with this change.
There are two other control frames sent in ast_channel_bridge that probably
should also be changed to AST_CONTROL_SRCCHANGE as well, but I'm going to leave
this change up to the discretion of resolving issue #17007.
For reference - old review implementing new control frame SRCCHANGE:
https://reviewboard.asterisk.org/r/540
(closes issue #17404)
Reported by: sdolloff
Patches:
bug17404.patch uploaded by jpeeler (license 325)
Tested by: sdolloff
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@281911 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A translator frame even if it local storage so the translation path
can be freed. This issue prevented g729 licenses from being freed up.
(closes issue #17630)
Reported by: manvirr
Patches:
encoder_fix.diff uploaded by dvossel (license 671)
Tested by: manvirr, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@280448 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a channel has an audiohook write list created on it, that
list stays on the channel until the channel is destroyed. There
is no reason to keep that list on the channel if it becomes empty.
If it is empty that just means we are doing needless translating
for every ast_read and ast_write. This patch removes the audiohook
list from the channel once it is detected to be empty on either a
read or write. If a audiohook is added back to the channel after
this list is destroyed, the list just gets recreated as if it never
existed to begin with.
(closes issue #17630)
Reported by: manvirr
Review: https://reviewboard.asterisk.org/r/799/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@279945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
