Reported by: arkadia
Tested by: murf, arkadia
Options added to forkCDR() app and the CDR() func to
remove some roadblocks for CDR applications.
The "show application ForkCDR" output was upgraded
to more fully explain the inner workings of forkCDR.
The A option was added to forkCDR to force the
CDR system to NOT change the disposition on the
original CDR, after the fork. This involves
ast_cdr_answer, _busy, _failed, and so on.
The T option was added to forkCDR to force
obedience of the cdr LOCKED flag in the
ast_cdr_end, all the disposition changing
funcs (ast_cdr_answer, etc), and in the
ast_cdr_setvar func.
The CHANGES file was updated to explain ALL
the new options added to satisfy this bug report
(and some requests made verbally and via
email, irc, etc, over the past months/year)
The 's' option was added to the CDR() func,
to force it to skip LOCKED cdr's in the
chain.
Again, the new options should be totally transparent
to existing apps! Current behavior of CDR,
forkCDR, and the rest of the CDR system should
not change one little bit. Until you add the
new options, at least!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@122046 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #11721)
(closes issue #12726)
Reported by: arkadia
Tested by: murf
These changes:
1. revert the changes made via bug 10668;
I should have known that such changes,
even tho they made sense at the time,
seemed like an omission, etc, were actually
integral to the CDR system via forkCDR.
It makes sense to me now that forkCDR didn't
natively end any CDR's, but rather depended
on natively closing them all at hangup time
via traversing and closing them all, whether
locked or not. I still don't completely
understand the benefits of setvar and answer
operating on locked cdrs, but I've seen
enough to revert those changes also, and
stop messing up users who depended on that
behavior. bug 12726 found reverting the changes
fixed his changes, and after a long review
and working on forkCDR, I can see why.
2. Apply the suggested enhancements proposed
in 10668, but in a completely compatible
way. ForkCDR will behave exactly as before,
but now has new options that will allow some
actions to be taken that will slightly
modify the outcome and side-effects of
forkCDR. Based on conversations I've had
with various people, these small tweaks
will allow some users to get the behavior
they need. For instance, users executing
forkCDR in an AGI script will find the
answer time set, and DISPOSITION set,
a situation not covered when the routines
were first written.
3. A small problem in the cdr serializer
would output answer and end times even
when they were not set. This is now
fixed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@118858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
own addressing system, the fix I made for issue 12376 does not guarantee
uniqueness to the datastores' uids. Though I know of no system that works
this way, I am going to change this right now to prevent trying to track
down some future bug that may occur and cause untold hours of debugging
time to track down.
The change involves using a global counter which increases with each new
chanspy_ds which is created. This guarantees uniqueness.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@118509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
it is possible that multiple spies may be listening to the same
channel.
(closes issue #12376)
Reported by: DougUDI
Patches:
12376_chanspy_uid.diff uploaded by putnopvut (license 60)
Tested by: destiny6628
(closes issue #12243)
Reported by: atis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@118365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a queue member. There was too much of an opportunity for the member
to hang up (either during a delay, announcement, or overly long
agi) between the time that he answered the phone and the time when
he actually was bridged with the caller. The consequence of this
was that if the member hung up in that interval, then proper
abandonment details would not be noted in the queue log if the caller
were to hang up at any point after the member hangup.
(closes issue #12561)
Reported by: ablackthorn
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and macroexten fields. This is needed because if macros are daisy-chained, the incorrect
context and extension are placed on the new channel. I also added locking to the channel prior
to accessing these variables as noted in trunk's janitor project file.
(closes issue #12549)
Reported by: darren1713
Patches:
app_queue.c.macroextenpatch uploaded by darren1713 (license 116)
(with modifications from me)
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114848 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also, remove setting the amount of time to wait for a digit from 5 seconds back
down to 1/10 of a second. I believe this was so the beep didn't get played over
and over really fast, but a while back I put in another fix for that issue.
(closes issue #12498)
Reported by: jsmith
Patches:
app_chanspy_channel_walk.trunk.patch uploaded by jsmith (license 15)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114597 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in the outer scope was never set properly, therefore making iterating through the channel
list always restart from the beginning. This bug would have affected anyone who called
chanspy without specifying a first argument.
(closes issue #12461)
Reported by: stever28
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114226 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Additionally, don't try to (re)set options when they have empty values in realtime (all unset columns would have an empty value).
(closes issue #12445)
Reported by: atis
Patches:
12445-autofill.diff uploaded by qwell (license 4)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
freeing the datastore here causes an eventual double free when the new channel
hangs up. We should only free the datastore if we were able to successfully remove
it from the channel we are referencing (i.e. the datastore was not moved).
(closes issue #12359)
Reported by: pguido
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114112 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
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
to prevent concurrent access of the same mailstream. This, along with trunk's
ability to configure TCP timeouts for IMAP storage will help to prevent
crashes and hangs when using voicemail with IMAP storage.
(closes issue #10487)
Reported by: ewilhelmsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@111049 65c4cc65-6c06-0410-ace0-fbb531ad65f3
code. This removes several problems people were seeing where their queue members would get into
an "unknown" state. Huge props go to atis on this one since he was the one who found the code
section that was causing the problem and proposed the solution. I just wrote what he suggested :)
(closes issue #12127)
Reported by: atis
Patches:
12127v3.patch uploaded by putnopvut (license 60)
Tested by: atis, jvandal
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@109713 65c4cc65-6c06-0410-ace0-fbb531ad65f3
datastore callback, called chan_fixup(). The concept is exactly like the
fixup callback that is used in the channel technology interface. This callback
gets called when the owning channel changes due to a masquerade. Before this
was introduced, if a masquerade happened on a channel being spyed on, the
channel pointer in the datastore became invalid.
(closes issue #12187)
(reported by, and lots of testing from atis)
(props to file for the help with ideas)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@108583 65c4cc65-6c06-0410-ace0-fbb531ad65f3
on the issue with mmichelson)
- Update copyright info on app_chanspy.
- Fix a race condition that caused app_chanspy to crash. The issue was that
the chanspy datastore magic that was used to ensure that spyee channels did
not disappear out from under the code did not completely solve the problem.
It was actually possible for chanspy to acquire a channel reference out of
its datastore to a channel that was in the middle of being destroyed. That
was because datastore destruction in ast_channel_free() was done near the
end. So, this left the code in app_chanspy accessing a channel that was
partially, or completely invalid because it was in the process of being free'd
by another thread. The following sort of shows the code path where the race
occurred:
=============================================================================
Thread 1 (PBX thread for spyee chan) || Thread 2 (chanspy)
--------------------------------------||-------------------------------------
ast_channel_free() ||
- remove channel from channel list ||
- lock/unlock the channel to ensure ||
that no references retrieved from ||
the channel list exist. ||
--------------------------------------||-------------------------------------
|| channel_spy()
- destroy some channel data || - Lock chanspy datastore
|| - Retrieve reference to channel
|| - lock channel
|| - Unlock chanspy datastore
--------------------------------------||-------------------------------------
- destroy channel datastores ||
- call chanspy datastore d'tor ||
which NULL's out the ds' || - Operate on the channel ...
reference to the channel ||
||
- free the channel ||
||
|| - unlock the channel
--------------------------------------||-------------------------------------
=============================================================================
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@108135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
