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
This commit is contained in:
Matthew Jordan
2013-07-07 20:34:38 +00:00
parent c54b26a18c
commit b193c2873d
11 changed files with 276 additions and 271 deletions

View File

@@ -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
*