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. No recognition of incoming calls

No recognition of incoming calls

Scheduled Pinned Locked Moved Support
27 Posts 2 Posters 659 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
    CTJackal
    wrote on last edited by
    #17

    Nicolas,

    Seem to be getting somewhere at last. If an agent logs into a queue via FOP2, then the CALLING number is shown as ringing the agent's extension and hence the pop-up works.

    If an agent logs into a queue via (queue number)* e.g. 803* or the agent is placed permanently into the queue via trixbox static agents, then it's the AGENT number which is shown as ringing the agent's extension, and hence no pop-up.

    Any thoughts?

    Carlos

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

      Not sure how is the agent-add macro doing its thing, you should look at the "queue show" output from the asterisk cli to see how are the agents added, and if they use Local/XXX@YYY, verify that the button configuration use extension=XXX and queuecontext=YYY. You can see that by running autoconfig-buttons-freepbx.sh. There must be a coincidence between extension/queuecontext in both the queue member and the button config so fop2 can match the inbound call as a queue member call.

      1 Reply Last reply
      0
      • C
        C
        CTJackal
        wrote on last edited by
        #19

        Hi Nicolas,

        Just had a further look and Trixbox adds to the queue:

        member=Local/500@from-internal/n,0

        when adding a static member. If I change this to:

        member=SIP/500

        then it works as expected. At least until Trixbox is relaoded and overwrites the change.

        Tried "queue show" and it gives Local/500@from-internal/n in both v2.6 and 2.8
        Also autoconfig-buttons-freepbx.sh gives:

        [QUEUE/803]
        type=queue
        extension=803
        label=Sales
        context=ext-queues
        queuecontext=from-internal
        extenvoicemail=*

        again in both v2.6 and 2.8

        To add yet more, setting the destination of an inbound route directly to an extension results in the CALLED extension being displayed against the extension in FOP2.

        Carlos.

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

          Look at the extension configuration in the buttons.cfg file, not the queue configuration, and see if they have the queuecontext set and to what value it is set.. it should be "from-internal", but maybe it is set to "from-queue". If that is the case, you must change the autoconfiguration button script to use the correct queuecontext for your setup.

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

            The thing is that as far as I know , FreePBX 2.6 or 2.7 introduced the from-queue context, so from-internal is used for older freepbx install.

            1 Reply Last reply
            0
            • C
              C
              CTJackal
              wrote on last edited by
              #22

              Yet more info Nicolas,

              Using 2 setups, one with static queue members (not working) and one with dynamic members (working), I've had a look at the output of fop2_server -X 15 and here are the major differences:

              Static:

              127.0.0.1 <- Event: Newchannel
              127.0.0.1 <- Privilege: call,all
              127.0.0.1 <- Channel: Local/500@from-internal-0f29;1
              127.0.0.1 <- ChannelState: 0
              127.0.0.1 <- ChannelStateDesc: Down
              127.0.0.1 <- CallerIDNum:
              127.0.0.1 <- CallerIDName:
              127.0.0.1 <- AccountCode:
              127.0.0.1 <- Uniqueid: 1290532841.6
              127.0.0.1 <- Server: 0

              Dynamic:

              127.0.0.1 <- Event: ChannelUpdate
              127.0.0.1 <- Privilege: system,all
              127.0.0.1 <- Channel: SIP/500-00000009
              127.0.0.1 <- Uniqueid: 1290532944.13
              127.0.0.1 <- Channeltype: SIP
              127.0.0.1 <- SIPcallid: 7fb80dba1efb090159448854183948a7@192.168.200.49
              127.0.0.1 <- SIPfullcontact: sip:500@192.168.200.37:5068;transport=udp
              127.0.0.1 <- Server: 0

              127.0.0.1 <- Event: ChannelUpdate
              127.0.0.1 <- Privilege: system,all
              127.0.0.1 <- Channel: SIP/500-00000009
              127.0.0.1 <- Channeltype: SIP
              127.0.0.1 <- SIPcallid: 7fb80dba1efb090159448854183948a7@192.168.200.49
              127.0.0.1 <- SIPfullcontact: sip:500@192.168.200.37:5068;transport=udp
              127.0.0.1 <- Peername: 500
              127.0.0.1 <- Server: 0

              127.0.0.1 <- Event: ExtensionStatus
              127.0.0.1 <- Privilege: call,all
              127.0.0.1 <- Exten: 500
              127.0.0.1 <- Context: ext-local
              127.0.0.1 <- Hint: SIP/500&Custom:DND500
              127.0.0.1 <- Status: 8
              127.0.0.1 <- Server: 0

              Further on we see the reason for the CID, i.e.

              Static:

              127.0.0.1 <- Event: Newstate
              127.0.0.1 <- Privilege: call,all
              127.0.0.1 <- Channel: SIP/500-00000006
              127.0.0.1 <- ChannelState: 5
              127.0.0.1 <- ChannelStateDesc: Ringing
              127.0.0.1 <- CallerIDNum: 500
              127.0.0.1 <- CallerIDName:
              127.0.0.1 <- Uniqueid: 1290532841.10
              127.0.0.1 <- Server: 0

              127.0.0.1 <- Event: Newstate
              127.0.0.1 <- Privilege: call,all
              127.0.0.1 <- Channel: SIP/501-00000007
              127.0.0.1 <- ChannelState: 5
              127.0.0.1 <- ChannelStateDesc: Ringing
              127.0.0.1 <- CallerIDNum: 501
              127.0.0.1 <- CallerIDName:
              127.0.0.1 <- Uniqueid: 1290532841.11
              127.0.0.1 <- Server: 0

              Dynamic:

              127.0.0.1 <- Event: Newstate
              127.0.0.1 <- Privilege: call,all
              127.0.0.1 <- Channel: SIP/500-00000009
              127.0.0.1 <- ChannelState: 5
              127.0.0.1 <- ChannelStateDesc: Ringing
              127.0.0.1 <- CallerIDNum: 07866676869
              127.0.0.1 <- CallerIDName: Trial: Stem Carl Marshall
              127.0.0.1 <- Uniqueid: 1290532944.13
              127.0.0.1 <- Server: 0

              127.0.0.1 <- Event: Newstate
              127.0.0.1 <- Privilege: call,all
              127.0.0.1 <- Channel: SIP/501-0000000a
              127.0.0.1 <- ChannelState: 5
              127.0.0.1 <- ChannelStateDesc: Ringing
              127.0.0.1 <- CallerIDNum: 07866676869
              127.0.0.1 <- CallerIDName: Trial: Stem Carl Marshall
              127.0.0.1 <- Uniqueid: 1290532944.14
              127.0.0.1 <- Server: 0

              It looks as though Asterisk is passing the CallerIDNum as the called extension! Any idea as to where to look in FreePBX to find where this may be generated?

              Carlos

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

                Hi Carlos,

                I am not sure where to look, but you might want to traverse the dialplan priority by priority in both cases from the asterisk full log.. quite difficult to do, but I do not see any other way to spot differences? When you refer to static vs dynamic, it is always with Local/XXX@YYY/n queue members?

                1 Reply Last reply
                0
                • C
                  C
                  CTJackal
                  wrote on last edited by
                  #24

                  Hi Nicolas,

                  No, the static queue agents show as Local/xxx@yyy/n either when added into the queue via Trixbox queues (same as FreePBX queues) or when added as dynamic using 803* to join queue 803. Both show this when looking at -X 15 output, i.e.:

                  Static:

                  127.0.0.1 <- Event: QueueMember
                  127.0.0.1 <- Queue: 803
                  127.0.0.1 <- Name: Local/500@from-internal/n
                  127.0.0.1 <- Location: Local/500@from-internal/n
                  127.0.0.1 <- Membership: static
                  127.0.0.1 <- Penalty: 0
                  127.0.0.1 <- CallsTaken: 0
                  127.0.0.1 <- LastCall: 0
                  127.0.0.1 <- CallAnswered: 0
                  127.0.0.1 <- TalkTime: 0
                  127.0.0.1 <- Status: 1
                  127.0.0.1 <- Paused: 0
                  127.0.0.1 <- Server: 0

                  Or when added via 803* :

                  127.0.0.1 <- Event: QueueMember
                  127.0.0.1 <- Queue: 803
                  127.0.0.1 <- Name: Local/500@from-internal/n
                  127.0.0.1 <- Location: Local/500@from-internal/n
                  127.0.0.1 <- Membership: dynamic
                  127.0.0.1 <- Penalty: 0
                  127.0.0.1 <- CallsTaken: 0
                  127.0.0.1 <- LastCall: 0
                  127.0.0.1 <- CallAnswered: 0
                  127.0.0.1 <- TalkTime: 0
                  127.0.0.1 <- Status: 1
                  127.0.0.1 <- Paused: 0
                  127.0.0.1 <- Server: 0

                  However when added as a queue agent using FOP2, we get:

                  127.0.0.1 <- Event: QueueMember
                  127.0.0.1 <- Queue: 803
                  127.0.0.1 <- Name: SIP/500
                  127.0.0.1 <- Location: SIP/500
                  127.0.0.1 <- Membership: dynamic
                  127.0.0.1 <- Penalty: 0
                  127.0.0.1 <- CallsTaken: 0
                  127.0.0.1 <- LastCall: 0
                  127.0.0.1 <- CallAnswered: 0
                  127.0.0.1 <- TalkTime: 0
                  127.0.0.1 <- Status: 1
                  127.0.0.1 <- Paused: 0
                  127.0.0.1 <- Server: 0

                  Carlos.

                  1 Reply Last reply
                  0
                  • C
                    C
                    CTJackal
                    wrote on last edited by
                    #25

                    Nicolas,

                    This issue looks similar to one posted earlier which I've just noticed:

                    View Post 328

                    Did you manage to find an answer to that one?

                    Carlos.

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

                      Hi Carlos,

                      I already said it before, if the AMI events says the calleris is "INCORRECTNUMBER", fop2 will display that as the callerid number. Regarding the queue members, you can configure fop2 to use the same type as FreePBX by setting the queuechannel for the button.

                      So from what you say it seems that the problem is with Local channels, it is not static vs dynamic, but Local vs SIP.

                      Please capture the output from fop2_server -X 1 while doing a call which shows the incorrect clid and send me the capture privately so I can review it here and see if I can find the issue.

                      Best regards,

                      1 Reply Last reply
                      0
                      • C
                        C
                        CTJackal
                        wrote on last edited by
                        #27

                        Nicolas,

                        Thanks for all you help on this one. I'll add this section even though you sorted it out privately since there may be others with the same issues with Trixbox 2.8.x

                        /etc/asterisk/manager.conf has the recommended lines of:

                        read=system,call,log,verbose,command,agent,user,originate
                        write=system,call,log,verbose,command,agent,user,originate

                        Changing this to:

                        read=all
                        write=all

                        solved the problem.

                        Many thanks for all your hard work.

                        Carlos.

                        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