[asterisk-users] Simple CDRs

[Asterisk Development Team]

Grey Man wrote:
> A single CDR should not be able to cover several Dial attempts or even
> multiple destinations within the same Dial attempts. If you think of
> Dial as just another application and of CDRs being designed to reflect
> the lifetime of a channel then things are simplified. If a Dial or any
> other dial plan application causes three channels to be created then
> that's 3 CDRs that will be generated. If the first Dial call fails and
> another one is made with another 3 destinations than that's another 3
> CDRs that will be generated.

I agree with this. The rule, clearly defined, should be "channel created 
and terminated; CDR created".

> If A tried to dial a group that consisted of 10 members then that's 10
> CDRs that should be generated. For those people that don't want
> unanswered CDRs they can be easily turned off with the configuration
> option. For those of us that want a CDR for every call which includes
> successful and unsuccessful call attempts we ge them.

I'll also agree here.

> I think with unanswered=no the desire would be to exclude any call
> with billsec=0. The disposition field is a descriptive field and not
> something that I think should be relied upon too heavily. Different
> channels may set the disposition field differently for eaxmple the SIP
> channel could get clever and set it to  "FAILED - 403 Forbidden" to
> reflect the SIP response code that caused the failure. That
> description would obviously not make sense for DAHDI.
> 
> I don't think it should be the case but if it looks like disposition
> is increasing the complexity of the design or implementation it could
> probably be dropped as it's not a critical CDR field and CEL will
> provide more information in that area anyway.

I'm a very agreeable person today. When Murf outlined the above, I was 
thinking that, if you have unanswered=no, then you don't want any CDRs 
other than what was ANSWERED. I like the billsec=0 though. That makes it 
quite clear, and isn't as complicated as parsing on disposition.

>>> - uniqueid: A GUID/UUID that cannot be changed and is critical for billing,
>> In my previous message, I proposed that we could add some config options
>> that would define uniqueid/linkedid behavior, let's get explicit:
>>
>> unique_append_ident=<string>
>>
>> The <string> would be appended to the unique id/linked id when it
>> goes "out the door"; This would allow you to tack on a system name
>> or ip or whatever to every uniqueid/linkedid as it goes into the db/log
>> file/whatever; if you had several systems logging to the same db,
>> you could guarantee that the id's were unique across systems that way.
>>
>> unique_append_uuid = yes
>>  would append the uuid (all 36 bytes of it)
>>  to the uniqueID/linkedid. This uuid is calculated once per Asterisk
>>  invocation;
>>
>> unique_append_uuid = per_channel
>>  would append the uuid (all 36 bytes of it)
>>  to the uniqueID/linkedid. This uuid is calculated once per
>>  channel created.
>>
>> Will this suffice?
> 
> I guess so but that seems to be a bit of overkill. The probability of
> a UUID clash are some astronomical figure so why not just generate the
> UUID when the CDR is created. I don't know what exactly what
> conditions you'd need to get such a conflict but at a minimum I
> suspect it's two servers with identical MAC addresses that generate
> the UUID at exactly the same tick on their real-time clocks. You'd
> have to work pretty hard to get those conditions and in my opinion
> appending a UUID to a UUID is not needed, a single UUID per CDR would
> be sufficient.

Actually I could see appending a 'servername' to the UUID as useful in a 
clustered environment. Every time I don't think I need to do that, I end 
up having to do it. And since this would be a configurable appendage, it 
shouldn't hurt anything.



Leif Madsen.
http://www.leifmadsen.com
http://www.asteriskdocs.org