(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.4@135799 65c4cc65-6c06-0410-ace0-fbb531ad65f3

include/asterisk/cdr.h

@@ -36,6 +36,7 @@
 #define AST_CDR_FLAG_ENABLE			(1 << 7)
 #define AST_CDR_FLAG_ANSLOCKED      (1 << 8)
 #define AST_CDR_FLAG_DONT_TOUCH     (1 << 9)
+#define AST_CDR_FLAG_DIALED         (1 << 10)
 
 /*! Disposition */
 #define AST_CDR_NULL                0
@@ -103,6 +104,7 @@ struct ast_cdr {
 	struct ast_cdr *next;
 };
 
+int ast_cdr_isset_unanswered(void);
 void ast_cdr_getvar(struct ast_cdr *cdr, const char *name, char **ret, char *workspace, int workspacelen, int recur, int raw);
 int ast_cdr_setvar(struct ast_cdr *cdr, const char *name, const char *value, int recur);
 int ast_cdr_serialize_variables(struct ast_cdr *cdr, char *buf, size_t size, char delim, char sep, int recur);