[Asterisk-Dev] dev conf topic: better CDRs
Race Vanderdecken
asterisk at vanderdecken.com
Thu Feb 24 11:44:33 MST 2005
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
More information about the asterisk-dev
mailing list