kenmirrors/asterisk
1
0
Fork 0
mirror of https://github.com/asterisk/asterisk.git synced 2025-10-12 15:45:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

Handle hangup logic in the Stasis message bus and consumers of Stasis messages

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

7
CHANGES
View File

@@ -286,8 +286,11 @@ CDR (Call Detail Records)
* CDRs will now be created between all participants in a bridge. For each
pair of channels in a bridge, a CDR is created to represent the path of
communication between those two endpoints. This lets an end user choose who
to bill for what during multi-party bridges or bridge operations during
transfer scenarios.
to bill for what during bridge operations with multiple parties.
* The duration, billsec, start, answer, and end times now reflect the times
associated with the current CDR for the channel, as opposed to a cumulative
measurement of all CDRs for that channel.
* When a CDR is dispatched, user defined CDR variables from both parties are
included in the resulting CDR. If both parties have the same variable, only