vicidial.org

We have a small issue with delay when dialing. Here is what I am seeing:

1 server has 1 long distance and one local T1 on it.
1 server has 2 long distance t1s on it.

The agents on the server with the 1LDt1 are getting calls much slower then the agents on the one with 2LDt1s, even though they both dial at the same dial level.

To run a little test they are both calling LD campaigns.

server1 - 6 agents, 1 LDt1 and dial level of 6.0
server2 - 7 agents, 2 LDt1s and dial level of 4.5

The wait time for the agents on server 1 is over 2 minutes between calls. The wait time on server 2 is at 27seconds.

If I watch server 2, I can see calls coming over and dialing out, but its hard to judge if its dialing as many as it should. Here is the dialplan for that.

exten => _1NXXNXXXXXX,1,Dial(Zap/g4/${EXTEN}||o)
exten => _1NXXNXXXXXX,2,Dial(IAX2/cobsrv01@cobsrv02/${EXTEN}||o)

Are there any tools to determine if all zap chans are getting utilized?

Is there a way to see how many numbers are dialed (not just answered, but dialed all together)?

Thanks,
Lucas

What are the loadavg for both servers?

What does the output of the ASTVDauto screen look like on both servers when dialing?
("screen -x ASTVDauto" to connect and "Ctrl a" then "d" to disconnect)

What kind of T1s are on each server?

Are you dialing over the local T1 as well as the LD T1 on server 1?

MATT---

What are the loadavg for both servers?

server 1 - 12.18 -- is running 2 campaigns, also running a local camp with 6 people and its running fine.. its the LD thats an issue
server 2 - 1.30

They all went to lunch and switched campaigns before I could get the screen -x ill get that a little later today.


Are you dialing over the local T1 as well as the LD T1 on server 1?


Yes, they are dialing on local and long distance (2 different campaigns). I noticed the server load was a bit high, but previously we didnt do it this way and the delay was still there.

Before today, we would have ~13 people on server 1 dialing long distance and 7-8 people on server 2 dialing long distance.

12.18 is way too high of a loadavg. It will cause delays in the dialing.

post the screen -x output when you get it.

Also, are those 6 agents all dialing out over both T1s on server 1?

Yeah, thats really high. I was a bit surprised. I now have 12 agents with a dial level of 6 on that server all dialing long distance together in one campaign. Server 2 is at lunch.

The server load is now looking like it fluctuates around 5 going as high as 9.49. With an avgwait of 0:33.

How are you dialing 12 agents at a dial_level of 6.0(72 lines) when you only have 48 lines?

What is your max_vicidial_trunks field set to for this server in your servers table?

There are 3 t1s.. server 1 has 1LDt1, server 2 has 2LDt1s

Max trunks is set to 100 on this server

I guess I should mention, that server has a local t1 on it as well.

Are you dialing from server1 to server2's T1 lines over IAX?

Are these servers set up for VICIDIAL load balancing?

Are you using a separate MySQL and Web server?

I guess I should have mentioned at the start.. this is the same project Enjay is working on. He is my partner, just happened that I was the one here messin with it today =)

What we are going to try is just stopping all of the flow of calls from server 1 to 2 and from 2 to 1.

Server 2 is going to have 1LDt1 only. Server 1 will have 2LDt1s and 1local. Server 1 has more people and dials both, server 2 only dials long distance and never has more then 8 people. This way, we can easily limit server2 and hopefully lower the load and not have these issues. We shall see!

Thanks,
Lucas

Matt,

How difficult would it be for us to implement the vicidial trunks on a per campaign basis this would resolve all of our line issues since you cannot deliniate between Local Vs Long Distance trunks.

-enjay

Additionally are there any tools to use to determine what Zap channels are being utilized (to ensure all lines are being use).

Also, what does this mean?

VD_hangup.agi|PRI-----NODEBUG-----0-----CANCEL----------

versus

VD_hangup.agi|PRI-----NODEBUG-----0-----ANSWER----------

enjay wrote:How difficult would it be for us to implement the vicidial trunks on a per campaign basis this would resolve all of our line issues since you cannot deliniate between Local Vs Long Distance trunks.

I suppose you could always hard-code it into the AST_VDauto_dial.pl script since that's the only script that uses that variable.

It would require a lot of extra programming and validations to offer a feature to create a set of definable trunk groups within the VICIDIAL package.

Additionally are there any tools to use to determine what Zap channels are being utilized (to ensure all lines are being use).

you should be able to get the listing of in-use zap channels per server from the live_channels table.

Also, what does this mean?

VD_hangup.agi|PRI-----NODEBUG-----0-----CANCEL----------

versus

VD_hangup.agi|PRI-----NODEBUG-----0-----ANSWER----------

CANCEL and ANSWER are Dial status codes, CANCEL is usually a timeout of the call, but not always. ANSWER usually means that the call was picked up on the remote end.

and if there is nothing?

-- Executing DeadAGI("Zap/53-1", "VD_hangup.agi|PRI-----NODEBUG-----0---------------") in new stack


Is there a location where I can see those HANGUPCAUSE variables?

-enjay

Would it be worth while to you to have that capability of defining trunks on a per campaign basis? If so I will start doing the research necessary to implement.

-enjay

The ${DIALSTATUS} variable is hers and is not always populated:
http://www.voip-info.org/wiki-Asterisk+ ... DIALSTATUS

As for campaign-specific trunks, the best way of doing it would probably be to create a new vicidial table(vicidial_trunks) and a new section in the vicidial/admin.php page where you could define trunks per server and assign them to campaigns. Then the AST_VDauto_dial.pl script needs to be modified to work with the new table.

It would take quite a bit of work, but it should work. I wouldn't put it high on my priority list, but I can add it to the TODO.

I was thinking more along the lines of actually doing it ourself and submitting the code for review, I'll put it on mantis when we're done.

-enjay