Skip to content
Snippets Groups Projects
  • Matthew Jordan's avatar
    d42b1169
    main/cdrs: Preserve context/extension when executing a Macro or GoSub · d42b1169
    Matthew Jordan authored
    The context/extension in a CDR is generally considered the destination of a
    call. When looking at a 2-party call CDR, users will typically be presented
    with the following:
    
    context    exten      channel     dest_channel app  data
    default    1000       SIP/8675309 SIP/1000     Dial SIP/1000,,20
    
    However, if the Dial actually takes place in a Macro, the current behaviour
    in 12 will result in the following CDR:
    
    context    exten      channel     dest_channel app  data
    macro-dial s          SIP/8675309 SIP/1000     Dial SIP/1000,,20
    
    The same is true of a GoSub:
    
    context    exten      channel     dest_channel app  data
    subs       dial_stuff SIP/8675309 SIP/1000     Dial SIP/1000,,20
    
    This generally makes the context/exten fields less than useful.
    
    It isn't hard to preserve these values in the CDR state machine; however, we
    need to have something that informs us when a channel is executing a
    subroutine. Prior to this patch, there isn't anything that does this.
    
    This patch solves this problem by adding a new channel flag,
    AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a
    Macro or a GoSub. The CDR engine looks for this value when updating a Party A
    snapshot; if the flag is present, we don't override the context/exten on the
    main CDR object. In a funny quirk, executing a hangup handler must *not* abide
    by this logic, as the endbeforehexten logic assumes that the user wants to see
    data that occurs in hangup logic, which includes those subroutines. Since
    those execute outside of a typical Dial operation (and will typically have
    their own dedicated CDR anyway), this is unlikely to cause any heartburn.
    
    Review: https://reviewboard.asterisk.org/r/3962/
    
    ASTERISK-24254 #close
    Reported by: tm1000, Tony Lewis
    Tested by: Tony Lewis
    ........
    
    Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12
    ........
    
    Merged revisions 422719 from http://svn.asterisk.org/svn/asterisk/branches/13
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422720 65c4cc65-6c06-0410-ace0-fbb531ad65f3
    d42b1169
    History
    main/cdrs: Preserve context/extension when executing a Macro or GoSub
    Matthew Jordan authored
    The context/extension in a CDR is generally considered the destination of a
    call. When looking at a 2-party call CDR, users will typically be presented
    with the following:
    
    context    exten      channel     dest_channel app  data
    default    1000       SIP/8675309 SIP/1000     Dial SIP/1000,,20
    
    However, if the Dial actually takes place in a Macro, the current behaviour
    in 12 will result in the following CDR:
    
    context    exten      channel     dest_channel app  data
    macro-dial s          SIP/8675309 SIP/1000     Dial SIP/1000,,20
    
    The same is true of a GoSub:
    
    context    exten      channel     dest_channel app  data
    subs       dial_stuff SIP/8675309 SIP/1000     Dial SIP/1000,,20
    
    This generally makes the context/exten fields less than useful.
    
    It isn't hard to preserve these values in the CDR state machine; however, we
    need to have something that informs us when a channel is executing a
    subroutine. Prior to this patch, there isn't anything that does this.
    
    This patch solves this problem by adding a new channel flag,
    AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a
    Macro or a GoSub. The CDR engine looks for this value when updating a Party A
    snapshot; if the flag is present, we don't override the context/exten on the
    main CDR object. In a funny quirk, executing a hangup handler must *not* abide
    by this logic, as the endbeforehexten logic assumes that the user wants to see
    data that occurs in hangup logic, which includes those subroutines. Since
    those execute outside of a typical Dial operation (and will typically have
    their own dedicated CDR anyway), this is unlikely to cause any heartburn.
    
    Review: https://reviewboard.asterisk.org/r/3962/
    
    ASTERISK-24254 #close
    Reported by: tm1000, Tony Lewis
    Tested by: Tony Lewis
    ........
    
    Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12
    ........
    
    Merged revisions 422719 from http://svn.asterisk.org/svn/asterisk/branches/13
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422720 65c4cc65-6c06-0410-ace0-fbb531ad65f3