[asterisk-users] Simple CDRs

[Tilghman Lesher]

On Thursday 08 January 2009 22:24:45 Grey Man wrote:
> On Fri, Jan 9, 2009 at 3:48 AM, Steve Murphy <murf at digium.com> wrote:
> > My advise is not to. I have no prob with uuids, except that they are
> > 36 bytes, and overkill for uniqueness. linkedID + system name would be
> > totally sufficient; One glance at the linkedID will tell you immediately
> > what sys it came from, if you did that.
> >
> > But it's quite legitimate to want to use UUID's. I have no idea how much
> > processing power they take to be generated, probably not much. There's
> > pros and cons...
>
> I don't deal with UUIDs as a number or string I deal with them as a
> UUID (a UUID is a type in OO langauages). That's the point I'm trying
> to get across. Every modern high level language already has constructs
> to deal with UUIDs AND it's such a dead easy way to generate a unique
> id, it's one line of code. By making it a string or integer or
> something else you're making it harder for people to deal with in
> their billing engines and it's not actually making the field any more
> unique than it would be as just a UUID.

Not every modern high level language has that construct builtin, and C
certainly does not.  The point is that we'd need to build the functionality
of making a deterministic algorithm for producing a UUID.  For our methods,
using the servername is certainly one way to do that.

> I don't understand why you want to combine server name and/or a
> timestamp with the unique id? If a user wants to know or sort on
> server name then why not provide a dedicated field in the CDR for
> that?

It's a deterministic way of producing a Globally Unique Identifier, or at
least, unique enough for the purposes here.

> I'm not being anal here. I'm not the only one that has raised this and
> time and time again it's cropped up on the mailing list where users
> have been burnt because they relied on uniqueid being unique. Perhaps
> it would be worth soliciting views from the user list on what people's
> preference would be for the uniqueid field? Maybe there is a super
> efficient unique id generation approach that uses less than 36 bytes
> but what's going to cost the most: people's time in accommodating the
> super cleverness  in their many and varied systems (instead of a UUID
> that's well understood with existing constructs) or storing 36 bytes
> per CDR?

I think Steve is as interested as anybody else in achieving a solution, but
you're hand-waving when it comes to the establishment of a UUID.  There
is no such construct that we can use, but there are very deterministic methods
(which Steve has enumerated) for producing the required uniqueness.  And at
the end of the day, what you need is the assurance that the algorithm used is
indeed unique enough to produce no possible collisions.

-- 
Tilghman