and a "core show channel" command. This patch adds locking
to prevent the resulting crash.
(closes issue #12155)
Reported by: tsearle
Patches:
show_channels_crash2.patch uploaded by tsearle (license 373)
Tested by: tsearle
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
during the initial INVITE, no matter if we're building the route set from
an INVITE request or response.
(closes issue #12391)
Reported by: benjaminbohlmann
Tested by: benjaminbohlmann
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113927 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is needed to correct the problem. Track whether the load succeeded with a
variable, so we can fix this with a simple reload event, instead.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113874 65c4cc65-6c06-0410-ace0-fbb531ad65f3
we should not send a BYE.
(closes issue #12392)
Reported by: fnordian
Patches:
chan_sip.patch uploaded by fnordian (license 110) with small modification from me
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
were specified when calling ParkAndAnnounce. This overflow is not exploitable remotely
and so there is no need for a security advisory.
(closes issue #12386)
Reported by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113507 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a for loop (in realtime_peer) to check all the ast_variables the loop was intending to test rather than just the first one. The change exposed the problem of calling memcpy on a NULL pointer, in this case the passed in sockaddr_in struct which is now checked.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
deadlock prevention in place in chan_local, but it would not work in a specific
case because the channel was recursively locked. By unlocking the channel prior
to calling the generator's generate callback in ast_read_generator_actions(), we
prevent the recursive locking, and therefore the deadlock.
(closes issue #12307)
Reported by: callguy
Patches:
12307.patch uploaded by putnopvut (license 60)
Tested by: callguy
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113065 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #12372)
Reported by: vinsik
Tested by: tecnoxarxa
This one line change makes an if inside a for loop (in realtime_peer) check all the ast_variables the loop was intending to test rather than just the first one.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113012 65c4cc65-6c06-0410-ace0-fbb531ad65f3
could be appended during a brief time when the manager is not waiting for input.
If an event comes during this period, we need to set an indicator that there is an
event pending so that the manager doesn't attempt to wait forever for an event that
already happened.
(closes issue #12354)
Reported by: bamby
Patches:
manager_race_condition.diff uploaded by bamby (license 430)
(comments added by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@112468 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #11243)
Reported by: whiskerp
Patches:
11243-maybe-asm.diff uploaded by qwell (license 4)
Tested by: Seggy (IRC)
Note: While I did write this patch, I would not have found this if fossil
had not reported and fixed issue #12253. A huge thanks to him for helping
to (indirectly) find the problem here.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@111856 65c4cc65-6c06-0410-ace0-fbb531ad65f3
asterisk-users, where a user was using Playback, but needed the
features of Background, and had no idea that Background existed,
or that it might provide the features he needed. I thought the
best way to avert these kinds of queries was to provide "See Also"
references in all three of "Background", "Playback", "WaitExten".
Perhaps a project to do this with all related apps is in order.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@111391 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: pj
Tested by: murf
These changes will set a channel variable ~~EXTEN~~ just before generating code
for a switch, with the value of ${EXTEN}. The exten is marked as having a switch,
and ever after that, till the end of the exten, we substitute any ${EXTEN}
with ${~~EXTEN~~} instead in application arguments; (and the ${EXTEN: also).
The reason for this, is that because switches are coded using
separate extensions to provide pattern matching, and
jumping to/from these switch extensions messes up the ${EXTEN} value,
which blows the minds of users.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@111341 65c4cc65-6c06-0410-ace0-fbb531ad65f3
after (about 200ms later) an "incorrectly" sized frame was received.
While it would be very nice to keep this as optimized as possible, it makes no sense
for the smoother to be dropping random bits of audio like this. Isn't that the
whole point of a smoother?
Closes issue #12093.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@111245 65c4cc65-6c06-0410-ace0-fbb531ad65f3
