[asterisk-dev] Simple question...

[Andrew Pollack]

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. 

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. 

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.

<call>
        <initiated>
                <menutree>
                        <outbound dial>
                                <remote answered>
                                <remote disconnected>
                        </outbound dial>
                </menutree>
        <disconnected>
</call>

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.

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.

---
Andrew Pollack
Northern Collaborative Technologies
207-221-2547


Miroslav Nachev <miro at space-comm.com> wrote on 03/27/2006 07:52:33 AM:

>    Dear Andrew,
> 
>    Thank you very much for the supported letter.
>    Let's start the projects with one discussion about which events we
> need. Then to sumarize and think out in advance the data structure
> where will be stored this information and from where this information
> will be taken. After that I will start design and develop the project.
> 
>    From which detailed records you need?
> 
> 
>    Best Regards,
>    Miroslav Nachev
> 
> 
> AP> Miroslav, 
> 
> AP> This sounds like an excellent addition to Asterisk.  As
> AP> someone who has made a living for twenty years producing
> AP> applications for customers I can tell you without question that
> AP> the most important and at the same time most frequently overlooked
> AP> part of the projects are their ability to produce highly detailed
> AP> and customized reports.  I once had a company CIO (Chief
> AP> Information Officer) tell me that while it was true his users
> AP> wanted lots of bells and whistles, he didn't care if I built the
> AP> thing out of crayons on waxpaper as long as he could get reports
> AP> out of it that justified the expenditure. 
> 
> AP> If Asterisk is to continue to grow into the mainstream
> AP> marketplace -- and I have no doubt that it will -- highly detailed
> AP> reporting is one of the most important additions to be made.  Good
> AP> luck on your project. 
> 
> AP> ---
> AP>  Andrew Pollack
> AP>  Northern Collaborative Technologies
> AP>  207-221-2547
> 
> 
> AP> asterisk-dev-bounces at lists.digium.com wrote on 03/27/2006 07:32:23 
AM:
> 
>  >>    Dear Clint,
>  >> 
>  >>    This situation and many other will be solved in case that the
>  >> Asterisk CDR system is designed to record all events (end to end
>  >> record of the call), not only the 1st and last end point of the 
call.
>  >>    I am able to do such CDR system and if someone would like to help
>  >> me will be very helpful. I intend to name the new project FCDR which
>  >> means Full Call Detail Records which will include all possible 
events
>  >> like dial, hold, all kind of transfers, conferences, 
call-end-reasons,
>  >> etc.
>  >>    Any help and ideas?
>  >>    
>  >> 
>  >>    Best Regards,
>  >>    Miroslav Nachev
>  >> 
>  >>   
>  >>  
>  >> CT> Hi Guys,
>  >> 
>  >> CT> I posted this to the Users list but didn't get a response. 
>  >> CT> I'm hoping someone here can help me out.
>  >>  
>  >> CT>  
>  >>  
>  >> CT> I'm writing an app that receives a call on an incoming 
> channel (A), the
>  >> CT> caller negotiates through a series of prompts and is transferred
>  >> to an  outgoing
>  >> CT> channel (B) using the Dial cmd. That part works.
>  >> 
>  >> CT> For billing  I'd like to be able to charge for the time that the
>  >> first caller
>  >> CT> is connected  to the callee on channel (B) so I can pass on my
>  >> own outgoing
>  >> CT> voip  costs.
>  >> 
>  >> CT> Can I do this? There doesn't seem to be a way of capturing
>  >> CT> the  ANSWERTIME of channel (B) from the
>  >> CT> channel (A) context of the dialplan. Or is  there?
>  >>  
>  >> CT>  
>  >>  
>  >> CT> Any suggestions would be greatly  appreciated.
>  >> 
>  >> CT> clint_in_sydney
>  >> 
>  >>   
>  >> 
>  >> _______________________________________________
>  >> --Bandwidth and Colocation provided by Easynews.com --
>  >> 
>  >> asterisk-dev mailing list
>  >> To UNSUBSCRIBE or update options visit:
>  >>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20060327/fdc4124f/Message.html