[Asterisk-Dev] dev conf topic: better CDRs

Tom Dickenson voip at digitaldatabits.net
Fri Feb 25 12:47:06 MST 2005


Should base the Unique Identifier upon something tangible that will never
overlap Date / Vs Time + Kernel Core

----- Original Message ----- 
From: "Tilghman Lesher" <tilghman at mail.jeffandtilghman.com>
To: <asterisk at vanderdecken.com>; "Asterisk Developers Mailing List"
<asterisk-dev at lists.digium.com>
Sent: Thursday, February 24, 2005 12:33 PM
Subject: Re: [Asterisk-Dev] dev conf topic: better CDRs


> On Thursday 24 February 2005 12:44, Race Vanderdecken wrote:
> > Give me a break.
> >
> > I create a GUID and then attach the ANI and the DNIS to the GUID to
> > make it really easy read and to be unique.
> >
> > It makes a big CDR uniqueid but you can be damn sure that there will
> > never be an overlap.
> >
> > Even with 50 calls per second you are just not going to duplicate a
> > random GUID for a given date between you and the Carrier.
>
> That's nothing.  I use the kernel core file as my unique identifier.
> Sure, it creates a column that's 1000000000 characters long, but
> hey, it's unique, and it'll never repeat.
>
> Sarcasm aside, the point of a unique identifier is to have something
> that is a) (duh) unique, and b) easily indexed for fast lookup.  The
> longer that you make your unique identifier, the bigger the resulting
> index, which makes lookups slower.  We want to use the smallest
> possible unique identifier, not add fields willy-nilly until we have
> something that looks (but is not provably) unique, which is what you've
> done.
>
> The nice thing about using a unique identifier which is based upon
> small, discrete bits of information is that it's provably unique.  Even
> though unixtime will eventually loop, it will loop in a predictable way
> (every 136 years).  Using random data or a cryptographic hash will
> have collisions that are completely unpredictable.  When you have
> such a collision, it's either going to break your system or cause it to
> behave in unpredictable ways, and you're going to have no idea why.
> That's not a very good methodology for a communications system.
>
> -- 
> Tilghman
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>




More information about the asterisk-dev mailing list