Hi guys
Fairly new here. We’re a small to medium sized installation (about 800 seats total in about 20 branches countrywide), running on 1.8.11.0 - 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
wiki.asterisk.org/wiki/display/AST/CDR+Fields
[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]
My questions:
-
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!
Regards
Stefan
- That depends on how you define “calls”. I can’t remember where I saw documentation on linkedid recently, but it explains the difficulty that different people have different meanings for one call, and also describes the strategy it uses to set the linkedid field.
There are some operations, like abandoned enquiry legs of attempted attended transfers from SIP phones that will never provide Asterisk with enough information to associate the legs.
- backends means things like the CSV file writer. I would guess that some of the lesser used, database based ones, particularly if “community supported” have not been updated.
Why did you post this on a discussion forum, when it seems to be a support question?
Thank you for the reply.
Because I’m pretty sure that it isn’t a problem or bug in Asterisk itself, but rather in my capacity to understand and implement what is required to be able to use the linkedid, peer account, and sequence CDR fields, to link legs of a CDR for a transferred call.
From there the post here, hoping that more experienced users might have an idea or have implemented the use of linkedid specifically. Also, since the docs explicitly stated “certain” back-ends, the idea was to find out -which- back-ends, and implement then them to try and start making use of linkedid in my CDR records.
This followed a week or two of experimentation and googling, with zero results so far… from there the fallthrough to try and find out if somebody else managed to use linkedid.
But apparently I’ve got the cat by the tail completely, so I guess I’ll just start looking elsewhere. Or, I’m making an extremely basic mistake (due to inexperience, incompetence, or whatever), which I freely admit…
Apologies if my post was inappropriate…? Should this rather be directed to the support forum then?
linkedid is a new feature, and may not be much used. The general advice, for some time, has been to use call event logging, rather than CDRs. I’d suggest that most people here with a need to associate records, have already created a solution.
You probably need to look at wiki.asterisk.org/wiki/display/ … cification
However note that this applies to the upcoming Asterisk version 12. Prior to that CDRs were being deprecated
I am pretty sure that the reference to backends simply means that some backends do not know about the linkedid field in the internal structure and simply do not output it. The easiest way of finding which is probably simply to try them. The second easiest is probably to look at their source code.
It is possible that no CDR backend currently supports linkedid, although the internal support framework for CDRs does, in supported versions.
Hi David
Again, thank you for taking the time to reply.
I did go and experiment a bit more and it seems that the adaptive ODBC CDR backend does what I need. It seems to support adding any number of custom fields, which at first glance looks like exactly what I need.
All now just depends on whether any custom fields are persistent, e. g. staying inviolate from the initial call in the dialplan to the CDR app that goes and sets the custom CDR field, to the time (after several transfers every which way) that the call is hung up and the CDR gets closed out and written through to the DB…
I’ll just need to resurrect my proper testing setup and see if it does behave that way consistently.
More research also seems to indicate that at the end of the day it might be better to just give up on CDRs and use CEL instead.
If CDRs are to be deprecated soon, that might be the only way to go.
Thank you for your comments, much obliged!
Regards
Stefan