Fairly new here. We’re a small to medium sized installation (about 800 seats total in about 20 branches countrywide), running on 126.96.36.199 - this is for reasons of stability and several pieces of software we developed ourselves to manage our installation.
We have lots of transfers taking place, and we are having problems with the “uniqueid” fields changing for a call that is transferred, as it moves to using / being connected to new channels / call legs, sometimes over divergent technologies (DAHDI -> SIP / SIP -> SIP service provider -> remote branch DAHDI / DAHDI -> PSTN -> remote branch DAHDI / etc.)
E. g. we CANNOT use uniqueid to uniquely identify one “call” that may be spread over several CDRs, if the call is repeatedly transferred. This uniqueid CDR behaviour is documented well, and I therefore started looking into the use of “linkedid” in the CDR record, which, as far as I can see, will always be the same ACROSS transfers (unlike “uniqueid”). This is based on
[i]In 1.8 and later
In some CDR backends, the following fields may also be supported:
linkedid: a unique identifier based on uniqueid. Unlike uniqueid, but spreads to other channels as transfers, dials, etc are performed peeraccount: the account code of the bridged channel sequence: a field that can be combined with uniqueid and linkedid to uniquely identify a CDR[/i]
Am I correct in stating that if I can use linkedid, it will remain the same ACROSS all transfers / legs for all CDRs for one logical “call”?
What are “some CDR backends” - this is pretty vague. E. g. can I, or can’t I, use a linkedid in CDRs??
[b]How can I use the linkedid field with the FreeTDS engine? We’re running FreetDS to MSSQL quite fine for “normal” CDR fields, but in the DB, all CDRs just have null in the linkedid field / column, eg. it never gets filled… so I guess FreeTDS is NOT a “certain backend”?[b]
I’ve tested with AdaptiveODBC to MySQL, and it DOES fill the linkedid field, but I was only able to make single calls to test. I noticed that the uniqueid and linkedid in this scenario were identical. Can I therefore assume if I use a DIFFERENT CDR backend (e. g. AdaptiveODBC) and NOT FreeTDS, that CDRs will START with the uniqueid = linkedid, --but-- as the uniqueid varies with successive transfers, the linkedid will stay at the original uniqueid=linkedid value? And I can therefore use the linkedid to unambiguously join on in SQL to know what CDRs for each transfer leg “actually” belong together??
We’re already using the userfield CDR field to try and do the required joining, but there are other new requirements to pass and store information in this field in our logic setup here which means “after the fact / after the CDR has been written to the DB” the userfield contents may be changed by us, so we need some other completely unambiguous way to associate all CDRs occuring for a single “logical” call, using a field other than userfield… eg. linkedid??
ANY help/comments appreciated!