<!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">
Steve Murphy wrote:
<blockquote cite="mid:1231775463.20112.690.camel@digium2" type="cite">
<pre wrap="">Hello!
Most are probably bored seeing another letter about this,
but I've put in a fair amount work on a spec for rewriting
the CDR system in Asterisk, and I have some questions:
First, please look at what I've written so far:
svn co <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>
and look at the file "CDRfix2.rfc.txt" in the RFCs dir.
The spec SIGNIFICANTLY alters the way CDRs are generated,
how they are structured, and what they express.
If you have ANYTHING to do with CDRs, then it is critical
you become involved in the design process for the new system!
Or suffer with the results!
What's going on?
I wrote up two modes of CDR generation: Leg-Based, and Simple.
A new field, "linkedID", that can be used to link CDRs as part
of the same total call.
Leg-Based is (or can be) very detailed. Every CDR has a type,
like CALL, AXFER, BXFER, PARK, etc. Depending on what actions
occur during a call, a call can be split up into several
"legs". A dialplan func to insert an event that will create
a new "leg" will be available, with its own user-specified
type.
Simple is just that. One CDR is generated per activated channel.
The start time is when it was created. The end time when it died/hungup.
The answer time is... you know! No fine-grained details. No dialplan
fanciness. linkedID can help you group channels involved in a single
'logical call'.
QUESTIONS:
Which of the two would you see being useful to you?
Is there Yet Another CDR system you would like to see instead?
How would/should it work?
Will both fulfil the requirements of CALEA?
It's been proposed that we implement just the Simple
CDR now, and it be introduced in some 1.6.x (or higher)
release. In that release, the existing CDR system would be
deprecated, and in some "futurer" release the "old" (now current)
CDR system would be dropped entirely. What do you
think? Are we high on drugs, or what?
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>
Hi,<br>
<br>
The specs look very promising. I think everyone<br>
here should be grateful for your efforts. In answer to your<br>
question I personally find both approaches very useful, although<br>
I would prefer to see the "simple" approach implemented first<br>
chronologically since I believe it is simpler to implement and we could<br>
get immediate results.<br>
One small question. I tried finding the "peeraccount" variable that<br>
was brought up many times in past emails in your CDRs fields
descriptions<br>
but I couldn't. This field was supposed to hold the accountcode for the
terminating side<br>
(and could be set for each channel using CHANNEL()) according to this :<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.venturevoip.com/print.php?rssid=2011">http://www.venturevoip.com/print.php?rssid=2011</a><br>
<br>
Is this field going to be implemented?<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: <a class="moz-txt-link-abbreviated" href="mailto:regs@kinetix.gr">regs@kinetix.gr</a>
------------------------------------------- </pre>
</body>
</html>