vicidial.org

vicidial.php VERSION: 2.4-325c BUILD: 110430-1924
Steps to reproduce :
1. Agent is in live call with customer
2. After parking the call and agent popping the transfer function window, the agent will enter the number to call
3. Then agent will click "Dial with customer", and once connected, the agent will grab the customer channel into conference.
4. Finally agent will press "Leave 3way conference" to remove from current call, and continue with next call.
But here agent is not able to leave the conversation.

After some days we have found a work around for this.
the agent will enter the number to call, tick consultative, tick dial override, then click dial with customer, then hangup XFER line, then untick consultative and then click Dial With Customer again and finally Leave 3- Way Call

So what can be the issue when doing it first time ?

Thanks,
Ankit

Thanks for posting your Vicidial version with build, please help by posting the rest:

when you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with build.

this IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

Your installation method could be very important when asking this question.

I am having the similar issue with my testing server. It is installed from vicibox .iso, version 3.1.15, no digium/sangoma hardware, Vicidial version: 2.4-357a build: 120125-2107, asterisk 1.4.38-vici. And it is single server installation.

1. Agent takes the call
2. Agent transfers the call using the "Park customer dial"
3. When agent wants to "grab th parked call", and the parked call comes back. But when agents wants to leave 3 way call, the button doesn't work. Agent can't hangup the xfer line either. They just end up with 3 way call when that situation is not wanted.


My goal is something like this:
1. Agent answers
2. Customer wants to transfer the call to mr. x
3. Agent puts customer on hold and tries to answer mr. x. If he answers, and allows the transfer, agent connect the customer and mr. x.
4. If mr. x is not available, then agent grabs the parked call and asks if he wants to connect to a different person. And then we go back to step 3.

But in vicidial the "dial with customer" and the "park customer call" buttons are grey. Is there a way to enable those options multiple times?

this will happen if you're trying to transfer the call to local extensions. Or wrong dialplan for carrier, that is using to dial 3-way number.

We had the same problems. blind transfer is good, but when agents were trying to "dial with customer" to supervisor's local ext, then "Leave 3-Way" button won't work.

The problem is, that dialplan entry for a local SIP phone (auto-generated) has no "tTor" options by default. I'm not sure if "r" is really needed, maybe only "tTo"

Code: Select all

exten => 340,1,Dial(SIP/340|60|)
exten => 340,2,Goto(default,85026666666666340,1)


should be

Code: Select all

exten => 340,1,Dial(SIP/340|60|tTor)
exten => 340,2,Goto(default,85026666666666340,1)


now the button "Leave 3-Way" will be active.

---------

PS I wish I know, how to add this "tTo" trough VICIdial admin interface and make it permanent

1) This is something that should be done by transferring the call to a Closer (consultative transfer possibly) which would transfer the client information to the closer's screen (which is completely missing if all you do is transfer the call to an extension).

2) A little troubleshooting tutorial

switch to the scripts folder

Code: Select all

cd /usr/share/astguiclient/

search without the actual extension number (which would presumably be a variable)

Code: Select all

grep 85026666666666 * -R -n

result:

Code: Select all

ADMIN_keepalive_ALL.pl:1776:            $Pext .= "exten => $dialplan[$i],2,Goto(default,85026666666666$voicemail[$i],1)\n";
ADMIN_keepalive_ALL.pl:1895:            $Pext .= "exten => $dialplan[$i],2,Goto(default,85026666666666$voicemail[$i],1)\n";


If you change this and it works ... please consider posting it to the Vicidial Issue Tracker (link at the top of this page!) so it can be fixed in the core and rolled out.

3) Excellent post

hi, i have the same issue.

Asterisk 1.4.39.1-vici
VERSION: 2.7-401a
BUILD: 130508-2256
© 2013 ViciDial Group

dialplan entry:
exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,2,Dial(sip/1${EXTEN:2}@aaa,,tTo)
exten => _91NXXNXXXXXX,3,Hangup

i also tried this

ahgindia wrote:vicidial.php VERSION: 2.4-325c BUILD: 110430-1924

Steps to reproduce :

1. Agent is in live call with customer

2. After parking the call and agent popping the transfer function window, the agent will enter the number to call

