Skip to content
Snippets Groups Projects
  • Matthew Jordan's avatar
    7e9febbf
    app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state · 7e9febbf
    Matthew Jordan authored
    When doing the rework of the CDR engine that pushed all of the logic into cdr.c
    and made it respond to changes in channel state over Stasis, we knew that
    accessing the CDR engine from the dialplan would be "slightly"
    non-deterministic. Dialplan threads would be accessing CDRs while Stasis
    threads would be updating the state of said CDRs - whereas in the past,
    everything happened on the dialplan threads. Tests have shown that "slightly"
    is in reality "very".
    
    This patch synchronizes things by making the dialplan applications/functions
    that manipulate CDRs do so over Stasis. ForkCDR, NoCDR, ResetCDR, CDR, and
    CDR_PROP now all use Stasis to send their requests over to the CDR engine,
    and synchronize on the channel Stasis topic via a subscription so that they
    return their values/control to the dialplan at the appropriate time.
    
    While going through this, the following changes were also made:
     * DISA, which can reset the CDR when a user successfully authenticates, now
       just uses the ResetCDR app to do this. This prevents having to duplicate
       the same Stasis synchronization logic in that application.
     * Answer no longer disables CDRs. It actually didn't work anyway - calling
       DISABLE on the channel's CDR doesn't stop the CDR from getting the Answer
       time - it just kills all CDRs on that channel, which isn't what the caller
       would intend.
    
    (closes issue ASTERISK-22884)
    (closes issue ASTERISK-22886)
    
    Review: https://reviewboard.asterisk.org/r/3057/
    ........
    
    Merged revisions 404294 from http://svn.asterisk.org/svn/asterisk/branches/12
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
    7e9febbf
    History
    app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating state
    Matthew Jordan authored
    When doing the rework of the CDR engine that pushed all of the logic into cdr.c
    and made it respond to changes in channel state over Stasis, we knew that
    accessing the CDR engine from the dialplan would be "slightly"
    non-deterministic. Dialplan threads would be accessing CDRs while Stasis
    threads would be updating the state of said CDRs - whereas in the past,
    everything happened on the dialplan threads. Tests have shown that "slightly"
    is in reality "very".
    
    This patch synchronizes things by making the dialplan applications/functions
    that manipulate CDRs do so over Stasis. ForkCDR, NoCDR, ResetCDR, CDR, and
    CDR_PROP now all use Stasis to send their requests over to the CDR engine,
    and synchronize on the channel Stasis topic via a subscription so that they
    return their values/control to the dialplan at the appropriate time.
    
    While going through this, the following changes were also made:
     * DISA, which can reset the CDR when a user successfully authenticates, now
       just uses the ResetCDR app to do this. This prevents having to duplicate
       the same Stasis synchronization logic in that application.
     * Answer no longer disables CDRs. It actually didn't work anyway - calling
       DISABLE on the channel's CDR doesn't stop the CDR from getting the Answer
       time - it just kills all CDRs on that channel, which isn't what the caller
       would intend.
    
    (closes issue ASTERISK-22884)
    (closes issue ASTERISK-22886)
    
    Review: https://reviewboard.asterisk.org/r/3057/
    ........
    
    Merged revisions 404294 from http://svn.asterisk.org/svn/asterisk/branches/12
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404295 65c4cc65-6c06-0410-ace0-fbb531ad65f3