New leads keep new status after 10+ passes

[udfxrookie]

I load new leads into the dialer, dial them and most stay in the New Status... my NA count is SUPER low so I'm thinking that the dialer may be dispositioning NA's as NEW.... what's going wrong here?

[gers55]

What is your List Order: set to. If it is set to random try something else like down count and see if it makes a difference

[udfxrookie]

That shouldn't make a difference. List order is the order in which the leads are placed into the hopper.

[udfxrookie]

Built new dialer as show in sig below. and still having the same problem... I have after running my lists with 17 agents for two days a total of 16 NA, but my NEW is still showing (after several passes) an insanely high number... and I have new with an 8 count....

[udfxrookie]

The calls that are getting the high count as NEW are not showing in the vici_log either... but still getting count incremented

[williamconley]

perhaps you should try a single call to see if it gets changed from new to "something else". then try "full load" .. then try in between. one of them has to give you a hint.

[mcargile]

Please post the Asterisk output when Vicidial tries to place a call to one of these numbers. I have a feeling the numbers are not properly formatted for your dialplan. When this happens Vicidial will send the manager event to place the call and make the lead as called, but Asterisk will fail to send the call out. This results in the call never making it into the call_log AGI script and thus never has its status changed.

[udfxrookie]

@william: We've tried several types of calls. When you do a manual it will increment the lead and because the agent is handling it and the call shows in the vicidial_agent_log and gets a disposition. Anytime the dialer handles the call it will not appear in vicidial_log and never get a disposition but stills get incremented... We have practically zero NA's and this causes a hug problem because when we try loading new leads to get better traction the dialer pulls NEW count whatever (sometimes 4-10) as well as the actual NEW 0 count... which bogs the dialer down...

@mcargile: The phone numbers are all correct... some of the list gets dialed and pushed into dispositions... if you read above it's pretty specific.. the call gets dialed, it's a NA status and gets coded or left in the NEW status and incremented. Nothing wrong with the lists.

[mcargile]

Still please post the output from Asterisk of one of these leads being dialed.

[udfxrookie]

Hope this is enough... I loaded just NEW in dialable and these are "NEW" leads with 1-6 counts already:

Code: Select all

[Sep 27 19:07:47] Scheduling destruction of SIP dialog '0aa1c98c2c9c15cb3cfb38132160a927@100.000.100.000' in 6400 ms (Method: INVITE)
[Sep 27 19:07:47] Reliably Transmitting (NAT) to 38.102.250.50:5060:
CANCEL sip:19733793235@38.102.250.50;cpd=on SIP/2.0
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK51f40e47;rport
From: "V9271907200000034997" <sip:8623675566@100.000.100.000>;tag=as13bf8be9
To: <sip:19733793235@38.102.250.50;cpd=on>
Call-ID: 0aa1c98c2c9c15cb3cfb38132160a927@100.000.100.000
CSeq: 102 CANCEL
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "V9271907200000034997" <sip:8623675566@100.000.100.000>;privacy=off;screen=no
Content-Length: 0


