[asterisk-bugs] [JIRA] (ASTERISK-20933) No CDR created after call has been split and then bridged back

[Rusty Newton (JIRA)]

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

Rusty Newton commented on ASTERISK-20933:
-----------------------------------------

bq. I've tested this on Asterisk 1.8.25.0 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.

                
> No CDR created after call has been split and then bridged back
> --------------------------------------------------------------
>
>                 Key: ASTERISK-20933
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20933
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/General, Core/Bridging
>    Affects Versions: 1.8.14.1, 1.8.15.1, 1.8.19.1
>         Environment: CentOS 5 using Digium yum repositories
>            Reporter: Alex Barnes
>            Assignee: Alex Barnes
>         Attachments: adaptive_bridge.log, adaptive_working.log, cdr_adaptive_odbc.conf, channels.log, debug_1.8.13.log, debug_1.8.20.log, debug_1.8.20_nobridge.log, extensions.conf, modules.conf, res_odbc.conf
>
>
> Scenario
> ===========================
> 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.
> Versions
> ===========================
> All packages installed via Yum.
> * 1.8.13.1-1_centos5 = OK
> * 1.8.14.1-1_centos5 = No CDR
> * 1.8.15.1-1_centos5 = No CDR
> * 1.8.15-0.cert1.1_centos5 = No CDR
> * 1.8.19.1-1_centos5 = No CDR
> Dialplan
> ===========================
> {code}
> [from-inside]
> exten => 321,1,SET(__DYNAMIC_FEATURES=testBridge)
> exten => 321,n,Dial(DAHDI/g1/321,300,)
> [macro-test-bridge]
> 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)
> [test-wait-bridge]
> 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)})
> [test-wait]
> exten => 1,1,NoOp(In test-wait)
> exten => 1,n,Wait(30)
> exten => 1,n,Hangup
> {code}
> features.conf
> ===========================
> {code}
> testBridge  => #2,peer,Macro,test-bridge
> {code}
> Example Output
> ===========================
> See attachments

--
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