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
By setting the PRINT_DIR variable, SUBMAKE will print out the directories it
descends into, which is important for editors (like vim) that watch the build
output so that they can take you to the file where an error occurred.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@272688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Recent changes to chan_dahdi with relation to overlap dialing call
pri_grab without first obtaining a lock.
(closes issue #17414)
Reported by: pdf
Patches:
bug17414.patch uploaded by jpeeler (license 325)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@272446 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If MeetMe is configured to use dynamic conference
numbers, then the first caller (which creates the
conference) had to enter the PIN number twice.
(closes issue #15878)
Reported by: shawkris
Patches:
issue15878.patch uploaded by pabelanger (license 224)
Tested by: pabelanger
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@272255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to the recursion used when compiling AEL in gen_prios, all the stack space
was being consumed when parsing some AEL that contained nesting 13 levels deep.
Changing a few large buffers to be heap allocated fixed the crash, although I
did not test how many more levels can now be safely used.
(closes issue #16053)
Reported by: diLLec
Tested by: jpeeler
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@271399 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(This is a backport of 269307, committed to trunk by rmudgett.)
Calling dahdi_indicate() when the channel private lock is already
held can cause a deadlock if the PRI lock is needed because
dahdi_indicate() will also get the channel private lock. The pri_grab()
function assumes that the channel private lock is held once to avoid
deadlock.
(closes issue #17261)
Reported by: aragon
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@271335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