---
[Sep 27 19:07:47] Scheduling destruction of SIP dialog '0aa1c98c2c9c15cb3cfb38132160a927@100.000.100.000' in 6400 ms (Method: INVITE)
[Sep 27 19:07:47]   == Manager 'sendcron' logged off from 127.0.0.1
[Sep 27 19:07:47]   == Spawn extension (default, 919733793235, 12) exited non-zero on 'Local/919733793235@default-6fe6,2'
[Sep 27 19:07:47] Scheduling destruction of SIP dialog '2b93580f36a3928a0082caf47657ac05@100.000.100.000' in 6400 ms (Method: INVITE)
[Sep 27 19:07:47]   == Manager 'sendcron' logged off from 127.0.0.1
[Sep 27 19:07:47]     -- Executing [h@default:1] DeadAGI("Local/919733793235@default-6fe6,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
[Sep 27 19:07:47] Reliably Transmitting (NAT) to 38.102.250.50:5060:
CANCEL sip:16095300207@38.102.250.50;cpd=on SIP/2.0
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK3c993c99;rport
From: "V9271907200000019761" <sip:8623675566@100.000.100.000>;tag=as4498b099
To: <sip:16095300207@38.102.250.50;cpd=on>
Call-ID: 2b93580f36a3928a0082caf47657ac05@100.000.100.000
CSeq: 102 CANCEL
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "V9271907200000019761" <sip:8623675566@100.000.100.000>;privacy=off;screen=no
Content-Length: 0


---
[Sep 27 19:07:47] Scheduling destruction of SIP dialog '2b93580f36a3928a0082caf47657ac05@100.000.100.000' in 6400 ms (Method: INVITE)
[Sep 27 19:07:47]   == Spawn extension (default, 916095300207, 12) exited non-zero on 'Local/916095300207@default-235a,2'
[Sep 27 19:07:47]     -- Executing [h@default:1] DeadAGI("Local/916095300207@default-235a,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
[Sep 27 19:07:47]   == Manager 'sendcron' logged off from 127.0.0.1
[Sep 27 19:07:47] Scheduling destruction of SIP dialog '47427482024ff9f626f7d661716e60ca@100.000.100.000' in 6400 ms (Method: INVITE)
[Sep 27 19:07:47] Reliably Transmitting (NAT) to 38.102.250.50:5060:
CANCEL sip:19734500702@38.102.250.50;cpd=on SIP/2.0
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK6fe2cee8;rport
From: "V9271907200000016091" <sip:8623675566@100.000.100.000>;tag=as4b4a3489
To: <sip:19734500702@38.102.250.50;cpd=on>
Call-ID: 47427482024ff9f626f7d661716e60ca@100.000.100.000
CSeq: 102 CANCEL
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "V9271907200000016091" <sip:8623675566@100.000.100.000>;privacy=off;screen=no
Content-Length: 0


---
[Sep 27 19:07:47]   == Manager 'sendcron' logged off from 127.0.0.1
[Sep 27 19:07:47] Scheduling destruction of SIP dialog '47427482024ff9f626f7d661716e60ca@100.000.100.000' in 6400 ms (Method: INVITE)
[Sep 27 19:07:47]   == Spawn extension (default, 919734500702, 12) exited non-zero on 'Local/919734500702@default-2373,2'
[Sep 27 19:07:47]     -- Executing [h@default:1] DeadAGI("Local/919734500702@default-2373,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
[Sep 27 19:07:47] Scheduling destruction of SIP dialog '37f713100c0dec7370ca60751ca85c74@100.000.100.000' in 6400 ms (Method: INVITE)
[Sep 27 19:07:47] Reliably Transmitting (NAT) to 38.102.250.50:5060:
CANCEL sip:16094980361@38.102.250.50;cpd=on SIP/2.0
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK0bf524c7;rport
From: "V9271907200000020555" <sip:8623675566@100.000.100.000>;tag=as583d095b
To: <sip:16094980361@38.102.250.50;cpd=on>
Call-ID: 37f713100c0dec7370ca60751ca85c74@100.000.100.000
CSeq: 102 CANCEL
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "V9271907200000020555" <sip:8623675566@100.000.100.000>;privacy=off;screen=no
Content-Length: 0


---
[Sep 27 19:07:47] Scheduling destruction of SIP dialog '37f713100c0dec7370ca60751ca85c74@100.000.100.000' in 6400 ms (Method: INVITE)
[Sep 27 19:07:47]   == Spawn extension (default, 916094980361, 12) exited non-zero on 'Local/916094980361@default-bcf2,2'
[Sep 27 19:07:47]   == Manager 'sendcron' logged off from 127.0.0.1
[Sep 27 19:07:47]     -- Executing [h@default:1] DeadAGI("Local/916094980361@default-bcf2,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
[Sep 27 19:07:47]
<--- SIP read from 38.102.250.50:5060 --->
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK51f40e47;rport=5060
From: "V9271907200000034997" <sip:8623675566@100.000.100.000>;tag=as13bf8be9
To: <sip:19733793235@38.102.250.50;cpd=on>;tag=xcast-46912861373408
Call-ID: 0aa1c98c2c9c15cb3cfb38132160a927@100.000.100.000
CSeq: 102 INVITE
Server: XCast Partner/1.1
Content-Length: 0


<------------->
[Sep 27 19:07:47] --- (8 headers 0 lines) ---
[Sep 27 19:07:47] Transmitting (NAT) to 38.102.250.50:5060:
ACK sip:19733793235@38.102.250.50;cpd=on SIP/2.0
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK51f40e47;rport
From: "V9271907200000034997" <sip:8623675566@100.000.100.000>;tag=as13bf8be9
To: <sip:19733793235@38.102.250.50;cpd=on>;tag=xcast-46912861373408
Contact: <sip:8623675566@100.000.100.000>
Call-ID: 0aa1c98c2c9c15cb3cfb38132160a927@100.000.100.000
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "V9271907200000034997" <sip:8623675566@100.000.100.000>;privacy=off;screen=no
Content-Length: 0


---
[Sep 27 19:07:47]
<--- SIP read from 38.102.250.50:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK51f40e47;rport=5060
From: "V9271907200000034997" <sip:8623675566@100.000.100.000>;tag=as13bf8be9
To: <sip:19733793235@38.102.250.50;cpd=on>;tag=xcast-46912543882192
Call-ID: 0aa1c98c2c9c15cb3cfb38132160a927@100.000.100.000
CSeq: 102 CANCEL
Server: XCast Partner/1.1
Content-Length: 0


<------------->
[Sep 27 19:07:47] --- (8 headers 0 lines) ---
[Sep 27 19:07:47]
<--- SIP read from 38.102.250.50:5060 --->
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK3c993c99;rport=5060
From: "V9271907200000019761" <sip:8623675566@100.000.100.000>;tag=as4498b099
To: <sip:16095300207@38.102.250.50;cpd=on>;tag=xcast-472679040
Call-ID: 2b93580f36a3928a0082caf47657ac05@100.000.100.000
CSeq: 102 INVITE
Server: XCast Partner/1.1
Content-Length: 0


<------------->
[Sep 27 19:07:47] --- (8 headers 0 lines) ---
[Sep 27 19:07:47] Transmitting (NAT) to 38.102.250.50:5060:
ACK sip:16095300207@38.102.250.50;cpd=on SIP/2.0
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK3c993c99;rport
From: "V9271907200000019761" <sip:8623675566@100.000.100.000>;tag=as4498b099
To: <sip:16095300207@38.102.250.50;cpd=on>;tag=xcast-472679040
Contact: <sip:8623675566@100.000.100.000>
Call-ID: 2b93580f36a3928a0082caf47657ac05@100.000.100.000
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "V9271907200000019761" <sip:8623675566@100.000.100.000>;privacy=off;screen=no
Content-Length: 0


---
[Sep 27 19:07:47]
<--- SIP read from 38.102.250.50:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK3c993c99;rport=5060
From: "V9271907200000019761" <sip:8623675566@100.000.100.000>;tag=as4498b099
To: <sip:16095300207@38.102.250.50;cpd=on>;tag=xcast-46912533770096
Call-ID: 2b93580f36a3928a0082caf47657ac05@100.000.100.000
CSeq: 102 CANCEL
Server: XCast Partner/1.1
Content-Length: 0


<------------->
[Sep 27 19:07:47] --- (8 headers 0 lines) ---
[Sep 27 19:07:47]
<--- SIP read from 38.102.250.50:5060 --->
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK6fe2cee8;rport=5060
From: "V9271907200000016091" <sip:8623675566@100.000.100.000>;tag=as4b4a3489
To: <sip:19734500702@38.102.250.50;cpd=on>;tag=xcast-46912808388720
Call-ID: 47427482024ff9f626f7d661716e60ca@100.000.100.000
CSeq: 102 INVITE
Server: XCast Partner/1.1
Content-Length: 0


<------------->
[Sep 27 19:07:47] --- (8 headers 0 lines) ---
[Sep 27 19:07:47] Transmitting (NAT) to 38.102.250.50:5060:
ACK sip:19734500702@38.102.250.50;cpd=on SIP/2.0
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK6fe2cee8;rport
From: "V9271907200000016091" <sip:8623675566@100.000.100.000>;tag=as4b4a3489
To: <sip:19734500702@38.102.250.50;cpd=on>;tag=xcast-46912808388720
Contact: <sip:8623675566@100.000.100.000>
Call-ID: 47427482024ff9f626f7d661716e60ca@100.000.100.000
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "V9271907200000016091" <sip:8623675566@100.000.100.000>;privacy=off;screen=no
Content-Length: 0


---
[Sep 27 19:07:47]
<--- SIP read from 38.102.250.50:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK6fe2cee8;rport=5060
From: "V9271907200000016091" <sip:8623675566@100.000.100.000>;tag=as4b4a3489
To: <sip:19734500702@38.102.250.50;cpd=on>;tag=xcast-46912527990688
Call-ID: 47427482024ff9f626f7d661716e60ca@100.000.100.000
CSeq: 102 CANCEL
Server: XCast Partner/1.1
Content-Length: 0


<------------->
[Sep 27 19:07:47] --- (8 headers 0 lines) ---
[Sep 27 19:07:47]
<--- SIP read from 38.102.250.50:5060 --->
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK0bf524c7;rport=5060
From: "V9271907200000020555" <sip:8623675566@100.000.100.000>;tag=as583d095b
To: <sip:16094980361@38.102.250.50;cpd=on>;tag=xcast-46912796377392
Call-ID: 37f713100c0dec7370ca60751ca85c74@100.000.100.000
CSeq: 102 INVITE
Server: XCast Partner/1.1
Content-Length: 0


<------------->
[Sep 27 19:07:47] --- (8 headers 0 lines) ---
[Sep 27 19:07:47] Transmitting (NAT) to 38.102.250.50:5060:
ACK sip:16094980361@38.102.250.50;cpd=on SIP/2.0
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK0bf524c7;rport
From: "V9271907200000020555" <sip:8623675566@100.000.100.000>;tag=as583d095b
To: <sip:16094980361@38.102.250.50;cpd=on>;tag=xcast-46912796377392
Contact: <sip:8623675566@100.000.100.000>
Call-ID: 37f713100c0dec7370ca60751ca85c74@100.000.100.000
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "V9271907200000020555" <sip:8623675566@100.000.100.000>;privacy=off;screen=no
Content-Length: 0


---
[Sep 27 19:07:47]
<--- SIP read from 38.102.250.50:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.000.100.000:5060;branch=z9hG4bK0bf524c7;rport=5060
From: "V9271907200000020555" <sip:8623675566@100.000.100.000>;tag=as583d095b
To: <sip:16094980361@38.102.250.50;cpd=on>;tag=xcast-46912532755760
Call-ID: 37f713100c0dec7370ca60751ca85c74@100.000.100.000
CSeq: 102 CANCEL
Server: XCast Partner/1.1
Content-Length: 0


When you look into the lead it show's no call history at all, and when you do a log search there are no logs of the call anywhere...

[williamconley]

possibly a difference in your dialplan from "manual" vs "auto".

I note that your log does not show the "dial" line of your dialplan execution. Only the result.

Which could make it quite difficult to see what could be a very simple cause ... (it may not be simple, of course, but it would be a serious failure not to at least Look at the actual execution of the dialplan before trying to "debug" what happens at the moment of termination ...).

also worthy of the question: have you tried this with "one call at a time" and then at increasingly higher load to see if there is a "threshold" or if it happens frequently even on one call at a time?

And ... is this a Virtual dialer?

[udfxrookie]

Problem was in dialplan.... tried making a custom dialplan for failover to go through three different carriers... bombed. New posting on failover.

[vccsdotca]

I am experiencing the same issue as this original post. From troubleshooting I gathered this was due to vicidial timing out the auto dial call as the logs show "CANCEL", so I figured vici kept the dispo as NEW because it had no other status. In this case the calls are actually no answers but they are not being treated as such.

Oddly, the calls using the PRI are treated with NA, it is only the VoIP calls that are staying as NEW. As long as the campaign dial timeout is longer than the carrier timeout I had assumed this would alleviate the issue but hasn't. Any suggestions would be great or as I have even tried to find agi code that depicts this behavior but no luck..I'll note they are using the same dial plan of

Code: Select all

agi_canada_pri-cidname.agi and 8369

thanks for anyones time.

Matt

[vccsdotca]

Please post the Asterisk output when Vicidial tries to place a call to one of these numbers. I have a feeling the numbers are not properly formatted for your dialplan. When this happens Vicidial will send the manager event to place the call and make the lead as called, but Asterisk will fail to send the call out. This results in the call never making it into the call_log AGI script and thus never has its status changed.

Interesting I think this is the actual reason but the calls arent actually "failing" they are just not being answered. So why are they not NA and what would cause the PRI to come back as NA..its not like the SIP code should matter...

[mcargile]

If you are using PRIs with asterisk 1.8 or 11 you need to put an 'i' in the dial command options. With out it the DAHDI drivers changes the caller ID name which causes Vicidial to lose the call.