Different CDR records for blind or attended transfer

Hi,

Been trying to wrap my head around this one, and just not getting it (possibly too tired, brain no likey)…

Asterisk 11 with FPBX 2.11

Manager has a perl script which does some analysis on call records, he is interesting in only inbound/outbound external calls, and internal on-net calls get ignored.

The problem I have is that the CDR records generated for a blind xfer versus an attended xfer are different. Here’s an example;

Attended xfer to extension
"0429123456",“222”,“21”,“17”,“ANSWERED”,"2015-06-03 15:05:56"
“222”,“225”,“14”,“11”,“ANSWERED”,“2015-06-03 15:06:08”

Blind xfer to extension
"0429123456",“222”,“9”,“7”,“ANSWERED”,"2015-06-03 15:08:54"
“0429123456”,“225”,“11”,“8”,“ANSWERED”,“2015-06-03 15:09:04”

So, as we can see in an attended xfer, call comes into 222 (reception), then 222 does an attended xfer to 225. Because the second part of the call generates a CDR showing the call from 222 - 225, this is ultimately disregarded as an on-net call.

Looking at the blind xfer, we see the CDR behaviour which is desirable - you can see the call come into 222 then you can also see the external call connected to 225 - thus, the stats reflect that 225 took an external inbound call.

Is it possible to get the CDR’s for an attended xfer to actually show the real connected party CID, instead of showing the CID of the internal extension which initiated the xfer?

I think what’s confusing me is both types of transfers are ultimately a SIP REFER sent to the transferee, right?

As far as I can read, an attended xfer sends an INVITE to the xfer-destination (for the consult) before sending a REFER to the transferee - but ultimately, it is still the transferee that receives the REFER then sends an INVITE to the xfer-destination to setup the last part of the call.

Seeing as though, in my eyes, they seem essentially the same I don’t know why the CDR records would be different.

I have trustrpid=Yes and sendrpid=Remote-Party-ID set on both extensions, and canreinvite=no.

I’m not having any luck at all… I also posted to asterisk-users mailing list and got no response. Is the CDR system a FreePBX addition to Asterisk? Is there another system to record CDR’s that I could try?

Really would like to get to the bottom of this because it does mess up our reporting…

Further to this, I’ve done some more testing. My original post was using Asterisk 11, FPBX 2.11 with chan_sip.

I tested with Asterisk 13, FPBX 12 and chan_pjsip and the CDRs are completely different.

Attended Transfer (101 ring 102, 102 does attended xfer to 103)
“102”,“103”,“5”,“ANSWERED”,“2015-07-09 11:22:16"
“101”,“102”,“16”,“ANSWERED”,“2015-07-09 11:22:06"
“101”,””,“10”,“ANSWERED”,“2015-07-09 11:22:20”

So we can see the first entry is the announce part (where 102 rings 103 to announce the caller being xferred). Then, when the transferred call is complete we get the bottom two entries. The first one (101 -> 102) looks like the TOTAL time of the call, and the second part looks like the time between 101 -> 103. But, there is no destination CID in the third entry!?

Here’s a blind transfer (101 rings 102, 102 blind xfer to 103):
“101”,“102”,“5”,“ANSWERED”,"2015-07-09 11:30:55"
“101”,“103”,“8”,“ANSWERED”,“2015-07-09 11:30:59”

This looks perfect, you can clearly see the two parts of the calls and the src and dst CIDs accurately represent real life.

I’m getting closer - if only the third entry of the attended xfer showed “101”,“103” as src and dst then this would be solved for me (our managers only care about volumes and not time spent on calls).

So it seems I have gotten this to work with Asterisk 13 and using the channel and dest channel CDR variables, instead of just the src and dst variables.

Here’s an example output;
PJSIP/102-0000003b,PJSIP/103-0000003c,“102”,“103”,“4”,“ANSWERED”,“2015-07-09 12:15:01"
PJSIP/101-00000039,PJSIP/102-0000003a,“101”,“102”,“11”,“ANSWERED”,“2015-07-09 12:14:54"
PJSIP/101-00000039,PJSIP/103-0000003c,“101”,””,“9”,“ANSWERED”,“2015-07-09 12:15:03”

101 rings into 102 (as seen in line 2), then 102 announces call to 103 (as seen in line 1), then the call is between 101 and 103 (as seen in line 3).

Even using the channel variables in Asterisk 11, the “third” line (the part of the call where the caller is speaking to the transfer destination) it still shows 102 as source and 103 as dest, when in that part of the call in real life 101 is talking with 103.