Re: [reSIProcate] True uniqeness of Helper::computeCallID()
Thanks Byron.
What are your thoughts on using a UUID type of algorithm as found in
http://www.ietf.org/rfc/rfc4122.txt
?
David
CC: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
From: bcampen@xxxxxxxxxxxx
Subject: Re: [reSIProcate] True uniqeness of Helper::computeCallID()
Date: Wed, 27 Sep 2006 20:30:48 -0500
To: mrdatman@xxxxxxxxxxx
Hrm. Just some preliminary fiddling with the probabilities (alas, my installation of octave is hosed) makes it look _extremely_ likely that you would get repeats within a data set of 2 million (before the hash, we aren't talking about hash collisions here). Just throwing in a timestamp or a counter would make the pre-hash token effectively unique, or you could go with a longer string of random hex (16 should bring it down to a vanishingly small probability). Maybe we could have Helper::computeCallId() take an optional int parameter that would specify the length of random hex the caller wants to go in the hash?
Best regards,
Byron Campen
Has anyone had issue with the true uniqueness of Helper::computeCallID().
I've used the value returned from this to push about two million calls into cdr records....however I am discovering that some new calls are attaching themselves to old cdr records.......
The algorithm used in Helper.cxx is the base64 of md5 of hostname + Random::getRandomHex(8)
My guess is there is a good chance that you will get a random number twice.
Does anyone have an idea on how this can be improved or a quick code snippet for me to create a truly unique callid?
Thanks in advance,
David
Share your special moments by uploading 500 photos per month to Windows Live Spaces Share it!
_______________________________________________
resiprocate-devel mailing list
Stay connected with the news, people, places and online services that matter to you on Live.com
Try it!