pickup call function cause dummy entry in database

Giggzz · June 2012

Hello,

we have a serious problem with our FOP2, every time when an agent picks up a call from the queue the system only writes a dummy entry in the cdr database. See this excerpt:

[2012-06-14 14:31:28] VERBOSE[14961] pbx.c: -- Executing [s@macro-dial-one:39] Set("SIP/SIP_Trunk_Alcatel-00004663", "CONNECTEDLINE(name,i)=Heiner Arndt") in new stack
[2012-06-14 14:31:28] VERBOSE[14961] pbx.c: -- Executing [s@macro-dial-one:40] Set("SIP/SIP_Trunk_Alcatel-00004663", "CONNECTEDLINE(num)=8045") in new stack
[2012-06-14 14:31:28] VERBOSE[14961] pbx.c: -- Executing [s@macro-dial-one:41] Set("SIP/SIP_Trunk_Alcatel-00004663", "D_OPTIONS=trM(auto-blkvm)I") in new stack
[2012-06-14 14:31:28] VERBOSE[14961] pbx.c: -- Executing [s@macro-dial-one:42] Dial("SIP/SIP_Trunk_Alcatel-00004663", "SIP/8045,"",trM(auto-blkvm)I") in new stack
[2012-06-14 14:31:28] VERBOSE[14961] netsock2.c: == Using SIP RTP TOS bits 184
[2012-06-14 14:31:28] VERBOSE[14961] netsock2.c: == Using SIP RTP CoS mark 5
[2012-06-14 14:31:28] VERBOSE[14961] app_dial.c: -- Called 8045
[2012-06-14 14:31:28] VERBOSE[15010] pbx.c: -- Executing [dummy@fop2-dummy:1] Answer("Local/dummy@fop2-dummy-22ea;2", "") in new stack
[2012-06-14 14:31:28] WARNING[15011] pbx.c: The application delimiter is now the comma, not the pipe. Did you forget to convert your dialplan? (QueueLog(8260|1339676989.78263|NONE|NOTABANDON|0|0|0))
[2012-06-14 14:31:28] WARNING[15011] app_queue.c: QueueLog requires arguments (queuename,uniqueid,membername,event[,additionalinfo])
[2012-06-14 14:31:28] VERBOSE[15010] pbx.c: == Spawn extension (fop2-dummy, dummy, 1) exited non-zero on 'Local/dummy@fop2-dummy-22ea;2'
[2012-06-14 14:31:28] VERBOSE[14961] app_dial.c: -- SIP/8045-00004665 is ringing
[2012-06-14 14:31:30] VERBOSE[14961] app_dial.c: -- Connected line update to SIP/SIP_Trunk_Alcatel-00004663 prevented.
[2012-06-14 14:31:30] VERBOSE[14961] app_dial.c: -- SIP/8045-00004665 answered SIP/SIP_Trunk_Alcatel-00004663

6. 2012-06-14 14:31:28 Local/dumm... dummy ANSWERED 00:00
7. 2012-06-14 14:19:04 Local/dumm... dummy ANSWERED 00:00
8. 2012-06-14 14:19:04 Local/dumm... dummy ANSWERED 00:00
9. 2012-06-14 14:18:20 SIP/SIP_Tr... 7129 "Manfred Jellemitzky" <7129> s ANSWERED 00:35
10. 2012-06-14 14:18:17 SIP/8045-0... 8045 8045 5459 NO ANSWER 00:43
11. 2012-06-14 14:18:15 SIP/SIP_Tr... 5647 "Dirk Duesterwald" <5647> s ANSWERED 00:11

this results in a false reporting and we really need to fix this out.
Thankyou for your Help!

nicolas · June 2012

Hi,

look at /etc/asterisk/extensions_override_fop2.conf for the fop2-dummy context, it should look like this:

[fop2-dummy]
exten => dummy,1,Answer
exten => dummy,2,Wait(1)
exten => dummy,3,Hangup

Add a NoCDR entry

[fop2-dummy]
exten => dummy,1,Answer
exten => dummy,2,Wait(1)
exten => dummy,3,NoCDR()
exten => dummy,3,Hangup

Reload the dialplan and try again. Let me know if the cdrs are not written then.

Best regards,

Giggzz · June 2012

Hi,

thank you for the fast answer but unfortunately your suggestions did not fix the problem.
Maybe I should descripe the problem more detailed. We would like to have the ability to get as much data as possible out of every call as we already do but not from the pickup calls. As I described bevore the pickup incidents only generate dummy entries. How can we fix this matter?

Thanks for your Help.

Regards, Florian.

nicolas · June 2012

The fix should work, but I copied the priorities wrong, there are two "3" priorities , use 4 for the hangup or just n for all except the 1st one. That MUST work, as the cdr you copied is listing the dummy entry that you see there.

