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

[Alex Barnes (JIRA)]

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

Alex Barnes commented on ASTERISK-20933:
----------------------------------------

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.

                
> 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: debug_1.8.13.log, debug_1.8.20.log, debug_1.8.20_nobridge.log
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira