app_followme which would occur at the end of an attended
transfer. The error occurred because we initially stored
a pointer to an ast_channel which then was hung up due
to a masquerade.
This commit adds a "fixup" callback to the bridge_config
structure to allow for end_bridge_callback_data to be
changed in the case that a new channel pointer is needed
for the end_bridge_callback.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@157305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@152535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
so that if packetization of audio is close (but not equal)
we don't end up flushing the audiohooks over small
inconsistencies in synchronization.
Related to issue #13005, and solves the issue
for most people who were experiencing the problem.
However, a small number of people are still experiencing
the problem on long calls, so I am not closing
the issue yet
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@149204 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- it is no longer necessary to forcibly include asterisk/autoconfig.h; every module already includes asterisk.h as its first header (even before system headers), which serves the same purpose
- astmm.h is now included by asterisk.h when needed, instead of being forced by the Makefile; this means external modules will build properly against installed headers with MALLOC_DEBUG enabled
- simplify the usage of some of these headers in the AEL-related stuff in the utils directory
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@144924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142675 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
The purpose of this branch was to take into account
"burps" which could cause jitterbuffers to misbehave.
One such example is if the L option to Dial() were used
to inject audio into a bridged conversation at regular
intervals. Since the audio here was not passed through
the jitterbuffer, it would cause a gap in the jitterbuffer's
timestamps which would cause a frames to be dropped for a
brief period.
Now ast_generic_bridge will empty and reset the jitterbuffer
each time it is called. This causes injected audio to be handled
properly.
ast_generic_bridge also will empty and reset the jitterbuffer
if it receives an AST_CONTROL_SRCUPDATE frame since the change
in audio source could negatively affect the jitterbuffer.
All of this was made possible by adding a new public API call
to the abstract_jb called ast_jb_empty_and_reset.
(closes issue #11259)
Reported by: plack
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@135841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@135799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_chanspy should be set at load time, not at compile
time, since dahdi_chan_name is determined at load time.
Also changed the next_unique_id_to_use to have the
static qualifier.
Also added the dahdi_chan_name_len variable so that
strlen(dahdi_chan_name) isn't necessary. Thanks to
seanbright for the suggestion.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@133169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
correct registration of AMI actions in chan_dahdi; in zap-only mode, only register the Zap flavors of the actions (and use Zap prefixes for headers and acks), but in dahdi+zap mode, register both Zap and DAHDI flavors of actions
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and b) completes contexts correctly when the extension is ambiguous.
(closes issue #12980)
Reported by: licedey
Patches:
20080703__bug12980.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@127973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #10927)
Reported by: murf
Tested by: murf, deeperror
(closes issue #12907)
Reported by: falves11
Tested by: murf, falves11
(closes issue #11849)
Reported by: greyvoip
As to 11849, I think these changes fix the core problems
brought up in that bug, but perhaps not the more global
problems created by the limitations of CDR's themselves
not being oriented around transfers.
Reopen if necc, but bug reports are not the best
medium for enhancement discussions. We need to start
a second-generation CDR standardization effort to cover
transfers.
(closes issue #11093)
Reported by: rossbeer
Tested by: greyvoip, murf
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@127663 65c4cc65-6c06-0410-ace0-fbb531ad65f3
macro. This caused the lock to not actually be released, and as a result, not
avoid deadlocks at all. This resolves the issues reported in the last while about
Asterisk locking up all over the place (and most commonly, in chan_iax2).
(closes issue #12927)
(closes issue #12940)
(closes issue #12925)
(potentially closes others ...)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@126573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
don't include tonezone.h in dahdi_compat.h, because only a couple of modules need it
get app_rpt building again after the DAHDI changes
(closes issue #12911)
Reported by: tzafrir
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@125132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
