[Home]

Summary:ASTERISK-24254: CDRs: Application/args/dialplan CEP updated during dial operation
Reporter:Matt Jordan (mjordan)Labels:
Date Opened:2014-08-21 06:53:51Date Closed:2014-09-05 17:06:25
Priority:MajorRegression?
Status:Closed/CompleteComponents:CDR/General
Versions:12.5.0 13.0.0-beta1 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ASTERISK-24254-12.diff
( 1) ASTERISK-24254-13.diff
Description: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.
Comments:By: Richard Mudgett (rmudgett) 2014-08-21 11:14:02.660-0500

I think option 2 is the better approach.  There are more interception macros/routines being used by the system now.  Connected-line interception routines, pre-dial routines, pre-connect routines (Dial's M and U options), Confbridge menu, DYNAMIC_FEATURES applicationmap, etc...

The nice thing is that most of these macros/routines are done by calling a function with the dialplan location to execute so it would be easy enough to add before/after channel snapshots with the flag.

By: Matt Jordan (mjordan) 2014-08-29 21:24:48.037-0500

As it turns out, the issue isn't due to mid-call macros or mid-call gosubs. It actually is the execution of _any_ macro or gosub that causes the issue for FreePBX. This does make some sense: if we have a common macro or subroutine that executes a Dial (or Queue, or anything else for that matter), the extension field in the CDR record is generally useless.

Interestingly enough, 1.8/11 have code that handles this for macros, but fail to do so for GoSubs. Because touching CDRs in 1.8/11 is a good way to cause an infinite amount of pain, this will only get fixed in 12+.