(from what the corresponding channel variables were set to)
when the agent logs out.
(closes issue #13098)
Reported by: davidw
Patches:
20080731__issue13098_agent_ackcall_not_reset.diff uploaded by bbryant (license 36)
Tested by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
buffers=<num of buffers>,<policy>
Where the number of buffers is some non-negative integer and the policy is either "full", "half", or "immediate".
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138938 65c4cc65-6c06-0410-ace0-fbb531ad65f3
lock to ensure that no other threads still have it locked. While
this should not happen under normal circumstances, it appears that
if the spyer and spyee hang up at nearly the same time, the following
may occur.
1. ast_channel_free is called on the spyee's channel.
2. The chanspy datastore is removed from the spyee's channel in
ast_channel_free.
3. In the spyer's thread, the spyer attempts to remove and destroy the datastore
from the spyee channel, but the datastore has already been removed in step 2,
so the spyer continues in the code.
4. The spyee's thread continues and calls the datastore's destroy callback,
chanspy_ds_destroy. This involves locking the chanspy_ds.
5. Now the spyer attempts to destroy the chanspy_ds lock. The problem is that in step 4,
the spyee has locked this lock, meaning that the spyer is attempting to destroy a lock
which is currently locked by another thread.
The backtrace provided in issue #12969 supports the idea that this is possible
(and has even occurred). This commit does not close the issue, but should help
in preventing one type of crash associated with the use of app_chanspy.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to timeouts from being strict to non-strict for more
accuracy.
(closes issue #13239)
Reported by: atis
Patches:
app_queue_timeouts_v2.patch uploaded by atis (license 242)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
properly deferred to be read from the channel owner when it gets taken out
of autoservice.
(closes issue #12874)
Reported by: dimas
Patches:
v1-12874.patch uploaded by dimas (license 88)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138027 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the existing channel name without the "Zap/" or "DAHDI/" prefix, since our
test string is also without that prefix.
(closes issue #13027)
Reported by: dferrer
Patches:
chan_zap-1.4.21.1_fix2.patch uploaded by dferrer (license 525)
(Slightly modified by me, to compensate for both names)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@137847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CDR(userfield) if it is set. The new behavior is to check for the userfield
column on module load, and if it exists, we will store CDR(userfield) when
CDRs are written. A similar patch already went into trunk and 1.6.0.
(closes issue #13290)
Reported by: falves11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@137348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: korihor
Wow, this one was a challenge!
I regrouped and ran a new strategy for
setting the ~~MACRO~~ value; I set it once
per extension, up near the top. It is only
set if there is a switch in the extension.
So, I had to put in a chunk of code to detect
a switch in the pval tree.
I moved the code to insert the set of ~~exten~~
up to the beginning of the gen_prios routine,
instead of down in the switch code.
I learned that I have to push the detection
of the switches down into the code, so everywhere
I create a new exten in gen_prios, I make sure
to pass onto it the values of the mother_exten
first, and the exten next.
I had to add a couple fields to the exten
struct to accomplish this, in the ael_structs.h
file. The checked field makes it so we don't
repeat the switch search if it's been done.
I also updated the regressions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@136726 65c4cc65-6c06-0410-ace0-fbb531ad65f3
release. Codec dahdi no longer functions with the transcoder interface in
zaptel at this time (which the last zaptel release was 1.4.11).
NOTE: Still needs an update to the configure script to make sure that
codec_dahdi is only built if the new transcoder interface is present in the
drivers.
(Issue: DAHDI-42)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@136544 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This allows vim :make functionality to work properly when errors have
occurred in the build. Without printing the directories, vim did not
know how to find the file that the error occurred in.
If the extra bit of build noise annoys anyone, just let me know, and
I'll make this optional.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@136168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
there are places where ast_rtp_new_source may be called
where the tech_pvt of a channel may not yet have an
rtp structure allocated. This caused a crash in chan_skinny,
which was fixed earlier, but now the same crash has been
reported against chan_h323 as well. It seems that the best
solution is to modify ast_rtp_new_source to not attempt to
set the marker bit if the rtp structure passed in is NULL.
This change to ast_rtp_new_source also allows the removal
of what is now a redundant pointer check from chan_skinny.
(closes issue #13247)
Reported by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@136062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
