CDRs: fix a variety of dial status problems, h/hangup handler creating CDRs

This patch fixes a number of small-ish problems that were noticed when
witnessing the records that the FreePBX dialplan produces:
(1) Mid-call events (as well as privacy options) have the ability to change the
    overall state of the Dial operation after the called party answers. This
    means that publishing the DialEnd event when the called party is premature;
    we have to wait for the execution of these subroutines to complete before
    we can signal the overall status of the DialEnd. This patch moves that
    publication and adds handlers for the mid-call events.
(2) The AST_FLAG_OUTGOING channel flag is cleared if an after bridge goto
    datastore is detected. This flag was preventing CDRs from being recorded
    for all outbound channels that had a 'continue' option enabled on them by
    the Dial application.
(3) The CDR engine now locks the 'Dial' application as being the CDR
    application if it detects that the current CDR has entered that app. This
    is similar to the logic that is done for Parking. In general, if we entered
    into Dial, then we want that CDR to record the application as such - this
    prevents pre-dial handlers, mid-call handlers, and other shenaniganry
    from changing the application value.
(4) The CDR engine now checks for the AST_SOFTHANGUP_HANGUP_EXEC in more places
    to determine if the channel is in hangup logic or dead. In either case, we
    don't want to record changes in the channel.
(5) The default option for "endbeforehexten" has been changed to "yes". In
    general, you don't want to see CDRs in the 'h' exten or in hangup logic.
    Since the semantics of that option changed in 12, it made sense to update
    the default value as well.
(6) Finally, because we now have the ability to synchronize on the messages
    published to the CDR topic, on shutdown the CDR engine will now synchronize
    to the messages currently in flight. This helps to ensure that all
    in-flight CDRs are written before shutting down.

(closes issue ASTERISK-23164)
Reported by: Matt Jordan

Review: https://reviewboard.asterisk.org/r/3154
........

Merged revisions 407084 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407085 65c4cc65-6c06-0410-ace0-fbb531ad65f3

1 files changed, 32 insertions, 6 deletions

diff --git a/main/manager_channels.c b/main/manager_channels.c
index 0bebb216c..3fdcc9654 100644
--- a/main/manager_channels.c
+++ b/main/manager_channels.c
@@ -151,12 +151,38 @@ ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
 				<parameter name="DialStatus">
 					<para>The result of the dial operation.</para>
 					<enumlist>
-						<enum name="ANSWER" />
-						<enum name="BUSY" />
-						<enum name="CANCEL" />
-						<enum name="CHANUNAVAIL" />
-						<enum name="CONGESTION" />
-						<enum name="NOANSWER" />
+						<enum name="ABORT">
+							<para>The call was aborted.</para>
+						</enum>
+						<enum name="ANSWER">
+							<para>The caller answered.</para>
+						</enum>
+						<enum name="BUSY">
+							<para>The caller was busy.</para>
+						</enum>
+						<enum name="CANCEL">
+							<para>The caller cancelled the call.</para>
+						</enum>
+						<enum name="CHANUNAVAIL">
+							<para>The requested channel is unavailable.</para>
+						</enum>
+						<enum name="CONGESTION">
+							<para>The called party is congested.</para>
+						</enum>
+						<enum name="CONTINUE">
+							<para>The dial completed, but the caller elected
+							to continue in the dialplan.</para>
+						</enum>
+						<enum name="GOTO">
+							<para>The dial completed, but the caller jumped to
+							a dialplan location.</para>
+							<para>If known, the location the caller is jumping
+							to will be appended to the result following a
+							":".</para>
+						</enum>
+						<enum name="NOANSWER">
+							<para>The called party failed to answer.</para>
+						</enum>
 					</enumlist>
 				</parameter>
 			</syntax>