[asterisk-bugs] [JIRA] (ASTERISK-24254) CDRs: Application/args/dialplan CEP updated during dial operation

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan closed ASTERISK-24254.
----------------------------------


> CDRs: Application/args/dialplan CEP updated during dial operation
> -----------------------------------------------------------------
>
>                 Key: ASTERISK-24254
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24254
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/General
>    Affects Versions: 12.5.0, 13.0.0-beta1
>            Reporter: Matt Jordan
>            Assignee: Matt Jordan
>         Attachments: ASTERISK-24254-12.diff, ASTERISK-24254-13.diff
>
>
> From the original FreePBX issue:
> {quote}
> Just installed Asterisk 12.4.0 and FreePBX 12.0.1beta10 from source.
> It's working almost all, just have two issues with cdr logging. After installed FreePBX 12, the CDR mysql database is not populated with any call data. I must create the file 'cdr_adaptive_odbc.conf' with this config to make it works:
> [cdr]
> connection=asteriskcdrdb
> table=cdr
> alias start => calldate
> It's right? FreePBX doens't auto make configurations for using odbc to store cdr data to mysql? (cdr_mysql is not compiled because it's deprecated).
> However the cdr is working right now, but I discovered a wrong behavior:
> the dst field contain 's' and not the dialed number, example:
> extension 1 call extension 2:
> "","1","s","macro-dial-one","""Mario Rossi"" <1>","SIP/1-00000000","SIP/2-00000001","Dial","SIP/2,,TtrI","2014-08-14 15:28:35","2014-08-14 15:28:38","2014-08-14 15:28:42",6,3,"ANSWERED","DOCUMENTATION","1408030115.0",""
> With Asterisk 11 and FreePBX 2.11 the dst field contain the dialed number.
> Best Regards
> {quote}
> The issue here is that subroutines executed within {{app_dial}} (or other applications for that matter) update the application, arguments, and the dialplan location of the calling channel. In particular, this removes the dial string portion of the CDR, which is generally not what people want.
> Generally, we need to ignore channel snapshots that are executing in the context of a mid-call macro/gosub/pre-dial, in a similar way that we "know" when a channel is executing hangup logic. There's a few ways to accomplish this:
> # Look for the dial begin event and lock the state of the calling channel. This may require caching the application/data/dialplan location off of the channel into the CDR object itself (which is already done at other times). The biggest problem with this approach is that pre-dial occurs prior to the dial begin, which means we'd most likely need to have pre-dial stasis events. More stasis events is some what undesirable.
> # Set a flag on the channel when it is executing a mid-call subroutine/macro/pre-dial. The CDR code can inspect the snapshots for the presence of this flag and, if present, take action accordingly. This adds another flag to the channel, which is also not great.
> # Finally, we could just lock the snapshot when we see it enter into a particular application until we see a DialEnd. This would require no changes other than in the CDR engine, but would require hard coded application strings which is less ideal.



--
This message was sent by Atlassian JIRA
(v6.2#6252)