Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

FOP2 Community Forum

  1. Home
  2. Support
  3. pickup call function cause dummy entry in database

pickup call function cause dummy entry in database

Scheduled Pinned Locked Moved Support
8 Posts 2 Posters 287 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G
    G
    Giggzz
    wrote on last edited by
    #1

    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

    1.  2012-06-14 14:31:28 	Local/dumm... 			dummy 	ANSWERED 	00:00
      
    2.  2012-06-14 14:19:04 	Local/dumm... 			dummy 	ANSWERED 	00:00
      
    3.  2012-06-14 14:19:04 	Local/dumm... 			dummy 	ANSWERED 	00:00
      
    4.  2012-06-14 14:18:20 	SIP/SIP_Tr... 	7129 	"Manfred Jellemitzky" <7129> 	s 	ANSWERED 	00:35
      
    5. 2012-06-14 14:18:17 	SIP/8045-0... 	8045 	8045 	5459 	NO ANSWER 	00:43
      
    6. 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!

    1 Reply Last reply
    0
    • N
      N
      nicolas
      wrote on last edited by
      #2

      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,

      1 Reply Last reply
      0
      • G
        G
        Giggzz
        wrote on last edited by
        #3

        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.

        1 Reply Last reply
        0
        • N
          N
          nicolas
          wrote on last edited by
          #4

          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.

          1 Reply Last reply
          0
          • G
            G
            Giggzz
            wrote on last edited by
            #5

            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.

            1 Reply Last reply
            0
            • N
              N
              nicolas
              wrote on last edited by
              #6

              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,

              1 Reply Last reply
              0
              • G
                G
                Giggzz
                wrote on last edited by
                #7

                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.

                1 Reply Last reply
                0
                • N
                  N
                  nicolas
                  wrote on last edited by
                  #8

                  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,

                  1 Reply Last reply
                  0

                  Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                  Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                  With your input, this post could be even better 💗

                  Register Login
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                  • Login

                  • Don't have an account? Register

                  • Login or register to search.
                  Powered by NodeBB Contributors
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • World
                  • Users
                  • Groups