Caller ID set on the channel before a masquerade occurs when using a local
channel would cause the information to be lost. The problem was that the
information was set on a channel destined to be hung up. The somewhat confusing
fix is to detect if any Caller ID has been set on the channel and if so
preswap the Caller ID data so that basically the masquerade puts the data back.
(closes issue #17138)
Reported by: kobaz
Review: https://reviewboard.asterisk.org/r/847/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@281390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is a scheduler item in chan_sip that keeps sending the
last provisional message in response to an INVITE Request for
a period of time until a final response to that INVITE is
sent. Because of the way this scheduler item works, it requires
a reference to a sip_pvt pointer to work properly. The problem
with this is that it is currently possible (but rare) for the
sip_pvt to get destroyed and that scheduler item to still
exist. When this occurs, the scheduler event fires and attempts
to access a freed sip_pvt which causes a crash.
(closes issue #17497)
Reported by: anonymouz666
Patches:
keepalive_diff_1.4_v2.diff uploaded by dvossel (license 671)
Review: https://reviewboard.asterisk.org/r/849/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@281185 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
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.4@279206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When you are using chan_dahdi ISDN signaling with immediate=yes and a call
comes in without a DNID then you get the DNID of a previous call.
Chan_dahdi does not touch the DNID field on a new call if it does not have
a DNID.
Made always copy the DNID from the new call.
The patches backport the relevant changes from trunk -r210387.
(closes issue #17568)
Reported by: wuwu
Patches:
issue17568_v1.4.patch uploaded by rmudgett (license 664)
issue17568_v1.6.2.patch uploaded by rmudgett (license 664)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@278701 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
A crash could occur if the extension is picked up while the parking extension is
being announced. Testing pu->notquiteyet while searching for a parked extension
resolves this crash.
(ABE-2418)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@277906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_bridge_call() clears AST_FLAG_BRIDGE_HANGUP_DONT. But during an attended
transfer, ast_bridge_call() is called for a second bridge on the same channel,
and it clears that flag, which still needs to get set for when the original
ast_bridge_call() gets control back and checks it.
Review: https://reviewboard.asterisk.org/r/741
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@277625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During a reload, the priexclusive and outsignalling parameters are not
read in from the config file as intended. Unfortunately, they get set to
defaults as a result. This patch makes sure that they do not get set to
defaults during a reload.
(closes issue #17441)
Reported by: mtryfoss
Patches:
issue17441_v1.4.patch uploaded by rmudgett (license 664)
issue17441_v1.6.2.patch uploaded by rmudgett (license 664)
issue17441_trunk.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@277419 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
At this point in the code, it is possible that peer_cdr may be invalid.
Specifically, in the blind transfer code, CDRs are swapped between channels.
So, peer_cdr is no longer == peer->cdr.
The scenario that exposed a crash in this code was a blind transfer that hit
the system call limit, causing the transferee channel to get destroyed after
the transfer attempt failed. Even if it succeeds and this code doesn't crash,
this code was still trying to reset a CDR on a channel that was now owned by
a different thread, which is a BadThing(tm).
(ABE-2417)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@275994 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
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
(closes issue #16102)
Reported by: Delvar
Patches:
say.conf.fix.patch uploaded by Delvar (license 908)
(plus a few additional fixes and simplifications by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@274417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
