No CDR created after call has been split and then bridged

Asterisk Asterisk Support
1

Hi all,

I have created a bug for an issue we are having since upgrading from 1.8.13 to 1.8.14 and above (inc. 1.8.19) but I was hoping someone could help reproduce or even suggest a work around.

Bug report is here, including example dialplans etc, to save me repeating myself too much: issues.asterisk.org/jira/browse/ASTERISK-20933

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.

Dialplan

This is a simplified dialplan to demonstrate the issue, our real dialplan is more complicated. The macro “macro-test-bridge” is initiated via DTMF feature.

[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

Thanks in advance for any help or suggestions,

Alex

2

You shouldn’t be using CDRs if you are doing anything but the simplest of calls. You should be using call event logging.

CDRs are not being actively maintained because the chances of collateral damage are too high. They are known not to work in non-trivial cases.

You might just get a fix, in this case, because it is a regeression error.

3

Hi David,

Thanks for the quick reply.

I’ve never looked into event logging so will do now, however I get the feeling its going to make me cry with that amount of work required to refactor our backend classes :smiley:

When you said “call event logging” did you mean “channel event logging” as Google is pointing me towards this page: voip-info.org/wiki/view/Aste … g+cel.conf

Cheers

Alex

4

yes

5

As far as my Goolging of the internet and the mailing list has found it appears that CEL isn’t really ready for a drop-in CDR system yet.

I found an RFC for a suggested module to convert events into a simple CDR but its hasn’t been updated for a long time: svn.digium.com/svn/asterisk/team/murf/RFCs/

Also the Asterisk wiki has a “to do” essentially that hasn’t been updated since 2010: wiki.asterisk.org/wiki/display/ … n+from+CEL

Does anyone know if any progress has been made in converting CEL into CDR?

I can see us writing our own CEL parser that creates simple CDR but this does seem like a popluar piece of work. Unfortunately we are a Java / PHP house so our own tool would most likely be an external utility rather than a nicely integrated Asterisk module :frowning:

Overall I like the sound of CEL and certainly seems like the way forward compared to the old CDR module and its apparent (not had problems ourselves till now) problems / shortcoming.

Thanks

Alex

6

I suspect you cannot turn CELs into CDRs without kowing the details of the specific dialplan and possibly also some local policy details.

7

To calculate billling the app would need to know something about the setup and/or dialplan to make decisions on inbound / outbound call direction. For example we infer direction based on DAHDI group number.

Converting CEL into either leg based CDR or a table equivalent to the current CDR module is certainly not trivial though. Hopefully there is a module in the pipeline already as I’m sure this would be very popular.