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
Asterisk has always set up a forwarded call when receiving a 482 Loop Detected.
This prevents handling the call failure by just continuing on in the dialplan.
Since this would be a change in behavior, the new option to disable this
behavior is forwardloopdetected which defaults to 'yes'.
Review: https://reviewboard.asterisk.org/r/764/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@274280 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
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
This value is purely informational. It does not alter configuration at all.
(closes issue #16029)
Reported by: Guggemand
Patches:
realtime-useragent.patch uploaded by Guggemand (license 897)
Tested by: Guggemand
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@273060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
