[asterisk-users] Refactor of CDR - Comments please.
Steve Davies
davies147 at gmail.com
Tue Jun 7 06:44:38 CDT 2011
Hi,
Since raising this ticket about broken CDR data:
https://issues.asterisk.org/jira/browse/ASTERISK-17826
I have been researching how CDR records work in various circumstances.
CEL will do most things that people want, but that does not change
that CDR records are likely to persist into future versions, and
should be as correct as possible.
Is this something people want? Is it "worth the risk" to change CDRs
again? I am working on a patch within 1.6.2, and if it is considered
worthwhile I will clean-up and migrate the patch to 1.8 and put it on
the review-board
It struck me that the fundamental issue was the "bridge_cdr" construct
that appears to have been added in version 1.4. While this solved the
problems it was aimed at solving, it appears to have caused other
problems, and perhaps even worsened support of CDR records when
channels are transferred/masqueraded. The "special cdr reset" feature
seems to be able to clear out valuable CDRs that are no-longer related
to the bridge when it ends, and copying bridge_cdr back into chan->cdr
often overwrites other valuable CDR data!
A classic example of the current failing is:
- A UK based receptionist calls Australia.
- Then a 2nd call leg is placed UK to America.
- The receptionist bridges the 2 calls.
The desired outcome would be 2 CDR records detailing the full duration
of both calls for billing purposes. Sadly, at present, one of the 2
CDRs stops when the transfer happens because Asterisk sees only one
bridge in progress.
Here is the outline of my solution:
1) There are 2 basic types of CDR
a) A CDR that tracks a running PBX/dialplan.
b) A CDR that tracks an outbound dialled channel.
2) Channels can be bridged and re-bridged. When bridging, the existing
code provides a way to merge caller (PBX) and callee (Dialed) CDRs,
and for consistency this will be maintained as closely as possible.
3) A CDR on a dialled channel should track that channel for its lifetime.
4) A CDR that tracks a running PBX should track that PBX for its
lifetime or until merged into a dialled call.
Side-note: 3) and 4) Affect the way cdr data is masqueraded.
5) Aim: Valid CDR output should be changed minimally over the current system.
6) Aim: NoCDR, ResetCDR and ForkCDR etc will remain untouched and
function the same.
7) A bridge CDR will be un-needed, instead, the bridged CDR will be
stored the dialed channel.
8) It is intended that all call legs will have a CDR, which will
accurately reflect the duration of that call leg, but no attempt will
be made to record transfers/masquerades beyond current mechanisms. CEL
data should provide that additional information if needed.
The changes to achieve the above are surprisingly minor (relatively
speaking). I am testing all of the cases that I can think of:
- Simple call in.
- Simple call out.
- Call-out, then blind transferred by caller and callee.
- Call-out, then att. transferred by caller and callee.
- AMP or call-file originated call.
- Masq-away of Local channel.
- Bridge() channels in the dialplan.
- Feature park of calls.
- Local/ channel calls.
- Feature transfer of calls.
- Transfer call to IVR/Playback
- Transfer IVR/Playback to a handset
- Feature Pickup and Pickup()
- SIP blind xfer
- SIP att xfer
- SIP xfer to ringing channel
Thoughts?
Many thanks,
Steve
More information about the asterisk-users
mailing list