vicidial.org

Hi -
Our set up was working correctly, and after our recent transition to a new data center - predictive dialing stopped working. All manual dials, and inbound calls work well on our set up. All our outbound traffic goes through a separate telecom router - which has been working okay as well - so not quite sure where the problem lies and would appreciate any help/direction to see where to look for.

Since, our set up was working correctly prior to transition - i doubt it has to do with configuration but either way - we have our "o" flags properly in place as has been mentioned in lot of the posts here but following are the details:

Vicidial Version:
VERSION: 2.4-317a
BUILD: 110602-0941

; VICIDIAL_auto_dialer transfer script AMD with Load Balanced:
exten => 8369,1,Playback(sip-silence)
exten => 8369,n,AGI(agi://127.0.0.1:4577/call_log)
exten => 8369,n,AMD(2000|2000|1000|5000|120|50|4|256)
exten => 8369,n,AGI(VD_amd.agi,${EXTEN})
exten => 8369,n,AGI(agi-VDAD_ALL_outbound.agi,NORMAL-----LB)
exten => 8369,n,AGI(agi-VDAD_ALL_outbound.agi,NORMAL-----LB)
exten => 8369,n,Hangup

Campaign configuration is set up to dial 8369 when connecting the call and we see it executing on the CLI.

CLI shows us that the call hangs up is returned as soon as the sip-silence is executed.

Drop Call Seconds is set to 2.

Appreciate your help in advance.

Thanks,

Hello,
Share the CLI output when you are in autodial mode.
Dont forget to hide any sensitive information like username, pass, ip address

Here's the CLI from an old test call that i'd done (PS - the number 786xxxxxx is hidden for privacy but is an actual number being dialed):

[Aug 21 10:40:38] -- Executing [9786xxxxxxx@default:2] Dial("Local/9786xxxxxxx@default-f34a,2", "SIP/786xxxxxxx@10.250.128.223||To") in new stack
[Aug 21 10:40:38] -- Called 786xxxxxxx@10.250.128.223
[Aug 21 10:40:38] -- Accepting AUTHENTICATED call from 10.20.1.57:
> requested format = ulaw,
> requested prefs = (ulaw|gsm),
> actual format = ulaw,
> host prefs = (ulaw),
> priority = mine
[Aug 21 10:40:40] -- SIP/10.250.128.223-0000023d is making progress passing it to Local/9786xxxxxxx@default-f34a,2
[Aug 21 10:40:45] -- SIP/10.250.128.223-0000023d answered Local/9786xxxxxxx@default-f34a,2
[Aug 21 10:40:45] > Channel Local/9786xxxxxxx@default-f34a,1 was answered.
[Aug 21 10:40:45] -- Executing [8369@default:1] Playback("Local/9786xxxxxxx@default-f34a,1", "sip-silence") in new stack
[Aug 21 10:40:45] -- <Local/9786xxxxxxx@default-f34a,1> Playing 'sip-silence' (language 'en')
[Aug 21 10:40:45] WARNING[2064]: file.c:1297 waitstream_core: Unexpected control subclass '-1'
[Aug 21 10:40:45] -- Executing [h@default:1] DeadAGI("Local/9786xxxxxxx@default-f34a,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----7-----0") in new stack
[Aug 21 10:40:45] -- Executing [8369@default:2] AGI("SIP/10.250.128.223-0000023d", "agi://127.0.0.1:4577/call_log") in new stack
[Aug 21 10:40:45] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Aug 21 10:40:45] -- Executing [8369@default:3] AMD("SIP/10.250.128.223-0000023d", "2000|2000|1000|5000|120|50|4|256") in new stack
[Aug 21 10:40:45] -- AMD: SIP/10.250.128.223-0000023d 18006274637 (null) (Fmt: 64)
[Aug 21 10:40:45] -- AMD: initialSilence [2000] greeting [2000] afterGreetingSilence [1000] totalAnalysisTime [5000] minimumWordLength [120] betweenWordsSilence [50] maximumNumberOfWords [4] silenceThreshold [256]
[Aug 21 10:40:46] -- AMD: Changed state to STATE_IN_SILENCE

PremBalwani wrote:Here's the CLI from an old test call that i'd done (PS - the number 786xxxxxx is hidden for privacy but is an actual number being dialed):

[Aug 21 10:40:45] > Channel Local/9786xxxxxxx@default-f34a,1 was answered.

I can see that the call was actually answered. When you said auto dial is not working, what you mean exactly.
Also, can you try auto dial with 8368 instead 8369

Sorry, i should've been more clear. The call connects but when trying to route out to available agents it just hangs up, gets flagged as queuetimeout in the database. We've tried changing it to 8368, and increasing drop timeout to 10 seconds but it's the same experience.

Thanks for your help.

Ok. Put only one agent in the dialer, and send the CLI output, so we can see what happens after the calls connect, and we can see the reason why the call is not being send to the agent.
Also, make sure that the agent is not logged in as closer, and also is not paused.

you mentioned having the o flag, but generally speaking you'll want t, o and r flags, possibly T too. I can't recall what each one does specifically but the t ones have to do with transfer capacity, which would certainly explain your issue.

*Edit* I see you do have the T flag enabled, so ignore me :/ sorry!

omarrodriguezt wrote:Ok. Put only one agent in the dialer, and send the CLI output, so we can see what happens after the calls connect, and we can see the reason why the call is not being send to the agent.
Also, make sure that the agent is not logged in as closer, and also is not paused.

CLI output provided was with agents available in closer state to take calls. They were in read state and not paused either.

I need to see more information of the CLI in order to continue helping you.

[Aug 21 10:40:46] -- AMD: Changed state to STATE_IN_SILENCE

This last line of CLI output does not show the result of the AMD or the termination of the call. Next you tried 8368, but did not show any output so we still have not seen what caused termination.

Ordinarily when you move, the "externip" value in sip.conf needs to be changed. If it's not, it can cause calls to fail in exactly this manner. However, I've not seen the rest of the output to narrow down the real cause.