[Asterisk-Dev] Real UniqueIDs (GUID/UUID) for CDRs

Stefan Reuter srt at reucon.net
Wed Mar 30 14:49:47 MST 2005


On Wed, 2005-03-30 at 15:31 -0600, Michael Giagnocavo wrote:
> Well, we could just dump the GUID into the uniqueid field, but it is 32 in
> length, and I'd have to increase it to 33 (minimum) or 37 (preferred, to
> keep nice format). I figured increasing a field like that would probably
> cause a ton of problems throughout the code that relies on it being 32 (say,
> database fields). Maybe someone who knows more can chime in here...

As I understand the current UniqueID algorithm it uses a Hi-Lo approach
with the high part being the startup time (or something similar - I dont
recall exactly) and the low part being incremented by 1 each time a new
id is generated.
This approach has the advantage that it is really fast.
If performance is a requirement for the UniqueId generation we could use
the GUID for the high part and continue to use the incremented uniqueint
for the low part.

The increased field length might in fact be an issue i did not think of
but is also present in the CDR only approach (at least when considering
storing CDRs in a database).
I don't think asterisk itself has a problem with this as the bristuff
patches from Junghans already use an extended UniqueId inclunding the
process id and a configurable node id.

=Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20050330/15cb22c0/attachment.pgp


More information about the asterisk-dev mailing list