New Enhanced Disconnect Logging Option 3

[jamiemurray]

I posted a patch on the bug tracker for introducing Enhanced Disconnect Logging Option 3 to address the issue of temporary carrier failures causing leads to go to ADC incorrectly.
http://www.vicidial.org/VICIDIALmantis/view.php?id=1367

[dreedy]

what is the option breakdown of this function the help does not go into detail on the option of 2 through 6.
Is there a explanation of this somewhere?

[mflorell]

From the help:

"Enhanced Disconnect Logging -
This setting, set to 1, enables logging of calls that get a CONGESTION signal with a cause code of 1, 19, 21, 34 or 38. Setting this to 2 will additionally log calls with cause codes of 18-CHANUNAVAIL and 102. Setting this to 3 will alternatively prevent some temporary error SIP messages on failed calls from sending the lead to ADC status. Instead, the status will be set as HUCXXX where XXX is the hangup_cause code. Eg. HUC18 for Cause 18 (SIP 408 Request timeout). Default is 0 for disabled."

Only options 0,1,2,3 are active, options 4,5,6 are there for future expansion.

[dreedy]

Thank you.

[pimo1974]

From the help:

"Enhanced Disconnect Logging -
This setting, set to 1, enables logging of calls that get a CONGESTION signal with a cause code of 1, 19, 21, 34 or 38. Setting this to 2 will additionally log calls with cause codes of 18-CHANUNAVAIL and 102. Setting this to 3 will alternatively prevent some temporary error SIP messages on failed calls from sending the lead to ADC status. Instead, the status will be set as HUCXXX where XXX is the hangup_cause code. Eg. HUC18 for Cause 18 (SIP 408 Request timeout). Default is 0 for disabled."

Only options 0,1,2,3 are active, options 4,5,6 are there for future expansion.

I notice when option 3 is set leads that get huc 18 21 23 etc do get disposed by system but they get dialed again on next reset even though they are not set as dialable. Is this expected behavior?

[williamconley]

From the help:

"Enhanced Disconnect Logging -
This setting, set to 1, enables logging of calls that get a CONGESTION signal with a cause code of 1, 19, 21, 34 or 38. Setting this to 2 will additionally log calls with cause codes of 18-CHANUNAVAIL and 102. Setting this to 3 will alternatively prevent some temporary error SIP messages on failed calls from sending the lead to ADC status. Instead, the status will be set as HUCXXX where XXX is the hangup_cause code. Eg. HUC18 for Cause 18 (SIP 408 Request timeout). Default is 0 for disabled."

Only options 0,1,2,3 are active, options 4,5,6 are there for future expansion.

I notice when option 3 is set leads that get huc 18 21 23 etc do get disposed by system but they get dialed again on next reset even though they are not set as dialable. Is this expected behavior?

Please describe in detail "not set as dialable"? Do you refer to "called since last reset" or "status"?

[pimo1974]

From the help:

"Enhanced Disconnect Logging -
This setting, set to 1, enables logging of calls that get a CONGESTION signal with a cause code of 1, 19, 21, 34 or 38. Setting this to 2 will additionally log calls with cause codes of 18-CHANUNAVAIL and 102. Setting this to 3 will alternatively prevent some temporary error SIP messages on failed calls from sending the lead to ADC status. Instead, the status will be set as HUCXXX where XXX is the hangup_cause code. Eg. HUC18 for Cause 18 (SIP 408 Request timeout). Default is 0 for disabled."

Only options 0,1,2,3 are active, options 4,5,6 are there for future expansion.

I notice when option 3 is set leads that get huc 18 21 23 etc do get disposed by system but they get dialed again on next reset even though they are not set as dialable. Is this expected behavior?

Please describe in detail "not set as dialable"? Do you refer to "called since last reset" or "status"?

I mean that HUC21 etc are not even dialable statuses in the first place.
So this happens with the feature on I will have say 400 HUC21 at end of day. next day I start dialing and that number is for instance 120. The statuses also don't show up in export calls report so haven't been able to export them that way to track them. my assumption is that the HUC statuses are visual and are maybe actually ADC's? I think this since they are not in system statuses and are activated by enabling enhanced disconnect logging. is this correct? To give some more context I have multiple clusters all of differing versions and SVN's from as old as vici 8 svn 3775 to as new as vici 11 svn 3835 we even have some older svns that do not have this feature. It behaves the same on all the clusters so I'm assuming its as it should be just trying to get an understanding of whats going on? We use this to track fed dncs as we have our switch set to return huc21 for any numbers in our feddnc DB or litigators db. We wanted to give some amount of visual feedback to users without having to run a carrier log report and it works great for that. They get a general idea of the amount of bad leads being dialed in the counts on camp screen. But it seems like these leads get put back into the ADC pool after a period of time, from my observations at least.

[jamiemurray]

You would need to add those statuses to System Statuses or even Campaign Statuses for them to show on reports as selectable statuses or to be able to add them to the dialable statuses for a campaign.

[williamconley]

HUC21 likely explanation: "AST_CAUSE_CALL_REJECTED 21. Call Rejected"

Hang Up Cause. 21. This could be a temporary situation if you have failover calling. (or even without it: Enhanced Disconnect is in play ... so ... those could just get automatically reinserted).

Do you have lead recycling active?

docs/VICIDIAL_statuses.txt has some possibly useful information on the topic.

Happy Hunting!