Skip to content
Snippets Groups Projects
  1. Oct 27, 2013
  2. Jun 17, 2013
    • Matthew Jordan's avatar
      Update Asterisk's CDRs for the new bridging framework · 6258bbe7
      Matthew Jordan authored
      This patch is the initial push to update Asterisk's CDR engine for the new
      bridging framework. This patch guts the existing CDR engine and builds the new
      on top of messages coming across Stasis. As changes in channel state and bridge
      state are detected, CDRs are built and dispatched accordingly. This
      fundamentally changes CDRs in a few ways.
      (1) CDRs are now *very* reflective of the actual state of channels and bridges.
          This means CDRs track well with what an actual channel is doing - which
          is useful in transfer scenarios (which were previously difficult to pin
          down). It does, however, mean that CDRs cannot be 'fooled'. Previous
          behavior in Asterisk allowed for CDR applications, channels, and other
          properties to be spoofed in parts of the code - this no longer works.
      (2) CDRs have defined behavior in multi-party scenarios. This behavior will not
          be what everyone wants, but it is a defined behavior and as such, it is
          predictable.
      (3) The CDR manipulation functions and applications have been overhauled. Major
          changes have been made to ResetCDR and ForkCDR in particular. Many of the
          options for these two applications no longer made any sense with the new
          framework and the (slightly) more immutable nature of CDRs.
      
      There are a plethora of other changes. For a full description of CDR behavior,
      see the CDR specification on the Asterisk wiki.
      
      (closes issue ASTERISK-21196)
      
      Review: https://reviewboard.asterisk.org/r/2486/
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      6258bbe7
  3. Oct 14, 2012
  4. Feb 20, 2012
  5. Sep 26, 2011
    • Richard Mudgett's avatar
      Merged revisions 337974 via svnmerge from · 55b70ae6
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/10
      
      ................
        r337974 | rmudgett | 2011-09-26 14:35:23 -0500 (Mon, 26 Sep 2011) | 37 lines
        
        Merged revisions 337973 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.8
        
        ........
          r337973 | rmudgett | 2011-09-26 14:30:39 -0500 (Mon, 26 Sep 2011) | 30 lines
          
          Fix deadlock when using dummy channels.
          
          Dummy channels created by ast_dummy_channel_alloc() should be destoyed by
          ast_channel_unref().  Using ast_channel_release() needlessly grabs the
          channel container lock and can cause a deadlock as a result.
          
          * Analyzed use of ast_dummy_channel_alloc() and made use
          ast_channel_unref() when done with the dummy channel.  (Primary reason for
          the reported deadlock.)
          
          * Made app_dial.c:dial_exec_full() not call ast_call() holding any channel
          locks.  Chan_local could not perform deadlock avoidance correctly.
          (Potential deadlock exposed by this issue.  Secondary reason for the
          reported deadlock since the held lock was part of the deadlock chain.)
          
          * Fixed some uses of ast_dummy_channel_alloc() not checking the returned
          channel pointer for failure.
          
          * Fixed some potential chan=NULL pointer usage in func_odbc.c.  Protected
          by testing the bogus_chan value.
          
          * Fixed needlessly clearing a 1024 char auto array when setting the first
          char to zero is enough in manager.c:action_getvar().
          
          (closes issue ASTERISK-18613)
          Reported by: Thomas Arimont
          Patches:
                jira_asterisk_18613_v1.8.patch (license #5621) patch uploaded by rmudgett
          Tested by: Thomas Arimont
        ........
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      55b70ae6
  6. Jul 14, 2011
  7. May 05, 2011
  8. Jul 20, 2010
  9. Feb 26, 2010
  10. Jun 26, 2009
Loading