[asterisk-users] CDR Design

[JD]

Ironically, much of the disagreement comes from everyone being *right*. 
Seriously.

Philisophically, Asterisk is a tool chest, not a true product. As an 
analogy, if one wants to sit, one can either buy a chair or get a 
saw/hammer/nails/lumber and build one. Both will do the job. Asterisk is 
more like the saw/hammer/nails/lumber.

Two wit:

Andrew: you are right. For folks wanting a simple AMA-style billing CDR, 
it would be ideal if we leave that in the system as is. Even if it is 
broken for many other uses of Asterisk. I don't need it myself, but I 
see your point.

regs: you are right. For folks wanting more advanced billing or 
intercarrier compensation, a standard CDR isn't going to cut it. We need 
to pull in N events, tied together by some kind of unique ID. Customized 
programming would then do the analysis and bill generation. Steve's 
system should help make that custom programming easier.

Grey man: you are right. The direction of a call leg is easy to 
determine from the point of view of asterisk. I suspect other folks 
however, think of it differently. Some would think of a call coming from 
a customer CPE to asterisk as an outbound call. Inbound to asterisk, 
yes. But outbound for billing purposes. But if you are using Asterisk 
for xyz, then the pattern of logic may differ yet again. So, while AMA 
CDRs may look at it in a specific way, Steve's flexible system should 
probably leave it up to each programmer writing their unique billing 
analysis software.

To sum up, personally I still think the current AMA-style CDRs should 
remain in place. Perhaps touched up a bit. Or not. Steve's system should 
be in addition to the AMA-style CDRs and called something other than 
CDRs. (CDRplus?)

But, I'm not doing the coding, so take what I say with a grain of salt.

John

Freddi Hansen wrote:
> 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    
>>
>>     
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
>