[asterisk-users] CDR Design

Freddi Hansen fh at danovation.dk
Wed Dec 3 11:08:25 CST 2008


I agree with  regs at kinetix.gr we need the events to create the final CDR.
I will not waste list space on a long but just show you 2 reallife 
examples that can't be handled both within the same 'fixed' way of 
generating CDR's as we do now.The new system that 's proposed would 
handle both  just with trimming  of the config file.
A:
Asterisk used on a shared premium number where we pay the companies 
that's chosen in the menu.
The Company chosen can make  internal transfers, the point is that  
A-line time  for the whole session
is 'billable'.
B.
Voip service provider that allows transfers.
B-line time is billable - A pays for leg A to B, when a transfer occurs 
then the leg from B to C must be paid by B

It's difficult to impossible to maintain that kind of logic in the 
Asterisk core.
Asking for 'one' CDR is essentially the same as asking for hardcoded 
cdr-event logic in the core -
I would certainly prefer the way that Murf is proposing.  

If we use Dbus,socket or spawn external program (like with agi) that's 
just an implementation detail but the architecture should be right.

Freddi


> Billing and logging should not be confused theoretically - I agree. 
> But in practice,
> the logging of the calls (not other events of the system) IS used for 
> billing purposes.
> The start and finish time is not enough for many (I not that it is not 
> enough for me).
>
> The accountcode is not enough for me either. From my CDRs I have to 
> extract all the
> information about which provider tried-and-failed or 
> tried-and-succeeded to terminate
> the call. So I need the terminator's info in the CDRs. This is the 
> only way that I can monitor
> what my providers charge me (and believe me, never take for granted 
> that your provider charge
> you with pre-agreed rates, mistakes happen :)). Also, having the 
> terminator's data in the CDR is
> the only way that I can calculate metrics such as ASR, ACD, mean PDD etc.
> And I can't imagine taking all this info from a logging module that 
> mixes CDR log events with
> other ones (hardware events, user agent registrations, etc.)
>
> Since there is no agreement on WHAT to log and since we have the 
> option to put a lot of info
> in the CDRs I think the right way to do it is provide the capability 
> of every single detail that COULD
> be logged and let the end user choose WHAT to log through the 
> configuration. I cannot understand
> tha benefit of a minimal/fixed/non-flexible CDR logging capability 
> when can have the flexibility to
> go from minimal to complex depending on a configuration entry in a 
> proper configuration file.
>
> P.S. Sometimes I wonder if I am the only one in the VoIP world that 
> finds terminator information in the
> CDRs useful (including failed calls).
>
> P.S. Sometime we use the term "billing" only for customer billing 
> processes which nowadays is incorrect
> or insufficient. "Billing" in today's demanding VoIP business means :
>
> 1. Customer Billing : we all know what that is
>
> 2. Provider CDRs cross-check : as I said above, you have to know what 
> your provider charges you in order
> to catch mistakes and in order to able to produce profit/loss reports.
>
> 3. QoS metrics : ASR, ACD, PDD to name a few. These cannot be 
> calculated without proper termination info
> from the CDRs. I see LCR modules being introduced now and then in the 
> asterisk community but they all seem
> a little useless if the above metrics cannot be extracted from the 
> CDRs. What is the benefit of having a low cost provider
> in your LCR if its ASR equals to 0.0001 %? and how can you measure its 
> ASR if the terminator's info (both failed and successful)
> is not in the CDRs?
>
>
> Andrew Thomas wrote:
> It seems to me that we are confusing billing and logging here.  Call
> billing only really needs the start and finish (like we get now) - but
> proper call logging requires all steps.
>
> Do we leave CDR's as they are (for billing purposes) and have a separate
> 'event' driven log for call logging?  Or do we change the CDR structure
> to accommodate logging as well?
>
> Personally, a separate 'event' log seems preferable to me as this keeps
> existing billing platforms useable.  It just means the logging programs
> will need to be re-written to look at a new database for events.
>
> I know we have the AMI - but that puts out a lot more information than
> is needed for simple logging (and requires something to prune and store
> the events in a database of some sort).
>
> Any thoughts?         
>     
> Andrew Thomas
> Technical Services Manager
> DataVox Ltd
> Saddleworth Business Centre
> Huddersfield Road
> Delph, Oldham
> OL3 5DF    
>



More information about the asterisk-users mailing list