True Unique ID

[ajax1515]

I've read in a few other posts (http://www.eflo.net/VICIDIALforum/viewt ... =3&t=27191) that unique_id may not always be "unique" which is concerning for me considering the volume of our calls and out needs for tracking.

I notice in looking at the call_log that there is also a column called called_code that has a format like this :V2151408300000004432

My question is simply this: In tracking individual dials, is the unique_id reliable in a multi server environment and if not, is the called_code an appropriate substitute?

[mflorell]

We do have several clients using caller_code or call_id or call_code or callerIDname(it's called different things in different places) as a uniqueid on multi-server systems, and it works pretty well.

[ajax1515]

Ok, thanks, that's good to know. I'm still curious though, how could the unique id in the call_log ever not be unique, it's a MySQL primary index which means it should have to be unique, what am I missing here?

[mflorell]

The call_log is not used for reporting purposes at all, it's minimally used for log processing as well. uniqueid is unique per server, and it is extremely rare even on a multi-server system for it to be duplicated. It is possible in some Asterisk builds to have the servername appended to the uniqueid, which can allow the uniqueid to be truly unique even on a multi-server system.

[ajax1515]

When you say multi-server systems in this particular case you are only referring to systems with more then 1 database server correct?

[mflorell]

No, systems with more than one Asterisk server.

[ajax1515]

I feel like I'm being a bit of a pain about this but I'm still having trouble conceptualizing how this works.

In the `asterisk` MariaDB database which is only located on the database server, the `call_log` table has as it's PRIMARY index `uniqueid` with values such as '1448488017.0'. A PRIMARY index is required by MySQL to be unique, so if what you're saying is true (obviously it is since you made it) then how does the system rectify itself when Asterisk_Server_1 creates a uniqueid that is the same as one created by Asterisk_Server_2 and in trying to INSERT it gets the Error Code: "1062. Duplicate entry 'xxxx' for key 'PRIMARY'"?

Second part of my question which dove tails from the first is: by what method (programatically) are the uniqueid's generated by the Asterisk Servers?

Thanks for your patience with me.

[mflorell]

The standard uniqueid within asterisk is generated in 2 parts:
1. the epoch time of the server (the number of seconds since January 01, 1970)
2. the internal Asterisk channel counter (the number of new channels created since Asterisk was started up to that point)

It is very unlikely that at the same second, the same number of channels will be used on two different asterisk servers on the same cluster. If this does happen, it would result in some logging issues, but nothing catastrophic.

On most running Vicidial systems you will see MySQL errors about duplicate key attempts on the call_log table. These errors are caused by the multiple levels of logging that exists to catch all Asterisk call events by Vicidial. On most systems, 100% of these errors can be ignored, since they only indicate that a redundant call_log entry was attempting to be inserted by one of the logging processes.

[ajax1515]

Got it, thank you for the information, it all makes sense now.

[ajax1515]

For those of you using newer asterisk builds, the setting that will allow you to prepend a server name to the uniqueid is found in asterisk.conf

[mflorell]

Just keep in mind, if you do that you will have to make every database field that contains the uniqueid big enough to handle that information.

[ajax1515]

Right, I had not considered that, I'm simply prepending the server number, so it's only adding 2 characters, the number, and a hyphen, making the id's look something like 2-142342543.234, but if you were to add a larger prepended value such as "asterisk-dial-server-1" then that would become a serious problem, thanks for pointing that out.