FOP2 Community Forum

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.

Hello Nicolas,

i want to forward all calls on Saturday between 14 - 22 o'clock to a mobil phone.
How can i configurate this in FreePBX?
A time condition and time group are already exist.
Can you tell me what kind of destination i need to configure if time matches?

Thanks & Regards,
Florian

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.

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.

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!