Member
Last active 6 years ago
Sometimes agents in 1 queue get calls that need to be sent to a different queue. With extension & ring groups transferring that call is easy in FOP2. They just highlight and transfer. With queues that doesn't seem so simple because you have to decide if you show the queue or not.
Lets say we have an agent who is a member of QUEUE1. They answer a call and find out that caller should have went to QUEUE2. This agent isn't a member of QUEUE2. Their FOP2 login doesn't show them QUEUE2. Why not? Well, mostly because the notifications for queue activity (chimes, flashing, text-to-speech, etc) trigger for ALL queues the agent has visible in FOP2, even if they aren't currently a member of that queue. Creating restrictions in FOP2 manager handles any permissions issue that we might have so we can restrict if the user can pickup the call, pause agents, etc. But getting constant aural and visual notifications for queues you aren't a member of can become very distracting and annoying.
Is there any way to do this that I'm missing? What I think would be really nice would be something similar to ring groups but for queues. A second window that you can create that just provides the list of queue numbers. No agent list, callers in queue, etc. This way you could publish this to ALL users.
Google gave me the following translation for the post above;
I have checked that the plugin that allows to answer calls by sending a SIP notify is only prepared for chan_sip. If Pjsip is used, the action is Pjsipnotify. Is it possible to adapt it? The parameters are the same (in the case of Yealink), only the Action changes.
Action: PJSIPNotify
ActionID: <value>
[Endpoint:] <value>
[URI:] <value>
Variable: <value>
I wanted to say that I noticed the same. PJSIP extensions can't use the answer button and I'd like to see this fixed.
Also, I'm personally having issues with yealink T46 phones with the latest firmware (and older firmware). Even using chan_sip the answer button hasn't worked for me. However T22P (now discontinued) work fine when using chan_sip. I must be missing something because I'd expect the T46 to handle this.
Well, still having 1 problem. Call Pickup from a queue on the remote PBX doesn't work. It does however work if I drag the call to my extension. Not sure why that isn't working.
Really strange. This happens in exactly the same way on both of my FOP2 installs.
The first time I populated buttons_custom.cfg and reload FOP2 none of the queues showed up and I couldn't pause/unpause agents at the extension level (helpful to pause/unpause in ALL queues).
I fixed the queue behavior as I mentioned above. However with what I just figured out it might have been a side effect of causing the button to be "removed" and "re-added".
I moved the buttons_custom.cfg file out of /usr/local/fop2 into my home folder. I then reloaded FOP2 and went into the FOP2 Manager -> Buttons to make sure they were gone (they were). I then moved the file BACK to /usr/local/fop2 and reloaded FOP2. Went into FOP2 Manager -> Buttons and the buttons showed up again. I went to Groups and added them back to the group I created for them. At this point I was back to where I was before, the buttons showing up in FOP2. HOWEVER NOW THE PAUSE/UNPAUSE WORKS!!!
The queuechannel field in FOP2 Manager STILL does not show up correctly! So there could possibly still be an issue I'm not aware of.
I suspect that simply removing and re-adding the buttons_custom.cfg file might have solved both problems with the queues showing up and the pause/unpause at the extension level. Because what I had done by changing the queue from [SIP/2097] to [SIP/2097^xxx.xxx.xxx] was to remove the button, and then when I changed it back I was re-adding it.
I still think something is wrong here. While it appears "fixed" for me, something stopped this from working correctly on initial creation. I'm not sure if the problem might resurface again if I try to add a new button for an extension on the remote system (who is a member of a queue) to buttons_custom.cfg.
I have two FreePBX servers and am adding the remote server extensions to the primary. On the remote server I ran;
autoconfig-buttons.sh
Which generates all the button details.
I then put that into the primary servers buttons_custom.cfg
For the most part it worked. However,queuechannel doesn't seem to be handled correctly.
[SIP/2001] type=extension extension=2001 label=John Smith mailbox=2001@default context=from-internal email=jsmith@domain.com queuechannel=Local/2001@from-queue/n|Penalty=0|MemberName=John Smith|StateInterface=SIP/2001&Local/2001@from-queue/n|Penalty=0|MemberName=John Smith|StateInterface=SIP/2001|Queue=2096&Local/2001@from-queue/n|Penalty=0|MemberName=John Smith|StateInterface=SIP/2001|Queue=2097 customastdb=CF/2001 extenvoicemail=*2001@from-internal queuecontext=from-queue autoanswerheader=__SIPADDHEADER51=Call-Info: answer-after=0.001 server=XXX.XXX.XXX.XXX
As you can see in FOP2Manager it cuts off after the word Penalty. What I'm experiencing is that these extensions aren't 100% working. For instance when I try to use the pause/unpause at the extension it doesn't work.
I also have had an issue with the queues defined in buttons_custom.cfg. Initially they would not show up. After reading on this forum a bit I tried editing [SIP/2097] to [SIP/2097^xxx.xxx.xxx] which didn't work. I then went back in and changed it back and magically the queues showed up.
FYI, yes the buttons were added to a group and should have been visible. Something isn't right here.
Read through THIS THREAD.
Correct permissions are set on
/var/lib/php/session
Performed the mysql queries as well, and it looks correct.
My admin account exists (the one I'm logging in with) and the SHA1 hash matches.
[root@pbx]# mysql -p asterisk -e "select * from ampusers" Enter password: +----------+---------------+---------------+----------------+----------+---------+ | username | password_sha1 | extension_low | extension_high | deptname | sections| +----------+---------------+---------------+----------------+----------+---------+ | jgould | xxxxxxxxxxxxx | | | | * | +----------+---------------+---------------+----------------+----------+---------+ [root@pbx]# mysql -u root -p asterisk -e "select sha1('xxxxxxxx')" Enter password: +------------------------+ | sha1('mypass') | +------------------------+ | xxxxxxxx | +------------------------+
At least on the system that uses the FreePBX internal database. The system that pulls accounts into user manager from AD does not show the AD user account I use for FreePBX GUI Admin access. I suspect those are stored differently.
Again, all I did between it working and when it stopped was download the latest fop2.tgz to /usr/src, extract, run make file, restart service. This moved me from 2.31.04 to 2.31.11.
Did some digging. During the install/upgrade I went from 2.31.04 to 2.31.11.
At the end I got this;
New configuration file /usr/local/fop2/fop2.cfg.new installed. Original fop2.cfg preserved. New configuration file /var/www/html/fop2/config.new.php installed. Original config.php preserved. New configuration file /var/www/html/fop2/admin/config.new.php installed. Original config.php preserved.
Looking at those 3 files I noted that they had some changes, specifically around authentication. So I moved the original files out of the way and renamed the .new files in their place. I also took note of the permissions on the original files and made sure the new ones going in their place matched.
I have 2 FreePBX/FOP2 systems. One uses is using the FreePBX database backed for users (set in User Manager), while the other one that I mentioned in my original post uses an AD backend.
Results
Neither system seemlessly logs into FOP2 after authenticating to FreePBX with my Admin account. HOWEVER, the system using the FreePBX internal backed for users DOES accept the credentials when I provide them at the FOP2 Manager login screen AND the plugins section is shown. The system using the AD backend does NOT accept the credentials for the AD account that I use to login to FreePBX.
My Guess
This did work previously with FOP2/FreePBX. I suspect when FreePBX is set to use AD credentials it only worked before because FreePBX and FOP2 were "passing" the FreePBX login session along. That actually trying to type the login credentials into FOP2 Manager would have failed. And currently this passing of the session is broken due to a change on FreePBX or FOP2.
@mvogel@cqsimple.com When you login to the admin are you seeing the plugins section?
Nope. Not unless I log in using last method, bypassing FreePBX authentication mechanism.
define('USE_BACKEND_AUTH',false);
Just updated to 2.31.11 and my FreePBX credentials are no longer allowing me to login to the FOP2 Manager section. Before the upgrade I was able to login without issue. After the upgrade of FOP2, and no other changes, I wasn't able to. Logging into FreePBX Admin first and then trying to login to FOP2, which used to automatically log me in, no longer works.
What I've figured out so far in working on this;
FreePBX has two sections where you can define user permissions. The old area is under Admin -> Administrators (with a big warning about how this is going away, mind you my FreePBX install isn't 100% updated right now). The other area is under Admin -> User Management. That is where everything is moving, or has been moved.
I created a user in Admin -> Administrators and granted all the permissions. That login WORKS with FOP2.
I created a user in Admin -> User Management and granted all the permission. That login DOESN'T WORK with FOP2.
Now, keep in mind that before upgrade FOP2 just now it DID work with the user created in Admin -> User Management.
I will note that my FreePBX is setup in Admin -> User Management -> Authentication Setting to use Authentication Engine Microsoft Active Directory. But AGAIN, this worked before the FOP2 upgrade.
Also, adding to /var/www/html/fop2/admin/config.php
define('USE_BACKEND_AUTH',false);
allows me to login with the defined admin user/password. But that isn't what I want to do.
What should I do? Everything else is working fine.
Ok, I upgraded the FOP2 Server to Version: 2.31.04. CLI is now working again and was able to check the version.