Summary:ASTERISK-20933: No CDR created after call has been split and then bridged back
Reporter:Alex Barnes (abarnes)Labels:
Date Opened:2013-01-14 08:08:42.000-0600Date Closed:2017-12-19 05:11:18.000-0600
Status:Closed/CompleteComponents:CDR/General Core/Bridging
Versions: Frequency of
is related toASTERISK-19537 Deadlock potential in ast_do_masquerade() because it calls ast_indicate with the channel lock held.
Environment:CentOS 5 using Digium yum repositoriesAttachments:( 0) adaptive_bridge.log
( 1) adaptive_working.log
( 2) cdr_adaptive_odbc.conf
( 3) channels.log
( 4) debug_1.8.13.log
( 5) debug_1.8.20_nobridge.log
( 6) debug_1.8.20.log
( 7) extensions.conf
( 8) modules.conf
( 9) res_odbc.conf

No CDR record is created after a call has been split and then bridged back.  See example dialplan below where a CDR record is created at all points right up to the Bridge command but not after.  Reversing which channel gets bridged still results in no CDR, i.e. the caller doing the bridging or the callee.

In our case the VoiceSafe is acting as an ISDN middle-man to record and log calls before being passed onto the PBX or telco.  I haven't tested purely SIP but I imagine it would be the same outcome.

Note that this was working in 1.8.13 but appears to have been broken in 1.8.14 and above.

All packages installed via Yum.

* = OK
* = No CDR
* = No CDR
* 1.8.15-0.cert1.1_centos5 = No CDR
* = No CDR

exten => 321,1,SET(__DYNAMIC_FEATURES=testBridge)
exten => 321,n,Dial(DAHDI/g1/321,300,)

exten => s,1,NoOp(In test-bridge)
exten => s,n,Set(operator-channel=${CHANNEL})
exten => s,n,Set(caller-channel=${BRIDGEPEER})

; Sync variables on both channels
exten => s,n,NoOp(Syncing channel vars)
exten => s,n,Set(SHARED(operator-channel,${operator-channel})=${operator-channel})
exten => s,n,Set(SHARED(caller-channel,${operator-channel})=${caller-channel})
exten => s,n,Set(SHARED(operator-channel,${caller-channel})=${operator-channel})
exten => s,n,Set(SHARED(caller-channel,${caller-channel})=${caller-channel})

exten => s,n,ChannelRedirect(${caller-channel},test-wait-bridge,1,1)
exten => s,n,ChannelRedirect(${operator-channel},test-wait,1,1)

exten => 1,1,NoOp(In test-wait-bridge)
exten => 1,n,Wait(5)
; Hanging up here rather than bridging will results in CDR correctly being created
; exten => 1,n,Hangup
exten => 1,n,Bridge(${SHARED(operator-channel)})

exten => 1,1,NoOp(In test-wait)
exten => 1,n,Wait(30)
exten => 1,n,Hangup

testBridge  => #2,peer,Macro,test-bridge

Example Output
See attachments
Comments:By: Rusty Newton (rnewton) 2013-01-16 09:36:12.625-0600


Please attach an Asterisk full log demonstrating the issue with DEBUG and VERBOSE messages enabled at level 5 or above.

Please attach any debug to the issue as a file and not in-line. Hit the Send Back button after. Thanks!

By: Alex Barnes (abarnes) 2013-01-17 05:25:08.366-0600

Attaching debug traces for the working version 1.8.13 and latest version, now 1.8.20.

Note on the debug_1.8.20_nobridge.log a CDR is written correctly when the call is not bridged.

By: Rusty Newton (rnewton) 2013-01-25 13:09:11.971-0600


Difficult to tell whats going on from the debug. There could be a bug in Asterisk or the module. You are using cdr_mysql, a deprecated module. For the core team to look into this, you would need to reproduce the issue using a core supported CDR module (preferably res_odbc/cdr_adaptive_odbc). If you reproduce it with an extended support module and then it would be up to a community developer to look into it.

However you reproduce it, they'll likely want to see all the options set in relevant config files , those for the CDR backend and for dialplan and channels involved.

By: Alex Barnes (abarnes) 2013-01-27 12:54:21.324-0600

I'll try and reproduce again tomorrow with the modules you listed.

I did reproduce the bug previously using cdr_syslog in order to try to discount the bug being in the cdr_mysql addon.  Sorry I can't figure out from your wiki link how to determine if cdr_syslog is actually core, I'm assuming it isn't but hopefully helps indicate cdr_mysql is not at fault in this case.

On a side note I'd prefer to switch to a core supported module regardless of this issue so thanks for the heads up.

By: Alex Barnes (abarnes) 2013-01-29 04:33:19.530-0600


I have attached some traces for the same scenarios but using cdr_adaptive_odbc and it displays the same issue as cdr_mysql.  Hence it looks like an issue in Asterisk rather than the CDR modules.


By: Rusty Newton (rnewton) 2013-01-29 09:48:14.051-0600

Thanks Alex.  You can see the support states for all the modules by looking at them in the menuselect tool you use before compiling Asterisk.

By: Rusty Newton (rnewton) 2013-01-29 11:07:41.149-0600

Linking issue ASTERISK-19537 -the commit resolving it occurred between the versions mentioned by reporter and seems most likely related to a possible cause for this issue.

{quote} = OK = No CDR

By: Alex Barnes (abarnes) 2014-02-10 09:39:42.322-0600


I've tested this on Asterisk and it still appears to be an issue.  This is quite an issue for us as we've not been able to update our version of Asterisk from version 1.8.13 for over a year now.

Should this Jira still be assigned to me or should it go back to unassigned?



By: Rusty Newton (rnewton) 2014-02-26 09:43:33.023-0600

bq. I've tested this on Asterisk and it still appears to be an issue. This is quite an issue for us as we've not been able to update our version of Asterisk from version 1.8.13 for over a year now.

It is in the queue with hundreds of other issues. We have many issues that are reported by many people, or where the code is commonly used by the entire user base. Due to the nature of things, those will be worked ahead of this one and you'll have to wait until a developer is either available or interested in working on this issue.

I know it is painful to run into an issue like this, however this is an open source project, you are welcome to submit a patch or [post a bounty|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties] on the lists if you don't have development capability . You can also just ask someone to take a look, though the developers consider CDR very tricky and an area of Asterisk where bug fix attempts can often result in more bugs being created.

As a note, [Channel Event Logging|https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=5242932] was created to solve a lot of design issues with CDR. You may look into using it in the future. Bugs against CEL are more likely to be fixed sooner rather than later.

That all being said, this issue does appear to be a regression and I'll ping a few people to see if any one has a chance to take a look at it. If they do, you'll see updates on the issue.

bq. Should this Jira still be assigned to me or should it go back to unassigned?

If in Waiting on Feedback status, you can press the "Send Back" or "Enter Feedback" buttons to get it back to its previous state, in this case that is Open. I've also set it to unassigned, as it shouldn't be assigned to you while in the Open state.

By: Alex Barnes (abarnes) 2014-02-26 12:06:22.170-0600

Many thanks for the update.

Definitely appreciate the open source aspect.  As you say since it was a regression issue I hoped that the original devs would be well placed to resolve the issue.  

Upgrading to CEL is definitely something I would like to do and is on our roadmap but it is quite a large change for our systems.

I'll see if I can persuade a sign off on a bounty.  Any ball park idea of how many man hours this bug might take to resolve?

By: Joshua C. Colp (jcolp) 2017-12-19 05:11:18.690-0600

CDRs have been completely rewritten in supported versions of Asterisk and this issue is no longer applicable, as a result I am suspending it.