[asterisk-users] Simple CDRs

[Anthony Francis]

Tilghman Lesher wrote:
> On Friday 09 January 2009 01:14:37 Grey Man wrote:
>   
>> On Fri, Jan 9, 2009 at 6:37 AM, Tilghman Lesher wrote:
>>     
>>> 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.
>>>       
>> I've been hand-waving for over a year about the CDRs so you're right
>> in that respect.
>>
>> There are no contructs in C for threads either but they are an
>> abstraction heavily used by Asterisk, likewise linked lists etc etc.
>>     
>
> Correct, and WE'VE BUILT THOSE CONSTRUCTS.  They are directly within
> the Asterisk code, and they may be viewed quite easily.
>
>   
>> At the end of the day whoever writes the code will implement it how
>> best they see fit. I'm merely pointing out that there is already a
>> very straight forward, standard way of generating unique ids that is
>> used extensively and has a probability lower than 1 in 10^36 of
>> generating a collision. In my opinion the methods discussed of
>> incorporating a server name or timestamp into some kind of sequence to
>> create a unique id are pretty fragile.
>>     
>
> That's not entirely true.  For example, part of the algorithm for the Java
> UUID (I wasn't able to determine the entire algorithm) is to use the server
> machine's MAC address.  That is part of a deterministic method of avoiding a
> collision.  Note that the Asterisk Call Unique ID is itself very deterministic
> in avoiding collision within a single machine.  It is impossible for a
> uniqueid, once generated, to conflict with another on the same machine, when
> referring to different calls.  That's not to say that there can't be multiple
> CDRs with the same unique ID, of course, but they all refer to the same call.
>
> We are entirely interested in DETERMINISTIC methods of uniqueness, not random
> and hope-for-the-best.  Given a truly random generator, it is possible for the
> same number to come up 100 times in sequence.  That is part of what random
> means.  It may be statistically unlikely, but it is just as likely as any
> other sequence.  When it comes to fragility, using a random number for a UUID
> is NOT deterministic and MAY produce collisions.
>
>   
I may be over simplifying but I would have a serial number object that 
gets incremented anytime it is called and will be set to 0 at start-up. 
I would then use it to generate a UUID like this:
MAC.serialid.64bit timedate

Not only would this number be perfectly universally unique (as long as 
you dont falsify the MAC) but from a record standpoint it gives you 
easily parsable information in a single field, the id of the call for 
referential integrity, the machine that generated the uuid, the calls 
created since start at the time of the call creation, and the exact time 
of creation with microseconds.

Just IMO.

-- 
Thank you and have any kind of day you want,

Anthony Francis
Rockynet VOIP