Issue with Intra-company transfer (No link to call recording in Queuemetrics)

[rkimberling]

Hello,

I am trying to find a solution to an issue where a customer calls into our TFN, they dial 3 or 4 to go straight to our Touchtone / IVR system, then they transfer from Touchtone IVR back to any given queue. When the call is transferred out from the IVR to the queue, then there is no call recording available in Queuemetrics. Where there is normally a link to the .wav file listed next to "IVR Selection" in Queuemetrics call detail, looking at these calls there is no link to the recording. It seems that the file association is broken when they transfer from IVR -> queue.

For some reason it creates two call records. The wrong one gets associated with the call in QM.

An example:

CDR shows this one call as two call records: 1406921904.1213530 and 1406921904.1213531. The recording is linked to 531. When we go to look at the full log, full log has no record of 531.

[root@pbxha2 asterisk]# grep 1406921904 full
[2014-08-01 12:38:24] VERBOSE[31236][C-00073e22] pbx.c: -- Executing [s@macro-user-callerid:1] Set("Local/1142@from-queue-00031724;2", "TOUCH_MONITOR=1406921904.1213530") in new stack
[2014-08-01 12:40:28] VERBOSE[31236][C-00073e22] pbx.c: -- Executing [s@macro-user-callerid:1] Set("Local/1142@from-queue-00031724;2", "TOUCH_MONITOR=1406921904.1213530") in new stack
[2014-08-01 12:40:40] VERBOSE[31236][C-00073e22] pbx.c: -- Executing [s@macro-user-callerid:1] Set("Local/1142@from-queue-00031724;2", "TOUCH_MONITOR=1406921904.1213530") in new stack
[2014-08-01 12:40:40] VERBOSE[31236][C-00073e22] pbx.c: -- Executing [8004@ext-queues:35] QueueLog("Local/1142@from-queue-00031724;2", "8004,1406921904.1213530,NONE,DID,8774081999") in new stack

The only workaround we have found is to search for and get the call from CDR Reports in FreePBX admin. (This solution doesn't work well for our Supervisors). I need to fix things so that when a Supervisor pulls up a call detail in Queuemetrics, they can get to the file recording like normal instead of having to dig through CDR reports.

Queuemetrics info:
Software release:   Loway QueueMetrics - 14.03.3
B: 4836 2014-04-03 13:24
Operating System:   O.S.: Linux - Ver: 2.6.32-220.13.1.el6.x86_64 - amd64
Java Runtime:   Version: 1.6.0_22
Vendor: Sun Microsystems Inc.
Class Version: 50.0
Java Home: /usr/local/queuemetrics/jdk1.6.0_22/jre
System path:   /usr/local/queuemetrics/tomcat/webapps/queuemetrics/WEB-INF
Storage type:   SQL Storage (Partition: P001)
Loway TPF:   Version: TPF 229/P B:66
Language pack:   V:2014-03-31 10:20
System time:   Java Time: 2014-09-14 16:32:59
Java Time Zone: America/Los_Angeles
MySQL Time: 2014-09-14 16:32:59.0
MySQL Time is aligned with Java Time

FreePBX Admin:
PBX Firmware:   2.210.62-1
PBX Service Pack:   1.0.0.0

[mirkox]

Hello,

when a call enters in the PBX Asterisk will give it a call_id; usually it also save recording with that ID in the filename (with several other information); so QueueMetrics will look for filenames with the same call_id. It is possible the when the call is transferred again from IVR to the queue the call obtains a new call_id.

Would be possible to get the records generated in queue_log for an entire call cycle?

Thanks
Mirko

[rkimberling]

Thanks Mirko!,

As requested here's the entries from queue_log following a test call where I started at voice recognition system (IVR external to Asterisk) and transferred back out to our CS Queue. More detailed explanation of the call flow below that.

This is the call coming into the PBX and transfer over to voice recognition (Ext 1248) on the dialplan
(1410806237.479329)
1410806255|1410806237.479329|8003|NONE|DID|866889XXXX
1410806255|1410806237.479329|8003|NONE|ENTERQUEUE||503407XXXX|1
1410806256|1410806237.479329|8003|Local/1248@from-queue/n|CONNECT|1|1410806255.479339|1
1410806330|1410806237.479329|8003|Local/1248@from-queue/n|COMPLETECALLER|1|74|1

At the point when the customer dials 0 then 4 to go back to Main menu level 2, it starts the new call record. It's an intracompany transfer, but it shows the call above is completed and a "new" call starts at this point.

This is the call from the Queuemetrics call detail record that doesn't have a recording link:
(1410806255.479340)
1410806312|1410806255.479340|8004|NONE|DID|866889XXXX
1410806312|1410806255.479340|8004|NONE|ENTERQUEUE||503407XXXX|1
1410806315|1410806255.479340|8004|SIP/2151|CONNECT|3|1410806312.479362|1
1410806331|1410806255.479340|8004|SIP/2151|COMPLETECALLER|3|16|1

Looking at the above, we found how it is creating two call records. Here is a detailed list of what happens from the moment they call in, transfer to this voice recognition system and back to the main menu to reach customer service.

1: Customer calls TFN 866-889-XXXX
2: Call goes to custom destination Inbound2cApp. This routine will look at the last 5 digits of CLID and send them to the appropriate menu.
3: Inbound2cApp sends call to Main Menu level 1.
4: Customer dials 4, this puts them in queue 8003 which sends them to the next available extension on the voice recognition system (An IVR that is external to Asterisk). In this test call I did today the destination was extension 1248.

NOTE: Extension 8003 is set to not record as this would take up too much disk space.

5: The customer does what they need on voice recognition, then dials 0 + 4 to transfer back out from there over to Main menu level 2. This is set to "Intra-company transfer" in Asterisk so it will retain the customer's original CLID.
 
NOTE: Before they reach Main menu level 2 it sends them to extension 9820. 9820 is a custom extension that forces it to record the call. (We can then pull this recording from CDR reports) Without this the call will not record.

6: From Main menu level 2, the customer dials 4 to get to queue 8004.
7: At this point, the customer is connected to agent at SIP extension 2151.

What it's doing is:
The first part of the call where the customer is on the voice recognition system is 1410806237.479329. This one has the needed call recording associated to it.

When they reach an agent at ext 2151 it starts a "new call" which is 1410806255.479340. This is the call from Queuemetrics call detail that has no recording associated to it.

So what's happening is when it transfers back from voice recognition system to Main menu level 2, it creates a new call record (.479340). The call recording is still associated with the first call record (.479329). The second call record (.479340) has no recording associated with it. By the time the Supervisor goes to pull up a recording of the agent in Queuemetrics, there is no recording that they can see.

[QueueMetrics]

What I would do is to store the unique-id of the main leg into a call variable, and use that to set up the name for the recording in the second leg (that will have a different unique-id).

So:
- the main leg of the call has uniqueid of 1234.123
- we store it in a variable
- when we reach the second queue, we set the recording name to "olduniqueid-step2"

So you would have recordings like:

1234.123.wav  (fro the main leg)
1234.123-step2.wav (for the second leg)

It's not pretty but it should work.

[gopal2k]

Its a late reply, but if you are using MixMonitor then you can use this "Set(AUDIOHOOK_INHERIT(MixMonitor)=yes)" after Mix Monitor line, this will have the recording even the call is transferred internally. For me it works.

Regards,
Gopal.