3. Then agent will click "Dial with customer", and once connected, the agent will grab the customer channel into conference.

4. Finally agent will press "Leave 3way conference" to remove from current call, and continue with next call.

But here agent is not able to leave the conversation.



After some days we have found a work around for this.

the agent will enter the number to call, tick consultative, tick dial override, then click dial with customer, then hangup XFER line, then untick consultative and then click Dial With Customer again and finally Leave 3- Way Call



So what can be the issue when doing it first time ?



Thanks,

Ankit

i still cannot leave 3way.
the response in the browser is
"One of these variables is not valid:
Channel must be greater than 2 characters
queryCID VXvdcW141090748311905119051190511905 must be greater than 14 characters
exten NEXTAVAILABLE must be set
ext_context default must be set
ext_priority 1 must be set

Redirect Action not sent"

Probably best to upgrade and see if someone already fixed it, rather than try to deep debug the problem that may already be solved.

I agree with @williamconley. Try upgrading to the latest version and see if the problem has been solved. You can check our HOWTOs here: http://goautodial.org/projects/goautodi ... ki/HowTos3.

Upgrading dont fix this issue i have 8.0.1 with asterisk 11.25.1-vici and i get this issue too.

I have been having this issue lately too on vicibox. I thought it was something in vicicbox 8.0.1 because its not happening on older servers, but it could be something in the newer svn. I found that adding more dialing servers solved my issue, so it must be something new related to being overloaded.

We have noticed this more and more lately. Usually only when the asterisk servers are overloaded. But the same amount of overloading on older SVNs we didn't see this happen to. Anyone know where I might start looking for to see whats causing this? Obvious solution is add more dialing servers but still.

Im having the same problem, and I have the last version of vicidial 8.1.2 with Asterisk 13.21.1-vici, I updated the asterisk version on server, acutally I just copy paste the version from the CLI and paste it, and restarted the vicidial server, it work fine for a few minutes then it wont work again, I changed the To to Ttor on my carrier side, and still nothing, Im loosing my mind here, I have never faced this problem.

I dont know if this is related, but im getting tons of these warinings: WARNING[6946][C-00003554]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel

Let me know if there is work around with this.

Asterisk 13.21.1-vici
VERSION: 2.14-694a
BUILD: 181005-1738

txs

Has anyone who experiences this resolved this yet?

I am going to try disabling the spectre and other VM hosted exploit tonight to see if that affects it.

I am starting to think it might be database related with these one of these two tables or both:

vicidial_manager
vicidial_live_agents

I have been running AST _flush_DBqueue more frequently lately to see if that helps and I haven't decided if its helping yet.
Do you thing these tables getting locked could affect this? and are these two of the tables that could be moved into memory?

Yes, and Yes. Although you need to be careful when changing those tables to MEMORY, there are cases where it can actually slow down your system.

For high-volume systems, this is how we recommend using the flush script in the crontab(and remember, on only ONE server):

### flush queue DB table every hour for entries older than 1 hour (changed to 4 minutes)
1,5,9,13,17,21,25,29,33,37,41,45,49,53,57 * * * * /usr/share/astguiclient/AST_flush_DBqueue.pl --seconds=240 -q

Hello Matt,

we adjusted the script to run each 4 mins, but the issue still exist the agent can't get out of the conference after pressing on leave 3 way conference.

VERSION: 2.14-686a
BUILD: 180904-1206

ahmed.saad92 wrote:Hello Matt,

we adjusted the script to run each 4 mins, but the issue still exist the agent can't get out of the conference after pressing on leave 3 way conference.

VERSION: 2.14-686a
BUILD: 180904-1206

Do you have an error in a log or an interface to share?

Hello William,


Which type of log to look at?, Apache doesn't show any error logs, so is MySQL and Asterisk. With 25 agents logged in on one server initiating 200 calls at a time (on predictive dialer) leave 3-way conference button does not seem to trigger any action, the button is not responsive. Any recommendation for where to look or how can this be mitigated?.

If the leave 3-way NEVER works, there's likely a configuration issue. Is it lit up but non-functional, or not even lit up?

Is this server freshly installed or recently upgraded or did you bring a database into a freshly installed server? It's common to have a mismatch in the Asterisk version during install which can cause the wrong code to be executed for the version of asterisk you're using.

