diff options
author | murf <murf@f38db490-d61c-443f-a65b-d21fe96a405b> | 2008-08-05 23:13:20 +0000 |
---|---|---|
committer | murf <murf@f38db490-d61c-443f-a65b-d21fe96a405b> | 2008-08-05 23:13:20 +0000 |
commit | 5482dbc0430efc94e35c5ab9d7a58c0743efadf9 (patch) | |
tree | 28765ae88a2eb03202410c78cc1a40c281a9aa98 /main/cdr.c | |
parent | 0343c9913dc4dfc64567d5ec89e07a3602a767d6 (diff) |
(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: http://svn.digium.com/svn/asterisk/branches/1.4@135799 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'main/cdr.c')
-rw-r--r-- | main/cdr.c | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/main/cdr.c b/main/cdr.c index 3afe07aad..1df433c32 100644 --- a/main/cdr.c +++ b/main/cdr.c @@ -162,6 +162,11 @@ void ast_cdr_unregister(const char *name) AST_LIST_UNLOCK(&be_list); } +int ast_cdr_isset_unanswered(void) +{ + return unanswered; +} + /*! Duplicate a CDR record \returns Pointer to new CDR record */ |