I have an issue that has been plaguing me recently.
I’ll give you the scenario that occurs:
A (e.g. 07XXXXXXXXX) calls in to B (e.g. 1XXX)
B then performs an assisted transfer (via the preset transfer key on their phone) to C (e.g. 2XXX)
A is then transferred through to C
The above works as expected at top level; the call is successfully transferred and A and C are able to talk. The issue arises once the call has finished. When I go to check the CDRs that have been created for the above event, it seems like it does three things:
Create a record within the CDR database for the entire length of the call ((A > B) + (B > C) + (A > C))
Create a record within the CDR database for B > C
Create a record within the CDR database for A > C
It’s fine that it doesn’t create a record for A > B as this isn’t really required. The only problem that I have with the above is that the third record is attributed to the person who was initially called. Here’s an example of some CDRs reflecting the above:
As you can see, the first two records are fine. It’s when it comes to the third one that the problem occurs. It’s still attributing the DST to User A instead of User C whom is the actual DST of the third record. This means that any time that has been spent on the phone by User C talking to User A after they’ve been transferred by User B is attributed to User B.
I’ve also completed a transfer using the Asterisk transfer (*2) and this has the same results as the above. I was concerned that the problem was only occurring due to the way that the handsets were transferring calls when pressing the preset “Transfer” button as I’ve read that they tend to be programmed to perform different actions and send different signals to the SIP server than a regular Asterisk transfer so attempting to do the same but using Asterisk’s built-in transfer shortcode was my way to make sure that this wasn’t the case.
If you have any ideas/thoughts on the above or need me to clarify anything, please let me know.
Looking into it further, it seems like the above isn’t quite the case.
The system creates two CDRs for a transferred call, one for A > B and one for A > C. It doesn’t account for B > C but as previously said, this isn’t important.
The weird thing about this all is that the two CDRs that are created differentiate in billsec and duration etc. but they both have the same unique ID… is this how the system is supposed to handle transfers? I can’t then differentiate between the two records as the thing that kept them unique is no longer that!
I can’t think of why it would be duplicating the unique ID… it seems very odd to me!
Yes, I understand that part but I pipe the information taken from the recording to a seperate server to deal with call times etc. so I use the unique ID as an identifier for the call itself. The reason for this is because there shouldn’t be any duplicates of that record present and it allows me to call the record directly once the call has ended using the Post Recording script. Is there perhaps another field of the CDR that you know of that is unique per record?
On the one hand, you’d expect the database to be (at least) 1NF. On the other, this is Asterisk, and not a DBMS.
In practice, because of things like multiple possible entry points for data capture, the Call Data Records aren’t (in fact) guaranteed to be unique. The primary key for the tuple includes several of the fields and should be unique within that. So, if there was one, the Primary Key for the record would actually something like Source + Destination + Time + Channel + one or two other fields.
The “Unique ID” is the foreign key entry to the other items associated with the record (which includes the call recording). Note that there is (often) and one-to-many relationship from the call recording to the CDR data, since a single recording could be the amalgamation of several different concurrent call paths - a call to a ring group, for example, will have a CDR for each extension that’s ringing, but the recording for that part of the call will always be the same, since the recording is running for all of the ring-group calls at the same time. Once upon a time, the Unique ID was actually an optional field that you had to recompile Asterisk to even get collected.
I haven’t looked lately, but the unique ID used to be the time of the call (in something like seconds or milliseconds since the Epoch) concatenated onto an auto-incrementing “call number” (the decimal point part) since the PBX was restarted. The time stamp is taken from the beginning of the recording stream, so the UID should always only point at one recording. I wrote a system (a long time ago) that managed recordings for a call center and used the “data” in the UID to manage a lot of that stuff.
I wish I had a better (or at least, less confusing) answer for you.
Cheers very much for that, Dave. You’ve cleared up a lot of things and even cleared up some things that I didn’t even realise needed clearing up!
For the purpose of identifying the call itself, do you think it may be worth while to create my own key which would just contain an amalgamation of some of the information stored within the CDR? I understand that there’s always going to be a chance that a duplicate could be present (all-be-it, very unlikely…). I feel like if I do the above, I’ll be able to differentiate the calls from one another without using the Unique ID as the calls themselves do consist of independent duration and billsecs.
