<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
If we only implement A->D cdr we lose information.<br>
On the other hand, if we implement all 3 CDRs for one call we can <br>
either use this info or ignore it and act like its not there. The first
way<br>
is prohibiting for some users. The second one can match any scenario<br>
with none to little effort.<br>
<br>
Steve Murphy wrote:
<blockquote cite="mid:1227553005.29412.25.camel@digium2" type="cite">
<pre wrap="">On Sat, 2008-11-22 at 04:02 +0000, Grey Man wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I've taken the liberty of starting a new thread to discuss the design
of the Asterisk CDR mechanism. The discussion has been kindly
initiated by murf putting together a proposal:
<a class="moz-txt-link-freetext" href="http://svn.digium.com/svn/asterisk/team/murf/RFCs">http://svn.digium.com/svn/asterisk/team/murf/RFCs</a>.
After reading the proposal I still don't think it's the right way to
go. To my mind adding more channel variables increases the complexity
in a situation that is already overly so. I think it's a mistake to
try and think about all the different call scenarios and come up with
little tricks for the more complicated ones. There will always be
something missed; app_shotgun initiates calls to 100 random numbers
and as soon as three or more calls are answered it will start randonly
transferring them amongst each other at 2 second intervals.
I think it's important to clarify at the outset what a CDR should be.
The most fundamental requirement for CDRs is that they accurately
record the following pieces of information for EVERY call entering or
leaving the system (note every means every and not; "channel" calls
but not "peer" calls).
1. Destination (aka as A Number)
2. AccountCode (aka as B Number)
3. Call Start Time (answer time),
4. Duration.
Of course adding extra information can be very useful and I'm not
proposing any fields be removed from the current implementation
(although for pity's sake one change that should be made it to use a
GUID/UUID for the CDR's uniqueid and save endless confusion).
People that really do need verbose or enhanced CDRs to do things like
tracking a call's flow as it travels in and out of queues, parking
lots etc. would be better off using AMI or the new CEL and not CDRs.
At the very least if problems arise with their call flow tracking they
will still be able to rely on the accuracy of the CDRs to piece it
altogether to work out what's going wrong.
My proposal of creating a 1-to-1 relationship between CDRs and
Asterisk channels already exsits but somewhere along the line it's
going awry. As an experiment, and to actually do something instead of
continually moaning about it, I started commenting out the blocks of
code in res_featrures.c and sip_channel.c that muck around with the
channel CDRs when a transfer occurs. The results of that were that the
CDRs for blind and attended transfers actually got better! They're
still not quite right but are pretty close with only one CDR on each
having a wrong detstination.
Regards,
Greyman.
</pre>
</blockquote>
<pre wrap=""><!---->
Greyman--
For the moment, let's not worry about the implementation. Let's
get consensus on the spec first. In the scenario, where A calls B,
B xfers A to C, C xfers A to D, or some such similar scenario,
half the world wants a single CDR for A, from the time it started,
to the time it hung up with D. The other half wants A->B's dial and
bridge,
a cdr for A & C's bridge, a CDR for A & D's bridge, and mayhaps some
CDRs
to describe the xfers, where B xfers A to C and C xfers A to D.
My document is pointing in the former direction, and either we need to
spec both, or pick one.
murf
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a></pre>
</blockquote>
<br>
</body>
</html>