[asterisk-dev] Simple question...

Mon Mar 27 06:50:51 MST 2006

   Dear Andrew,

   We are thinking in the same way. In my opionion MySQL is good idea
where the data to be stored. The XML is not for database processing.
It is good for data transporting between different systems.
   Also my idea is like your: to store multiply records for one call
with UniqueID, sub-version-id and related-unique-id field. That's why
I need to summarize all kind of events that will handle which will
help me to determine the database-table structure and to take decision
from where and how to extract the needed info.
   I need from related-unique-id field because for example in one
Attended transfer you mix 2 independent channels. The situation is
similar for conferences and other.

   Best Regards,
   Miroslav Nachev

AP> I think you're on the right track with respect to the events
AP> related to calls.  Any change in a call's connection state, what
AP> caused that state, and what time the state change occurred.  I
AP> haven't studied the core code enough to know if that information
AP> is traced as a single object anywhere, but that would make the
AP> most sense.  

AP> The problem with logging in general, is that you get a great
AP> sequence of events on a call, but reporting from that is tricky.
AP>  People wants reports on the duration of some events from end
AP> point to the end point, but determining the start and end points
AP> is harder than you'd think.  Is it the time the connection
AP> happens, or when the call is dialed? Is "parked" time excluded or
AP> included?  These are going to be subject to the economic needs of
AP> the report, not any kind of programmer logic.  That means nearly
AP> any reporting software is going to have to do some kind of
AP> sequential scan and compile statistics as a pre-report job.    

AP> Given the above, the idea of each call getting a unique id
AP> and having each event tagged with that id and a timestamp is
AP> probably the most important first aspect.  From there, an external
AP> process which compiles the records in any number of ways becomes
AP> possible.   A sort of pseudocode way of looking at a call that
AP> makes sense to me could best be represented in a kind of xml style
AP> tree structure, though I don't believe this is a good way to STORE
AP> the data. 

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

AP> If you look at each of the nodes as having a timestamp,
AP> context, local and remote numbers, etc.,  it would be logically
AP> easy to get the whole call time, subject out time in the menu, add
AP> back time on the outbound dial or remote answered segments, etc. 

AP> Keep in mind that I am representing the data this way, but I
AP> do NOT support storing the call data for each call as an XML
AP> record.  XML is good for transferring data from one place to
AP> another but its a pretty wasteful and difficult to process storage
AP> format. 

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

AP> 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
 >>   
 >> 