diff options
author | Matthew Jordan <mjordan@digium.com> | 2013-07-07 20:34:38 +0000 |
---|---|---|
committer | Matthew Jordan <mjordan@digium.com> | 2013-07-07 20:34:38 +0000 |
commit | b193c2873d27e15dfec521c7fef10411e8d1f5c8 (patch) | |
tree | daca49030f9fa3d65f64bb6df6beba256a0e6c92 /include/asterisk/cdr.h | |
parent | c54b26a18ced70ee31e27b4f545d2d5289d73043 (diff) |
Handle hangup logic in the Stasis message bus and consumers of Stasis messages
This patch does the following:
* It adds a new soft hangup flag AST_SOFTHANGUP_HANGUP_EXEC that is set when a
channel is executing dialplan hangup logic, i.e., the 'h' extension or a
hangup handler. Stasis messages now also convey the soft hangup flag so
consumers of the messages can know when a channel is executing said
hangup logic.
* It adds a new channel flag, AST_FLAG_DEAD, which is set when a channel is
well and truly dead. Not just a zombie, but dead, Jim. Manager, CEL, CDRs,
and other consumers of Stasis have been updated to look for this flag to
know when the channel should by lying six feet under.
* The CDR engine has been updated to better handle a channel entering and
leaving a bridge. Previously, a new CDR was automatically created when a
channel left a bridge and put into the 'Pending' state; however, this
way of handling CDRs made it difficult for the 'endbeforehexten' logic to
work correctly - there was always a new CDR waiting in the hangup logic
and, even if 'ended', wouldn't be the CDR people wanted to inspect in the
hangup routine. This patch completely removes the Pending state and instead
defers creation of the new CDR until it gets a new message that requires
a new CDR.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'include/asterisk/cdr.h')
-rw-r--r-- | include/asterisk/cdr.h | 24 |
1 files changed, 2 insertions, 22 deletions
diff --git a/include/asterisk/cdr.h b/include/asterisk/cdr.h index cd0501f06..49acc61dd 100644 --- a/include/asterisk/cdr.h +++ b/include/asterisk/cdr.h @@ -178,7 +178,7 @@ * * The following transitions can occur while in the Bridge state: * \li If a \ref ast_bridge_blob_type message indicating a leave is received, - * the state transitions to the Pending state + * the state transitions to the Finalized state. * * \par Parked * @@ -203,27 +203,7 @@ * * The following transitions can occur while in the Parked state: * \li If a \ref ast_bridge_blob_type message indicating a leave is received, - * the state transitions to the Pending state - * - * \par Pending - * - * After a channel leaves a bridge, we often don't know what's going to happen - * to it. It can enter another bridge; it can be hung up; it can continue on - * in the dialplan. It can even enter into limbo! Pending holds the state of the - * CDR until we get a subsequent Stasis message telling us what should happen. - * - * The following transitions can occur while in the Pending state: - * \li If a \ref ast_bridge_blob_type message is received, a new CDR is created - * and it is transitioned to the Bridge state - * \li If a \ref ast_channel_dial_type indicating a Dial Begin is received, a - * new CDR is created and it is transitioned to the Dial state - * \li If a \ref ast_channel_cache_update is received indicating a change in - * Context/Extension/Priority, a new CDR is created and transitioned to the - * Single state. If the update indicates that the party has been hung up, the - * CDR is transitioned to the Finalized state. - * \li If a \ref ast_bridge_blob_type message indicating an entrance to a - * holding bridge with a subclass type of "parking" is received, the CDR is - * transitioned to the Parked state. + * the state transitions to the Finalized state * * \par Finalized * |