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.
  • 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