https://origsvn.digium.com/svn/asterisk/trunk
........
r153181 | twilson | 2008-10-31 13:55:33 -0500 (Fri, 31 Oct 2008) | 5 lines
Recent CDR fixes moved execution of the 'h' exten into the bridging code, so variables that were set after ast_bridge_call was called would not show up in the 'h' exten. Added a callback function to handle setting variables, etc. from w/in the bridging code. Calls back into a nested function within the function calling ast_bridge_call
(closes issue #13793)
Reported by: greenfieldtech
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@153265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r147050 | seanbright | 2008-10-07 08:01:36 -0400 (Tue, 07 Oct 2008) | 8 lines
Make sure to compare the correct number of characters when special-casing
our DAHDI operator mode stuff. Technically, it would work fine, as 'DAH'
is currently unique amongst our channel technologies, but as Jared points
out:
<@jsmith> Sure... as long as the technology starts whith DAH.... but
it could be DAHDOO!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@147051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r142676 | murf | 2008-09-11 22:50:48 -0600 (Thu, 11 Sep 2008) | 40 lines
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
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.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142677 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r139627 | murf | 2008-08-22 16:03:13 -0600 (Fri, 22 Aug 2008) | 59 lines
Merged revisions 139347 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139347 | murf | 2008-08-21 17:03:50 -0600 (Thu, 21 Aug 2008) | 47 lines
(closes issue #13251)
Reported by: sergee
Tested by: murf
THis is a bold move for a static release fix, but I wouldn't have
made it if I didn't feel confident (at least a *bit* confident)
that it wouldn't mess everyone up.
The reasoning goes something like this:
1. We simply cannot do anything with CDR's at the current point
(in pbx.c, after the __ast_pbx_run loop). It's way too late to
have any affect on the CDRs. The CDR is already posted and gone,
and the remnants have been cleared.
2. I was very much afraid that moving the running of the 'h'
extension down into the bridge code (where it would be now
practical to do it), would result in a lot more calls to the
'h' exten, so I implemented it as another exten under another
name, but found, to my pleasant surprise, that there was a
1:1 correspondence to the running of the 'h' exten in the
pbx_run loop, and the new spot at the end of the bridge.
So, I ifdef'd out the current 'h' loop, and moved it into
the bridge code. The only difference I can see is the stuff
about the AST_PBX_KEEPALIVE, and hopefully, if this
is still an important decision point, I can replicate it
if there are complaints. To be perfectly honest,
the KEEPALIVE situation is not totally clear to me,
and how it relates to a post-bridge situation is less
clear. I suspect the users will point out everything
in total clarity if this steps on anyone's toes!
3. I temporarily swap the bridge_cdr into the channel
before running the 'h' exten, which makes it possible
for users to edit the cdr before it goes out the door.
And, of course, with the endbeforehexten config var set,
the users can also get at the billsec/duration vals.
After the h exten finishes, the cdr is swapped back
and processing continues as normal.
Please, all who deal with CDR's, please test this version
of Asterisk, and file bug reports as appropriate!
........
I also made a little fix to the app_dial's 'e' option,
that is related to my updates.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@139628 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r135821 | murf | 2008-08-05 17:45:32 -0600 (Tue, 05 Aug 2008) | 42 lines
Merged revisions 135799 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
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.6.0@135822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r130794 | mmichelson | 2008-07-14 12:54:11 -0500 (Mon, 14 Jul 2008) | 16 lines
Merged revisions 130792 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r130792 | mmichelson | 2008-07-14 12:50:21 -0500 (Mon, 14 Jul 2008) | 8 lines
Add a check to the CAN_EARLY_BRIDGE macro in app_dial to
be sure there are no audiohooks present on the channels
involved. This fixed a one-way audio situation I had in
my test setup. I couldn't find any open issues that suggested
one-way audio with regards to mixmonitor (or other audiohook)
usage, though.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r123165 | murf | 2008-06-16 14:43:46 -0600 (Mon, 16 Jun 2008) | 19 lines
(closes issue #12689)
Reported by: ys
Many thanks to ys for doing the research on this problem.
I didn't think it would be best to unlock the contexts
and then relock them after the remove_extension2() call,
so I added an extra arg to remove_extension2() and set it
appropriately in each call. There were not that many.
I considered forcing the code to lock the contexts before
the call to remove_extension2(), but that would require
a slightly greater degree of changes, especially since
the find_context_locked is local to pbx.c
I did a simple sanity test to make sure the code doesn't
mess things up in general.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@123173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114113 | mmichelson | 2008-04-14 11:25:09 -0500 (Mon, 14 Apr 2008) | 17 lines
Merged revisions 114112 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114112 | mmichelson | 2008-04-14 11:24:22 -0500 (Mon, 14 Apr 2008) | 9 lines
If the datastore has been moved to another channel due to a masquerade, then
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.6.0@114114 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91783 | russell | 2007-12-07 10:38:48 -0600 (Fri, 07 Dec 2007) | 6 lines
* Add channel locking around datastore operations that expect the channel
to be locked.
* Document why we don't record Local channels in the dialed interfaces list.
* Remove the dialed variable as it isn't needed.
* Restructure some code for clarity and coding guidelines stuff
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Event Dial has new headers, to comply with other events
- Source -> Channel Channel name (caller)
- SrcUniqueID -> UniqueID Uniqueid
(new) -> Dialstring Dialstring in app data
(moremanager)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91407 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91273 | mmichelson | 2007-12-05 16:35:52 -0600 (Wed, 05 Dec 2007) | 11 lines
The 'G' option for Dial() did not properly handle the case where only a label was
provided. This was due to the fact that the answering channel did not have an extension
set, so ast_parseable_goto would fail. This fix eliminates the call to ast_parseable_goto
on the answering channel since it is a wasteful call. The answering channel and the calling
channel are both directed to the same extension and context, just different priorities, so
we can just copy the values from the calling channel to the answering channel and increment
the answering channel's priority.
(closes issue #11382, reported by jon, patch by me with correction by jon)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91291 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This works in much the same way as the automonitor, except that instead of using the monitor
app, it uses the mixmonitor app. By providing an 'x' or 'X' as a dial or queue option, a DTMF
sequence may be entered (as defined in features.conf) to start the one-touch mixmonitor.
This patch also introduces some new API calls to the audiohooks code for searching for an audiohook
by type and for searching for a running audiohook by type.
Big thanks to joetester for writing the initial patch, testing it and patiently waiting for it to
be committed.
(closes issue #10185, reported and patched by xmarksthespot)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89622 | murf | 2007-11-26 23:24:02 -0700 (Mon, 26 Nov 2007) | 1 line
closes issue #11379; OK, this is an attempt to make both sides happy. To the cdr.conf file, I added the option 'unanswered', which defaults to 'no'. In this mode, you will see a cdr for a call, whether it was answered or not. The disposition will be NO ANSWER or ANSWERED, as appropriate. The src is as you'd expect, the destination channel will be one of the channels from the Dial() call, usually the last in the list if more than one chan was specified. With unanswered set to 'yes', you will still see this cdr entry in both cases. But in the case where the dial timed out, you will also see a cdr for each line attempted, marked NO ANSWER, with no destination channel name. The new option defaults to 'no', so you don't see the pesky extra cdr's by default, and you will not see the irritating 'not posted' messages.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
