Merged revisions 135799 via svnmerge from
authorSteve Murphy <murf@digium.com>
Tue, 5 Aug 2008 23:45:32 +0000 (23:45 +0000)
committerSteve Murphy <murf@digium.com>
Tue, 5 Aug 2008 23:45:32 +0000 (23:45 +0000)
commit5eaf8450d6e71d391e60e238195da5c0b69232e9
tree5cc17919fb6c8c46a38008cb1b2beafc9b98ccfe
parentde582e1eb2969dda036ed17f5567a317a20b2f92
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/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
apps/app_dial.c
include/asterisk/cdr.h
main/cdr.c
main/channel.c
main/features.c