[asterisk-dev] No unique identifier for CDR

[Atis Lezdins]

On Thu, Aug 27, 2009 at 3:54 PM, Tilghman
Lesher<tilghman at mail.jeffandtilghman.com> wrote:
> On Thursday 27 August 2009 07:33:28 Atis Lezdins wrote:
>> On Thu, Aug 27, 2009 at 11:59 AM, Nick Lewis<Nick.Lewis at atltelecom.com>
> wrote:
>> > Atis
>> >
>> > Thanks for describing the good work that is underway on CDR
>> >
>> > Regarding call_id, I am personally more concerned with distinguishing
>> > parts of a call than associating them. For call monitor recordings the
>> > system needs to be able restrict parties to reviewing only the parts of
>> > a call in which they participated. For example if a receptionist
>> > transfers a call to a CEO, the receptionist should not have access to
>> > the recording of the part of the call after the transfer. Only with a
>> > unique cdr identifier can this be restricted. (I appreciate the need to
>> > associate parts of a call with different channels from a call logging
>> > point of view though).
>> >
>> > I do not think that having a ResetCDR(w) increment held in a dialplan
>> > global variable comes to quite the same thing as a native CDR field. I
>> > feel that a CDR row should be able to be uniquely identified without
>> > recourse to application specific data such as the userfield. This is
>> > because a row id is something fundamental to the management of a data
>> > structure. Only by automating the generation of a row id within cdr.c
>> > can this be assured.
>> >
>> > If my proposed uniqueid + cdrinstance identifier for a CDR row is too
>> > focused on channels then how about a genuine atomic row id such as
>> > "cdrid" that is lock generated for every post_cdr (or batch equivalent)?
>>
>> As I mentioned before - uniqueid is not unique per CDR, it's per
>> channel. For example if You blind transfer a call, you should still
>> get the same uniqueid, but separate CDR for parent channel.
>>
>> I would like that "cdrinstance" (or rename it to "sequence") is
>> incremented each time when CDR with linkedid is written. That way -
>> You can easily get all linked CDRs by linkedid, and distinguish them
>> by combining linkedid+cdrinstance.
>
> Why not just create an autoincrement field in your database and use that
> as your per-record unique ID?

Did You mean "id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY"? Yes, it's
there, as MySQL needs primary key for performance, but it would be
quite a hassle to get it from dialplan - to link CDR to call records
etc.

Regards,
Atis

-- 
Atis Lezdins,
VoIP Project Manager / Developer,
IQ Labs Inc,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835