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. checkdir passing bad variables

checkdir passing bad variables

Scheduled Pinned Locked Moved Support
8 Posts 2 Posters 97 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.
  • C
    C
    chrisgg
    wrote on last edited by
    #1

    So I got everything working properly, but something has changed. The variables never get set for the callerid and callername anymore.

    I get this in my logs now when a call runs the checkdir.php.

    /fop2/checkdir.php?poptype=connect&clidnum=undefined&clidname=undefined&exten=275&fromqueue=Sales&UNIQUEID=1332695254.28713
    
    [trix asterisk]# grep 1332695254.28713 queue_log
    1332695277|1332695254.28713|1010|NONE|ENTERQUEUE||"SalesNOT FOUND" <1235551212>
    

    The event_log for the above example (with the phone number changed)

    Is there anything I should be looking for or a setting somewhere that would cause it to be "undefined"

    We use your call-stats, and all the callerID and callerNumbers are there perfectly fine.

    Our checkdir.php is your example pretty much for the variables.

    
    function custom_popup($ALLVAR) {
    
            $clidnum   = $ALLVAR['clidnum'];
            $clidname  = $ALLVAR['clidname'];
            $fromqueue = $ALLVAR['fromqueue'];
            $exten     = $ALLVAR['exten'];
    
    1 Reply Last reply
    0
    • N
      N
      nicolas
      wrote on last edited by
      #2

      Hi,

      You might want to check the manager debug to see what callerid and name are passed to the AgentConnect event. I have just tested it locally and callerid is passed fine, also the new option to pass variables (eventwhencalled=vars) works ok too.

      So, start fop2_server in manager debug mode:

      service fop2 stop
      cd /usr/local/fop2
      script capture.log
      ./fop2_server -X 3
      

      (do your calls, wait for an agent to be connected to a call then stop the session)

      ctrl-C
      exit
      

      Inspect the capture.log, search for AgentConnect and check the data there.

      Best regards,

      1 Reply Last reply
      0
      • C
        C
        chrisgg
        wrote on last edited by
        #3

        The variable doesn't even exist in the AgentConnect, its set in the AgentCalled though.

        Sorry I guess I really don't know how its being passed since its not in that Event. I don't know, we have a ringall system in place if that makes any difference. So it rings all channels, until someone picks it up.

        Can you explain more on this new option you mentioned? eventwhencalled=vars

        127.0.0.1       <- Event: NewCallerid
        127.0.0.1       <- Privilege: call,all
        127.0.0.1       <- Channel: SIP/xxxxxxx-xxx
        127.0.0.1       <- CallerIDNum: 1235551212
        127.0.0.1       <- CallerIDName: SalesNOT FOUND
        127.0.0.1       <- Uniqueid: 1332788687.31688
        127.0.0.1       <- CID-CallingPres: 0 (Presentation Allowed, Not Screened)
        127.0.0.1       <- Server: 0
        
        127.0.0.1       <- Event: AgentCalled
        127.0.0.1       <- Privilege: agent,all
        127.0.0.1       <- Queue: 1010
        127.0.0.1       <- AgentCalled: Local/275@from-internal/n
        127.0.0.1       <- AgentName: Local/275@from-internal/n
        127.0.0.1       <- ChannelCalling: SIP/xxxxxxxx-xxx
        127.0.0.1       <- DestinationChannel: Local/275@from-internal-9301;1
        127.0.0.1       <- CallerIDNum: 1235551212
        127.0.0.1       <- CallerIDName: SalesNOT FOUND
        127.0.0.1       <- Context: ext-queues
        127.0.0.1       <- Extension: 1010
        127.0.0.1       <- Priority: 19
        127.0.0.1       <- Uniqueid: 1332788687.31688
        127.0.0.1       <- Server: 0
        
        127.0.0.1       <- Event: AgentConnect
        127.0.0.1       <- Privilege: agent,all
        127.0.0.1       <- Queue: 1010
        127.0.0.1       <- Uniqueid: 1332788687.31688
        127.0.0.1       <- Channel: Local/275@from-internal-9301;1
        127.0.0.1       <- Member: Local/275@from-internal/n
        127.0.0.1       <- MemberName: Local/275@from-internal/n
        127.0.0.1       <- Holdtime: 105
        127.0.0.1       <- BridgedChannel: 1332788805.31785
        127.0.0.1       <- Ringtime: 6
        127.0.0.1       <- Server: 0
        
        
        1 Reply Last reply
        0
        • N
          N
          nicolas
          wrote on last edited by
          #4

          I forgot about this, sorry. The callerid number and name are set prior to that event, it could be set on:

          Event: Newstate
          With Ringing state

          or the Event: MemberStatus
          if you have eventmemberstatus=yes in the queue configuration.

          And some other situations, a Link event, a Callerid event, etc. So, inspect a little bit up your log and look for those, when the callerid is set, the callerid. If you set debug level to 15 ( -x 15 ), you will see the commands sent to the web client, look for the commands clidnum and clidname that are passed, and then the manager event just above those.

          1 Reply Last reply
          0
          • C
            C
            chrisgg
            wrote on last edited by
            #5

            It isn't passing it at all, the only one I see is "fromqueue" to the web client. I have pretty much given up at this point, I am no debugger, and to be honest this isnt critical enough to hire someone to look at it. The logs make no sense to me what so ever. There is no clidnum or clidname being passed anywhere. eventwhencalled is set to yes on all queues.

            I haven't changed anything and it used to work fine, I figured it would of been something simple. However I appreciate all your support, and I hope someone can get something out of your explanations on this in the future by reading our post here.

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

              It is still working fine, perhaps your manager events are being filtered. Do you have "all" permissions in /etc/asterisk/manager.conf file read and write lines ?

              1 Reply Last reply
              0
              • C
                C
                chrisgg
                wrote on last edited by
                #7

                read = all
                write = all
                writetimeout = 1000
                eventfilter=!Event: RTCPSent
                eventfilter=!Event: RTCPReceived
                eventfilter=!Event: VarSet
                eventfilter=!Event: Cdr
                eventfilter=!Event: ExtensionStatus
                eventfilter=!Event: ChannelUpdate

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

                  Do you have eventmemberstatus=yes in your queue configuration? Try toggling it and see if that makes a difference.

                  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