You can also edit FOP2Callbacks.pm , look for fop2-dummy there, you will see a block checking for the AMI "LEAVE" command, at the end it returns @allreturn, just comment the previous line, that will prevent FOP2 from firing up that command:

            $return = "Action: Originate\r\n";
            $return .= "Channel: Local/dummy\@fop2-dummy/n\r\n";
            $return .= "Application: QueueLog\r\n";
            $return .= "Data: $queue,$uniid,NONE,NOTABANDON,0,0,0\r\n";
            $return .= "Async: true\r\n";
            $return .= "\r\n";

            #push @allreturn, $return;
            return @allreturn;
        }

Notice the # before the push line.

Giggzz · June 2012

Hi and thanks for your help.

In the Log we have the following warning:

[2012-06-20 16:33:09] WARNING[3987]: pbx.c:1402 pbx_exec: The application delimi                                          ter is now the comma, not the pipe.  Did you forget to convert your dialplan?  (                                          QueueLog(8240|1340202758.0|NONE|NOTABANDON|0|0|0))
[2012-06-20 16:33:09] WARNING[3987]: app_queue.c:5735 ql_exec: QueueLog requires                                           arguments (queuename,uniqueid,membername,event[,additionalinfo])
  == Spawn extension (fop2-dummy, dummy, 1) exited non-zero on 'Local/dummy@fop2                                          -dummy-117c;2'

My FOP2Callbacks.pm

$return = "Action: Originate\r\n";
            $return .= "Channel: Local/dummy\@fop2-dummy/n\r\n";
            $return .= "Application: QueueLog\r\n";
            $return .= "Data: $queue|$uniid|NONE|NOTABANDON|0|0|0\r\n";
            $return .= "Async: true\r\n";
            $return .= "\r\n";

            push @allreturn, $return;
            return @allreturn;
        }

I've changed the code to "$return .= "Data: $queue,$uniid,NONE,NOTABANDON,0,0,0\r\n";"
Like this:

$return = "Action: Originate\r\n";
            $return .= "Channel: Local/dummy\@fop2-dummy/n\r\n";
            $return .= "Application: QueueLog\r\n";
            $return .= "Data: $queue,$uniid,NONE,NOTABANDON,0,0,0\r\n";
            $return .= "Async: true\r\n";
            $return .= "\r\n";

            push @allreturn, $return;
            return @allreturn;
        }

after applying the changes above I've restartet the Asterisk Server but the error still occurs
It seems like my changes won't affect anything at all cause as you can see the entries are still in one database column (Dummys):
8260|1340348662.3752|NONE|NOTABANDON|0|0|0

To be more precisely, we want the same grade of information we gain from any normal incoming call as for the pickup calls. Currently the pickup calls only generate dummy entries with useless information.

Can you help me?

Regards, Florian.

nicolas · June 2012

Please do what I said, comment the push line. That way, there will be no command being sent to asterisk, so it does not matter if it has a syntax error or whatever happens with it , it won't be sent. And it will not generate a queue_log entry, a cdr entry, NOTHING. Just comment the line I said.

Best regards,

Giggzz · August 2012

Hi,

that was not what i want.
I don't want no Dummy entries, I only want the Call Informations when I pick up a call manuell.
This informations are not in the cdr when we pick up a call, its only a dummy in the cdr without usefull informations about the call.

It looks like this:

|| *calldate* || *clid* || *src* || *dst* || *dcontext* || *channel* || *dstchannel* || *lastapp* || *lastdata* || *duration* || *billsec* || *disposition* || *amaflags* || *accountcode* || *uniqueid* || *userfield* ||

|| 2012-08-20 13:36:57 ||  ||  || dummy || fop2-dummy || Local/dummy@fop2-dummy-ea84;1 ||  || QueueLog || 8240,1345462510.3843,NONE,NOTABANDON,0,0,0 || 0 || 0 || ANSWERED || 3 ||  || 1345462617.3845 ||  ||

I think here is only one comma or pipe in my FOP2Callbacks.pm wrong.

Could you please check this again?
Do you need any more informations? I hope I was able to formulate my problem-now understandable, is not always so clear in English for me.

nicolas · August 2012

FOP2 adds an entry in the queue_log file by using a Local channel to to so. That Local channel will generate a dummy cdr with no useful information, as it is not a real call. It has the duration of the "dummy" call, and it will not inherit nor show anything else about the real call being picked up or not.

So, it is impossible to have that dummy entry showing anything meaningful about the real call. The Local channel lives just for a few seconds and dies and nothing else. This is how asterisk works. It is not a fop2 problem or issue, it is just the way it is in asterisk.

Commenting the fop2callback file will not generate the NOTABANDON entry in queue_log and it will not fire that dummy local channel to write such line. So you won't see anything in the cdr nor in the queue_log file, just like a regular call pickup from a phone (that will log an ABANDON line in queue_log because the call was forcefully removed from the queue and not served to an agent).

There is nothing more to do, either you have the NOTABANDON and dummy CDR, or none.

Best regards,

pickup call function cause dummy entry in database

Comments