[asterisk-bugs] [JIRA] (ASTERISK-21688) CDR record cannot be modified in 'h' extension when 'g' option is used in Dial application

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205828#comment-205828 ] 

Matt Jordan edited comment on ASTERISK-21688 at 4/25/13 9:41 AM:
-----------------------------------------------------------------

Interesting. This only occurs when the 'g' option is present as an option passed to the Dial application.

When the 'g' option is set, the {{AST_FEATURE_NO_H_EXTEN}} is applied to the caller channel's features. This has the result of not running the {{h}} extension on the channel when the peer hangs up, and causes the goofy CDR logic in features to not be executed. In general, this is a 'good' thing, however, when the bridge is broken the CDR is written automatically. This means that when the {{h}} extension is executed on the caller channel, the CDR is already out the door, and you can't catch it. The {{Set}} in the {{h}} extension is actually executing on a non-existant CDR record on the caller channel.

I don't see us changing this behavior.
# It would require us changing CDR behavior in a release branch.
# It is incredibly complex, and attempting to hold the CDR for the bridge after the bridge has been broken would have far-reaching implications.
# There is an easy work around: don't use the 'g' flag if you don't need to.
# Even if you do need the 'g' flag, then set the property on the CDR prior to the bridge being created using one of the various interception macros or subroutines.

                
      was (Author: mjordan):
    Interesting. This only occurs when the 'g' option is present as an option passed to the Dial application.

When the 'g' option is set, the {{AST_FEATURE_NO_H_EXTEN}} is applied to the caller channel's features. This has the result of not running the {{h}} extension on the channel when the peer hangs up, and causes the goofy CDR logic in features to not be executed. In general, this is a 'good' thing, however, when the bridge is broken the CDR is written automatically.

This means that when the {{h}} extension is executed on the caller channel, the CDR is already out the door, and you can't catch it.

I don't see us changing this behavior.
# It would require us changing CDR behavior in a release branch.
# It is incredibly complex, and attempting to hold the CDR for the bridge after the bridge has been broken would have far-reaching implications.
# There is an easy work around: don't use the 'g' flag if you don't need to.
# Even if you do need the 'g' flag, then set the property on the CDR prior to the bridge being created using one of the various interception macros or subroutines.

                  
> CDR record cannot be modified in 'h' extension when 'g' option is used in Dial application
> ------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21688
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21688
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_dial, CDR/General, Features
>    Affects Versions: 11.2.1
>         Environment: Debian Squeeze 64x
> Asterisk 11.2-cert1
>            Reporter: Emiliano
>            Severity: Minor
>
> Can't update CDR (cdr_adaptive_odbc) custom fields after hangup.
> I tried by setting endbeforehexten with yes or no.
> Scenario:
> exten => s,1,Dial(SIP/TEST,,g)
> same => n,Set(CDR(field)=testing)
> same => n,hangup()
> exten => h,1,Noop(Set different value for field)
> same => n,Set(CDR(field)=hanguptest)
> same => n,hangup()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira