I’d love to take advantage of all the new stuff when they get it working but I need to get to a point where we’re not disconnecting callers tomorrow. I don’t have a bullet-proof vest and I’m not sure how to get by the call center director and live to tell about it. I’ve got a family to think about.
The FreePBX engineer I spoke with today said that he thought this sounded like a reasonable solution. We discussed the fact that I won’t have asterisk-based DND, Call Forward, etc. but we’re not using those anyway. This is a call center environment where the agents put the phone devices on DND when they’re away and we don’t use call forwarding.
What are the other implications? All I can go on is recommendations from the experts on how to fix this and right now I’m hearing that “in the field” this is how it’s fixed.
We created a file /usr/local/bin/freepbx_fix_queue_members.sh that contains:
#!/bin/sh
# freepbx_fix_queue_members.sh
#
# run from /etc/amportal.conf to convert queue members to sip devices
# Local Pseudo channels aren't stable
# and dialparties.agi (from local pseudo channels) will cause Asterisk crash
#
# change: member=Local/102@from-internal/n,0
# to: member=SIP/102,0
cp /etc/asterisk/queues_additional.conf /etc/asterisk/queues_additional.conf-freepbx
sed 's/member=Local\/\([0-9a-zA-Z_]*\).*,\(.*\)/member=SIP\/\1,\2/' </etc/asterisk/queues_additional.conf-freepbx >/etc/asterisk/queues_additional.conf
asterisk -rx "reload"
(don’t forget to make the file executable)
Then we changed/added a line to /etc/amportal.conf that reads:
What I did was change “Local” to “SIP” and deleted out the “from-internal” in the “/var/www/html/admin/modules/queues/page.queues.php” and then saved changes to the queues from within FPBX. This successfully changed Local to SIP in the queue_additional.conf like escape2mtns describes above.
This is working well at the moment I will observe tomorrow under high traffic conditions how this works out.
jajaja, Mine is obviously prone to breaking when the QUEUE module is updated by FPBX but it was easyer for me to edit the php script file seeing that Iḿ not such a Linux “boffin”.
Are there any drawbacks you see using SIP instead of Local, such as problems trasnferring etc or should everything else work the same?
Philippe,
thank you for your input because I was sure that there were implications…but at the moment I need a solution for the dialparties.agi script hanging every day and going to 180% load on my server.
What main implications does this change to SIP have? …because since I have done it my server has gone down to 20% CPU usage and I have perfect voice quality on all calls which is my first objective obviously seeing that this is a 100 agent call center.
What is you suggestion for someone like me that is not very savvy on programming etc? I have implemented 1.4.26RC5 seeing that you had mentiond something having been implemented in 1.4.25 or 26 but still today I was having the same issues.
How can I get hold of the other solution you mention with the “hints”?
BTW, I’m absolutely not trying to cross purposes with Philippe. I really appreciate him and his efforts.
But I would like to mention … because I couldn’t find this info anywhere and I looked… that the FreePBX engineer I spoke with today said that they have seen bugs with the 1.4.23, 1.4.24, and 1.4.25 versions of Asterisk and that they recommend all installations stick with the 1.4.22 level unless something else requires that you upgrade.
From a call center perspective, it seems like the SIP queue member is the way to go. I’ve now run across other forum posts (here I think) that talk about how using the Local channel for queue members causes Asterisk to see the Agent as in-use even if the call is transferred away and that the Agent isn’t ‘available’ again until that call disconnects from whoever received the call transfer.
At the end of the first full business day using SIP queue members, we’ve now gone over 24 hrs without a crash/restart or hung dialparties.agi (for the first time).
Philippe,
We have had a day with over 15K calls and no crashes or hanging dialparties.agi. I need to know what we can do to use SIP instead of Local to avoid these problems in the future or is this something that has to be corrected in Asterisk??
What exact things are we loosing by doing the SIP instead of Local call type?
I am happy as a pig in sh.t. The call center has been stable for 3 days now using SIP instead of Local. I wonder when the Asterisk team finds out what they broke in the way the AGI are handled. Im no expert but Id say there is something gravely wrong somewhere there.
Here is the change I made in:
/var/www/html/admin/modules/queues/page.queues.php
Changed from: (just serach for “Local”)
$members[$key] = “Local/”.$members[$key]."@from-internal/n,".$penalty_val;
to:
$members[$key] = “SIP/”.$members[$key].",".$penalty_val;
This is obviously a temporary fix until the queues module is updated by FPBX again and at some point in time I hope there is a solution for the dialparties hanging issue to be able to revert back to the original way of handling these calls as intended by FPBX.
We put Speschko’s script in the production server yesterday, and it appears to fix our issue. Relative to the previous condition with dialparties.agi and the associated hit, the CPU is now loafing.
This is a great relief!
We’ll look forward to an official fix, and will make a donation now to help.
By sending directly to SIP, first of it requires you to be running in extension mode thought that is usually not an issue with most people as that is the default and most don’t know there is even another mode that you can run in.
The biggest issue you run into will be if those agents subsequently transfer calls to someone else which potentially requires going to that person’s voicemail. Instead of dropping into voicemail, the call will be hung up. There are some other anomalies related to that that may occur, but it’s late on a Friday so it’s not coming to me right now.
The other issue which is probably not a problem for you, is that all numbers may not always be SIP. There could be other devices, they could be other dialplan, they could be outside numbers. Again, none of that may be important in your situation.
There is an ability to use Asterisk Agents, agent.conf type, that is un-supported, keeping in mind that I think that is being deprecated in 1.6. If you put Annn as your static agent number, it will treat it like an agent which can get a similar result that you are doing.
Okay, setting ringinuse=no, by itself, didn’t work.
But as documented elsewhere, an edit to queues_post_custom.conf does appear to do the trick. We have several queues, so we put the changes in this format:
that’s why I suggested looking at the 2.6 version of the module, it has an option for ringinuse, and several other things.
Though, come to think about it, there may be some dependencies that make it require 2.6 core changes. But then again, you could just load all of 2.6. I plan on wrapping the tarball up and making it a bit more formal within the next couple weeks, but it is pretty solid overall. And there is some nice enhancement for queues.
I did consider the 2.6 suggestion, but prefer to wait for the tarball. This is a production system I’m now experimenting on, and the end users are pretty jumpy.
If it’s that, then it’s a bug with phpagi, not with Asterisk or FreePBX.
I was having symptoms pretty much as here, and have just spent today diagnosing it, and the fix I’ve put at the above link solves it for me (as well as other ‘unexplained delays’ issues), so it may help others, and it would be good to see if it works for other people as well.
