Summary:	ASTERISK-03691: [patch] Standard UUID/GUIDs for CDR uniqueid
Reporter:	Michael Giagnocavo (aginamu)	Labels:
Date Opened:	2005-03-17 12:03:12.000-0600	Date Closed:	2011-06-07 14:05:17
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) cdr_csv_guid.diff.txt ( 1) cdr_guid_v3.diff.txt ( 2) cdr_guid.v4.diff.txt
Description:	This patch adds standard UUID/GUIDs from libuuid instead of just copying the channel ID. This a: guarantees uniqueness across all machines (assuming they have a MAC address) and b: allows the unique ID to be easily supported, as any decent database will have 16-byte GUIDs as a native datatype. ****** ADDITIONAL INFORMATION ****** Disclaimer on file.
Comments:	By: Olle Johansson (oej) 2005-03-17 12:21:25.000-0600 Will the expansion of the uniquid field break database support in CDRs, like the schema for ODBC, Mysql or SQLike? If so, you need to document that you have a larger field now. By: Michael Giagnocavo (aginamu) 2005-03-17 12:34:10.000-0600 MySQL: I highly doubt it, since MySQL doesnt ever cause errors. It just silently trashes data :). At any rate, I should document it. Where/how should I do so? By: Michael Giagnocavo (aginamu) 2005-03-17 13:28:34.000-0600 Perhaps its better if I create a new field on CDR: uuid_t guid. That way people must explicitally take advantage of it. Also, about the DB, in fact, the data should be stored as a 16-byte binary field and not a string, so it's more than a length extension. By: Michael Giagnocavo (aginamu) 2005-03-17 14:33:49.000-0600 The guid.v2.diff.txt contains the patch implemented as a separate uuid_t field on the cdr struct: guid. guid.diff.txt wasn't supposed to be uploaded. By: Kevin P. Fleming (kpfleming) 2005-03-17 17:31:59.000-0600 I think this should be wrapped in a CDR_LOG_UUID #ifdef, just like CDR_LOG_UNIQUEID is. By: Clod Patry (junky) 2005-03-19 10:07:38.000-0600 yes, cause i remark the uniqueid can have duplicate unique ids when 2 machines (are writing to the same database). If both of your machine is crashing at about the same time, then after the crashes, when they have the same number of calls at a time t. You'll get an error of duplicate Key (im using psql). If unique ids can be re-written for many machines, we'll be sure to not have duplicate keys, even in x machines world, writting to the same database. By: Michael Giagnocavo (aginamu) 2005-03-19 10:21:55.000-0600 kpfleming: The UniqueId isn't in an #ifdef, except in the individual CDR modules (and I don't patch those so as to maintain backwards compatability). Also, using #ifdefs shouldn't be a preferred solution since it adds more complexity to the system. Devs should go the extra mile (when it makes sense) and add a config option. junky: Precisely why I'm using GUIDs instead of trying to re-invent things. By: Kevin P. Fleming (kpfleming) 2005-03-19 10:27:17.000-0600 Yeah, you are right, currently the unique ID is always generated, but not necessarily logged. My concern here is that GUID generation is not instantaneous, and I don't want to add the extra CPU time to every call for every Asterisk server who doesn't care about them. In other words, this needs to be an option, defaulting to 'off'. By: Michael Giagnocavo (aginamu) 2005-03-19 10:46:03.000-0600 I created a loop that generates 1,000,000 UUIDs and ran it on a 2.4GHz machine. using time, it says it takes 0.68 seconds. That's about 1500 cycles per generation (of course, not counting the overhead to cache in that code). Just to compare, just opening and closing a file 1,000,000 times took 9.8 seconds. By: Mark Spencer (markster) 2005-03-19 12:02:01.000-0600 This would create a new dependency for Asterisk.  It should be optional.  Is there a way to make UNIQUEID use UUID if it's available and if not, use the existing system? By: Kevin P. Fleming (kpfleming) 2005-03-19 12:10:20.000-0600 I missed the "new dependency" thing too... dang. That means this will have to be a compile-time option, for sure :-) By: Michael Giagnocavo (aginamu) 2005-03-19 12:35:36.000-0600 OK, v3 now has the ifdefs for define CDR_GUID. By: Kevin P. Fleming (kpfleming) 2005-03-19 12:40:26.000-0600 The #includes need to be wrapped in #ifdef as well. By: Michael Giagnocavo (aginamu) 2005-03-19 12:55:51.000-0600 Yea, I knew I was missing something :\. OK, this should work then. By: Clod Patry (junky) 2005-03-19 17:42:10.000-0600 in cdr.c, i don't see any affectation, where it should be exactly? Plus, in cdr_pgsql.conf (or any CDR conf files), do we have to insert a new choice, like: uuid=no (default)??? Cause if we have the libs, i think that would be great if we can choose at any time if we want uniqueid as the current "form" or as a UUID. Plus, like i already suggested it, i think all infos related to CDR should be in cdr.conf, just many classes in that file like: [mysql] foo bar [postgresql] foo2 bar2 [csv] foo3 bar3 In a case like that, with all infos in 1 file, changing ( or add/remove) in cdr will be easier to make. By: Michael Giagnocavo (aginamu) 2005-03-30 14:11:05.000-0600 OK, I added support for cdr_csv to prove it works. I'll leave the other CDR backends to people who know them better :). By: Clod Patry (junky) 2005-03-30 14:18:22.000-0600 If mark wants it in HEAD, i can patch others. By: Tilghman Lesher (tilghman) 2005-03-30 16:29:30.000-0600 As noted on the list, libuuid is GPL, so we either need a license exception or a disclaimed implementation.  In addition, libuuid is not included on *BSD, so we still need a disclaimed implementation in utils.c. By: drmac (drmac) 2005-03-30 16:43:50.000-0600 someone just posted on the -dev list that the UUID library is the incorrect license and that it cannot be used with asterisk. The person also stated there is no UUID equiv on BSD. By: Kevin P. Fleming (kpfleming) 2005-03-31 13:45:08.000-0600 I think this bug needs to be suspended until we know that there is a usable, license-compatible UUID library available that will work on the major platforms that Asterisk runs on (Linux, *BSD and Solaris).