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
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.4@130792 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
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/branches/1.4@91783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@91273 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@90735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes it so that if there is no announce file specified, the application will continue until finished (or caller hangs up).
If a bogus announce file is specified, then a warning message will be printed saying that the file could not be found, but execution will
still continue.
(closes issue #10186, reported by jon, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75253 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r65172 | murf | 2007-05-18 14:56:20 -0600 (Fri, 18 May 2007) | 1 line
This update will fix the situation that occurs as described by 9717, where when several targets are specified for a dial, if any one them reports FAIL, the whole call gets FAIL, even though others were ringing OK. I rearranged the priorities, so that a new disposition, NULL, is at the lowest level, and the disposition get init'd to NULL. Then, next up is FAIL, and next up is BUSY, then NOANSWER, then ANSWERED. All the related set routines will only do so if the disposition value to be set to is greater than what's already there. This gives the intended effect. So, if all the targets are busy, you'd get BUSY for the call disposition. If all get BUSY, but one, and that one rings is not answered, you get NOANSWER. If by some freak of nature, the NULL value doesn't get overridden, then the disp2str routine will report NOANSWER as before.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@65200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
