[Asterisk-Dev] dev conf topic: better CDRs

[Race Vanderdecken]

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.

Race "The Tyrant" Vandederdecken



-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Tilghman
Lesher
Sent: Wednesday, February 23, 2005 6:23 PM
To: Asterisk Developers Mailing List
Subject: Re: [Asterisk-Dev] dev conf topic: better CDRs

On Wednesday 23 February 2005 15:56, Chris Parker wrote:
> On Feb 23, 2005, at 3:25 PM, Matthew Boehm wrote:
> > Since uniqueid is generated from time(), the probability of 5 (or
> > more) asterisk servers being in perfect microsecond sync with
> > eachother seems highly unlikely. Agreeded? But still,
> > mathematically it is possible that two
> > calls on two different machines end at the same time and 1 failes
> > to write
> > to database because of UNIQUE constraint. I'd hate to see an entire
> > server
> > blowup from that.
> >
> > I was thinking of adding something that MySQL uses when doing
> > replication.
> > You assign a unique 'serverid' to each server's config. Could you
> > add that
> > to cdr_*.conf for each machine; then use that id in the uniqueid
> > calculation?
> >
> > Something worth exploring?
>
> Since RADIUS has solved a lot of this, it might be wise to look at
> how in the RADIUS accounting world ( which has the same problems with
> a unique-id not being globally unique ) this is handled.
>
> In particular, FreeRADIUS ( http://www.freeradius.org/ ) and the
> rlm_acct_unique module.  It creates an MD5 unique hash from user
> configurable ( at run-time ) attributes, which can be used to get a
> lot closer global unique value.

That's lovely, but MD5 is not guaranteed to be unique (and it wasn't
designed to be unique, only to be a cryptographic hash), given a set of
inputs.  Over time, the probability of a collision increases.

Currently, we have a 2 integer method, which is guaranteed to be
machine-unique:  unixtime and instance increment, which, as long as
the daemon isn't constantly restarting, is fine.  To add network
uniqueness, the addition of a third integer should be sufficient:  the
32-bit integer representation of the IP address.  Oddly, that's 96 bits,
32 less than MD5, yet it's guaranteed to be unique for at least the next
30 years.

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