Note that this requires a reboot:

Code: Select all

perl install.pl --copy_sample_conf_files

and be sure that you include a provided option when asterisk version is requested (11.X is not the same as 11, for instance: don't make up your own option). You may want to make a copy of all your .conf files in /etc/asterisk first so you can bring forward any customizations.

Also verify the value for asterisk version in admin->servers

Thank you for your reply, William. Dug a little deeper into this, Asterisk version match, and the installation is a fresh one, no changes to the database done. What we're noticing now is when a call comes to the agent from the dialer (with some calls not all) does not switch the status of the agent to Live Call and that's exactly when we're not able to leave 3-way conference. It kind of make sense, VDAD won't allow us to leave 3-way conference if they are not sensing a live call to begin with. A new question pops up, what is causing VDAD to not switch the agent status to live call with some calls?.

Quick update: agent status is live call until the agent presses leave 3-way conference, once the agent presses leave 3-way conference their status is switched to no live call and the button is no longer clickable.

ahmed.saad92 wrote:Quick update: agent status is live call until the agent presses leave 3-way conference, once the agent presses leave 3-way conference their status is switched to no live call and the button is no longer clickable.

Expected behavior. The agent has left the call. The agent then gets a fresh session and takes another call after dispo.

ahmed.saad92 wrote:What we're noticing now is when a call comes to the agent from the dialer (with some calls not all) does not switch the status of the agent to Live Call and that's exactly when we're not able to leave 3-way conference

Usually an overloaded server. Could be the DB or the dialer or the web, any of them in overload could cause the issue. Does this happen during heavy dialing? Randomly even when there are only a couple agents? What's the Average Server Load and Core Count for the machines involved? (Dialer, Web, DB). Does it happen to all agents on all servers? How many servers do you have?

Hello William,

Thank you for your reply, This issue start to appear when we have 25 agent or above, the System Load: 343 - 9%,

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 24
On-line CPU(s) list: 0-23
Thread(s) per core: 2
Core(s) per socket: 6
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 62
Model name: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz
Stepping: 4
CPU MHz: 1200.000
CPU max MHz: 2600.0000
CPU min MHz: 1200.0000
BogoMIPS: 5187.18
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 15360K
NUMA node0 CPU(s): 0-5,12-17
NUMA node1 CPU(s): 6-11,18-23

We did some changes, we disabled DB binary logging this option was enabled by default in the installation and the issue got fixed we are not facing the issue any more with the same number of agents, so i think it's the overload on the server too.

ahmed.saad92 wrote:the System Load: 343 - 9%,

For that system load to report accurately requires some calibration and understanding. Use "uptime" or "htop" at the CLI or use the Average Server Load value from the bottom of the real time screen (which shows average server load for the web server upon which you are viewing). Any load over 50% of the total core count is approaching overload. If load matches the core count: You're overloaded (note that 0-50% takes a while, but 50% to 100% is pretty farkin fast).

ahmed.saad92 wrote:On-line CPU(s) list: 0-23
Thread(s) per core: 2
Core(s) per socket: 6
Socket(s): 2

Indicating hyperthreading is on. This can be a bad thing. Test with hyperthreading off if you experience issues. Report your results as this is something we've all watched for a while. Note that "virtual cores" may fool windows, but linux ... not so much. Especially not linux apps using perl "hi-res timing" module, which uses every nanosecond of the system clock.

I am VERY interested in testing your change. Disabling the Binary logging.

What procedure did you do to disable the logging? My research points to commenting out log_bin in my.cnf or live with SET sql_log_bin = 0;
Is that what you did? and Will that work?

Lastly I read that Binary logs are required for replication. does that mean if I have a slave reporting database I must not disable the binary logging?

binary logging is disabled in a different way based on which version of mysql you're using.

and it is required for replication, but you can set the retention period fairly short so it doesn't fill the HD. You can also put the binary logs on a different HD (which is a fairly smart move from a recovery standpoint anyway).

I spent some time on this and found out what is causing my issue. might be the same as yours.

After a few hours of heavy use, when the agent presses the leave 3way, nothing is being passed for channel in manager_send.php and gets the error: "One of these variables is not valid:
Channel must be greater than 2 characters."

After a reboot it starts sending a value again. ex. &channel=SIP/Inphxin-00000001

Not sure why it stops yet, and not sure if our issues were the same but I am still working to figure this one out.

As a reminder heres my stuff.
Asterisk 13.21.1-vici
SVN 3052
Installed using ViciBox v.8.0.1

VERSION: 2.14-694a
BUILD: 181005-1738
DB Schema Version: 1561
Using webrtc Viciphone
Dell R610s Raid 1 H700 with SSDs
1DB, 1 Web, 3 Dialers 15 agents per server

does this also happen on a non-webrtc phone?

Attempting to determine if it's related to that process or something else.

Thats a great question and I had been very suspicious of it being webrtc related.

So heres the deal, I tried it with Xlite Softphone AFTER the point where it stops working. and it still doesn't work. If I reboot the server it starts works fine. so from that stand point, yes it does happen on a softphone. but would using only softphones cause it to break in the first place? that I am not sure of. If I can't find anything else this weekend I am going to try switching all the agents off webphone. but thats going to be a task installing xlite on all the computers...

my current theory is I noticed after a reboot The dialing server. (not the database or webserver just the dialers) the channel seems to always reset to SIP/Inphxin-00000001 (found in both the live calls table and the developer tools on chrome for whats being sent for manager_sent.php so maybe they are sending so many transfers that the number gets too high or something??

When its broken the channel in the live calls table looked like SIP/Inphxin-000098ab Maybe the letters are breaking it?

Another quick thought I am currently having is maybe the dialers are having trouble consistently communication all the information with the database or webserver.

since it still happens when there is no load on the systems or the network at the time I am testing. (after it became broken during production and before I reboot to resolve it). maybe it has something to do with all ports or connections being used or something? (I feel like I am streaching here. haha)

But I have seen you write somewhere about tcp port handling (reuse/recycle/timeout settings) and the the "conntrack max" setting. Could either of these stop the agent interface from being able to retrieve the Channel information from the dialer that is required to be sent in the manager_send.php?

alo wrote:the channel seems to always reset to SIP/Inphxin-00000001

When? Before you tell it to reset or after? If it's after, that's normal. You just reset, so it started again from "call 1".

Yes. Its after. I kinda assumed thats normal, but I am wondering if that has something to do with it breaking.
Like the number gets too high to send to the manager_send.php and when it resets back to 0 its good to go.
I think I am stretching, but so far thats the only thing I can find different from before I reboot and after.

I wonder where the system is pulling the channel data that it puts in the manager_send.php call.

Nope. Keep lookin. I suspect there's a cache, register or other limiting factor involved. But the only way you could claim it's this number is if it always stops at the same number Before your restart. Thinking that Starting over at 1 after reset is proof that it's related is like saying there's a problem caused by the clock because "uptime" says "00:00" after a reboot. lol

Code: Select all

nf_conntrack: table full, dropping packet

conntrack max has been known to become an issue. This value can be difficult to manage as it is calculated from system resources (If I recall) if you try to set it too high. So you *may* be able to double it, but you may not. In which case more resources (um ... memory?) may be needed.

Duct Tape Possibilities vary based on version of OS:

Code: Select all

netstat -n | grep TIME_WAIT | wc -l
cat /proc/sys/net/ipv4/tcp_tw_recycle
cat /proc/sys/net/ipv4/tcp_fin_timeout
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
cat /proc/sys/net/nf_conntrack_max


Code: Select all

echo '1' > /proc/sys/net/ipv4/tcp_tw_recycle
echo 'net.ipv4.tcp_tw_recycle = 1' >> /etc/sysctl.conf
echo '10' > /proc/sys/net/ipv4/tcp_fin_timeout
/sbin/sysctl -w net.netfilter.nf_conntrack_max=196608


With your experience there:

Code: Select all

nano /etc/sysctl.conf

Vicibox 7.0.3, for instance, has this in /etc/init.d/after.local :

Code: Select all

echo '262144' > /proc/sys/net/netfilter/nf_conntrack_max

Note that any of the above changes may be temporarily disruptive ... but after a few minutes (upon all connections on the "new rules") it should stabilize.