[Asterisk-Dev] dev conf topic: better CDRs

[Tilghman Lesher]

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