[asterisk-users] CDR "forking" for DUNDi calls

[Chris Bagnall]

Greetings list,

I have an interesting challenge that presented itself recently that I'm sure many other list readers must have come across and resolved.

We have a client with an asterisk server managing a shared building. The client uses the CDRs to perform billing to the tenants within that building.

When a tenant makes an outbound call, their sip.conf registration sets the accountcode field, and the outbound macro sets the userfield in the CDR to the number that has been dialled. This field is used to determine whether the call is chargeable by our client's billing software.

This works fine for 99% of calls. The problem occurs when a tenant calls another tenant. Part of the outbound macro performs a lookup in the [in-e164] context for the number before passing it onto the PSTN, obviously if the number is handled by this server, the PSTN is avoided. The first dialplan command for each incoming number is Set(CDR(accountcode)=<useraccount>) where <useraccount> is their accountcode. This is essential as some tenants have calls forwarded to their mobiles - which do go out via the PSTN and need to be charged appropriately.

What happens at present is that the caller's accountcode is set, together with the userfield. When the call is sent to the [in-e164] context with the recipient's number, the accountcode is set to theirs, but still with the original userfield. So essentially, the recipient gets charged for being called, and the caller pays nothing. This is the problem.

I've read around and it looks like the solution probably lies in some combination of ForkCDR and ResetCDR, but documentation for both is slim at best, and I'm not really sure where to go from here.

Any suggestions gratefully appreciated.

Regards,

Chris
-- 
C.M. Bagnall, Director, Minotaur I.T. Limited
For full contact details visit http://www.minotaur.it
This email is made from 100% recycled electrons