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