<br><font size=2 face="sans-serif">I think you're on the right track with
respect to the events related to calls. Any change in a call's connection
state, what caused that state, and what time the state change occurred.
I haven't studied the core code enough to know if that information
is traced as a single object anywhere, but that would make the most sense.
</font>
<br>
<br><font size=2 face="sans-serif">The problem with logging in general,
is that you get a great sequence of events on a call, but reporting from
that is tricky. People wants reports on the duration of some events
from end point to the end point, but determining the start and end points
is harder than you'd think. Is it the time the connection happens,
or when the call is dialed? Is "parked" time excluded or included?
These are going to be subject to the economic needs of the report,
not any kind of programmer logic. That means nearly any reporting
software is going to have to do some kind of sequential scan and compile
statistics as a pre-report job. </font>
<br>
<br><font size=2 face="sans-serif">Given the above, the idea of each call
getting a unique id and having each event tagged with that id and a timestamp
is probably the most important first aspect. From there, an external
process which compiles the records in any number of ways becomes possible.
A sort of pseudocode way of looking at a call that makes sense to
me could best be represented in a kind of xml style tree structure, though
I don't believe this is a good way to STORE the data.</font>
<br>
<br><font size=2 face="sans-serif"><call></font>
<br><font size=2 face="sans-serif"> <initiated></font>
<br><font size=2 face="sans-serif">
<menutree></font>
<br><font size=2 face="sans-serif">
<outbound
dial></font>
<br><font size=2 face="sans-serif">
<remote answered></font>
<br><font size=2 face="sans-serif">
<remote disconnected></font>
<br><font size=2 face="sans-serif">
</outbound
dial></font>
<br><font size=2 face="sans-serif">
</menutree></font>
<br><font size=2 face="sans-serif"> <disconnected></font>
<br><font size=2 face="sans-serif"></call></font>
<br>
<br><font size=2 face="sans-serif">If you look at each of the nodes as
having a timestamp, context, local and remote numbers, etc., it would
be logically easy to get the whole call time, subject out time in the menu,
add back time on the outbound dial or remote answered segments, etc.</font>
<br>
<br><font size=2 face="sans-serif">Keep in mind that I am representing
the data this way, but I do NOT support storing the call data for each
call as an XML record. XML is good for transferring data from one
place to another but its a pretty wasteful and difficult to process storage
format.</font>
<br>
<br><font size=2 face="sans-serif">---<br>
Andrew Pollack<br>
Northern Collaborative Technologies<br>
207-221-2547<br>
</font>
<br>
<br><tt><font size=2>Miroslav Nachev <miro@space-comm.com> wrote
on 03/27/2006 07:52:33 AM:<br>
<br>
> Dear Andrew,<br>
> <br>
> Thank you very much for the supported letter.<br>
> Let's start the projects with one discussion about which
events we<br>
> need. Then to sumarize and think out in advance the data structure<br>
> where will be stored this information and from where this information<br>
> will be taken. After that I will start design and develop the project.<br>
> <br>
> From which detailed records you need?<br>
> <br>
> <br>
> Best Regards,<br>
> Miroslav Nachev<br>
> <br>
> <br>
> AP> Miroslav, <br>
> <br>
> AP> This sounds like an excellent addition to Asterisk. As<br>
> AP> someone who has made a living for twenty years producing<br>
> AP> applications for customers I can tell you without question
that<br>
> AP> the most important and at the same time most frequently overlooked<br>
> AP> part of the projects are their ability to produce highly detailed<br>
> AP> and customized reports. I once had a company CIO (Chief<br>
> AP> Information Officer) tell me that while it was true his users<br>
> AP> wanted lots of bells and whistles, he didn't care if I built
the<br>
> AP> thing out of crayons on waxpaper as long as he could get reports<br>
> AP> out of it that justified the expenditure. <br>
> <br>
> AP> If Asterisk is to continue to grow into the mainstream<br>
> AP> marketplace -- and I have no doubt that it will -- highly detailed<br>
> AP> reporting is one of the most important additions to be made.
Good<br>
> AP> luck on your project. <br>
> <br>
> AP> ---<br>
> AP> Andrew Pollack<br>
> AP> Northern Collaborative Technologies<br>
> AP> 207-221-2547<br>
> <br>
> <br>
> AP> asterisk-dev-bounces@lists.digium.com wrote on 03/27/2006 07:32:23
AM:<br>
> <br>
> >> Dear Clint,<br>
> >> <br>
> >> This situation and many other will be
solved in case that the<br>
> >> Asterisk CDR system is designed to record all events
(end to end<br>
> >> record of the call), not only the 1st and last end
point of the call.<br>
> >> I am able to do such CDR system and if
someone would like to help<br>
> >> me will be very helpful. I intend to name the new project
FCDR which<br>
> >> means Full Call Detail Records which will include all
possible events<br>
> >> like dial, hold, all kind of transfers, conferences,
call-end-reasons,<br>
> >> etc.<br>
> >> Any help and ideas?<br>
> >> <br>
> >> <br>
> >> Best Regards,<br>
> >> Miroslav Nachev<br>
> >> <br>
> >> <br>
> >> <br>
> >> CT> Hi Guys,<br>
> >> <br>
> >> CT> I posted this to the Users list but didn't get
a response. <br>
> >> CT> I'm hoping someone here can help me out.<br>
> >> <br>
> >> CT> <br>
> >> <br>
> >> CT> I'm writing an app that receives a call on an
incoming <br>
> channel (A), the<br>
> >> CT> caller negotiates through a series of prompts
and is transferred<br>
> >> to an outgoing<br>
> >> CT> channel (B) using the Dial cmd. That part works.<br>
> >> <br>
> >> CT> For billing I'd like to be able to charge
for the time that the<br>
> >> first caller<br>
> >> CT> is connected to the callee on channel
(B) so I can pass on my<br>
> >> own outgoing<br>
> >> CT> voip costs.<br>
> >> <br>
> >> CT> Can I do this? There doesn't seem to be a way
of capturing<br>
> >> CT> the ANSWERTIME of channel (B) from the<br>
> >> CT> channel (A) context of the dialplan. Or is there?<br>
> >> <br>
> >> CT> <br>
> >> <br>
> >> CT> Any suggestions would be greatly appreciated.<br>
> >> <br>
> >> CT> clint_in_sydney<br>
> >> <br>
> >> <br>
> >> <br>
> >> _______________________________________________<br>
> >> --Bandwidth and Colocation provided by Easynews.com
--<br>
> >> <br>
> >> asterisk-dev mailing list<br>
> >> To UNSUBSCRIBE or update options visit:<br>
> >> http://lists.digium.com/mailman/listinfo/asterisk-dev<br>
> <br>
> <br>
</font></tt>