Re: DIALER FLUSH- no ring after callresult = 25

michal_madejowski · ‎01-08-2018

Hello

I found something bad in my UCCE 9.0 version.
Dialer closed contact after it gave callResult = 25 and callstatuszone = B. In other campaigns evertything is ok.
I know that this status tell me that it was made some chacnge on campaign but normally after callresult=25 it should try to call in next time but in my case contacts was closed.

here is log from campaign manager:

campaignID: 5139
DialingListsID: 61

15:43:52:374 la-CampaignManager Trace: (CM_DLR) Received CloseCustomerRecord from Dialer ICM9-PG-02-A, DialingListID=61, CampaignID=5139, QueryRuleID=5421, CallResult=25
15:43:52:374 la-CampaignManager Trace: Executing SQL Command [UPDATE DL_5139_5421 SET CallsMadeToZone1=0, CallsMadeToZone2=0, LastNumberDialedZone1=1,LastNumberDialedZone2=0,LastZoneDialed=0, CallStatusZone1='B', CallStatusZone2='B',CallbackDateTimeZone1=NULL,CallbackDateTimeZone2=NULL,CallbackDateTime01=NULL,CallbackDateTime02=NULL,CallbackDateTime03=NULL,CallbackDateTime04=NULL,CallbackDateTime05=NULL,CallbackDateTime06=NULL,CallbackDateTime07=NULL,CallbackDateTime08=NULL,CallbackDateTime09=NULL,CallbackDateTime10=NULL,CallResult=25,CallResult01=25,CallResult02=0,CallResult03=0,CallResult04=0,CallResult05=0,CallResult06=0,CallResult07=0,CallResult08=0,CallResult09=0,CallResult10=0,CallbackNumber = '' WHERE DialingListID=61]

and from baDialer:

15:43:52:741 dialer-baDialer Trace: (CPORT) SetState, port: 292, state: PORT_DEVICE_ATTRIB
15:43:52:741 dialer-baDialer Trace: (CUST) SetCallResult, id: 61 in DL_5139_5421, skill: 7498, result: 1 [DIAL_RESERVED], now: [Mon Jan 08 15:43:52 2018], callback: [Mon Jan 08 14:32:36 2018]
15:43:52:741 dialer-baDialer Trace: (CUST) Validation failed, Current Time [Mon Jan 08 15:43:52 2018] - End Time [Mon Jan 08 14:39:30 2018]-[Mon Jan 08 15:10:00 2018]
15:43:52:741 dialer-baDialer Trace: (CUST) SetCallResult, id: 61 in DL_5139_5421, skill: 7498, result: 0 [IDLE], now: [Mon Jan 08 15:43:52 2018], callback: [Mon Jan 08 14:32:36 2018]
15:43:52:741 dialer-baDialer Trace: (CM) Invalid customer time, customer: 23006070xxxxx, dial Id: 61 in DL_5139_5421, result: 0
15:43:52:741 dialer-baDialer Trace: (CM) Close record request, customer: 23006070xxxxx, Dial Id: 61 in DL_5139_5421, result: 0 [IDLE]
15:43:52:741 dialer-baDialer Trace: (CUST) SetCallResult, id: 61 in DL_5139_5421, skill: 7498, result: 25 [DIALER_FLUSH], now: [Mon Jan 08 15:43:52 2018], callback: [Mon Jan 08 14:32:36 2018]
15:43:52:741 dialer-baDialer Trace: (CUST) Record sent to campaign manager, id: 61 in DL_5139_5421, skill: 7498, result: 25 [DIALER_FLUSH]

I have no idea why this is happening.
max attemps on this campaign is set to 5, no personal callbacks.

Mark Swanson · ‎01-08-2018

Check out this previous discussion;

https://supportforums.cisco.com/t5/contact-center/ucce-dialer-10-5-incorrect-timezone/td-p/2773865

michal_madejowski · ‎01-09-2018

Thnak You.
I have ImportAreaCodeProcDisable parameter set to "1",local time zome GMT+1 and I do not have personal callbacks on this campaign.
So my question is why is this happens? Whether someone changed something on campaign and dialer put callback in wrong time?
What should I do to fix it?

Mark Swanson · ‎01-09-2018

Check out this doc...

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/outbound_option/outboundoption9_0/installation/guide/UCCE_BK_O4A87BBC_00_outbound-option-guide-for-cisco/UCCE_BK_O4A87BBC_00_outbound-option-guide-for-cisco_appendix_0101...

Looking at Table1, code 25 means;

"Dialer has flushed this record due to a change in the skillgroup or the campaign"

However, your logs also revealed;

15:43:52:741 dialer-baDialer Trace: (CUST) SetCallResult, id: 61 in DL_5139_5421, skill: 7498, result: 1 [DIAL_RESERVED], now: [Mon Jan 08 15:43:52 2018], callback: [Mon Jan 08 14:32:36 2018]

15:43:52:741 dialer-baDialer Trace: (CUST) Validation failed, Current Time [Mon Jan 08 15:43:52 2018] - End Time [Mon Jan 08 14:39:30 2018]-[Mon Jan 08 15:10:00 2018]

15:43:52:741 dialer-baDialer Trace: (CUST) SetCallResult, id: 61 in DL_5139_5421, skill: 7498, result: 0 [IDLE], now: [Mon Jan 08 15:43:52 2018], callback: [Mon Jan 08 14:32:36 2018]

15:43:52:741 dialer-baDialer Trace: (CM) Invalid customer time, customer: 23006070xxxxx, dial Id: 61 in DL_5139_5421, result: 0

15:43:52:741 dialer-baDialer Trace: (CM) Close record request, customer: 23006070xxxxx, Dial Id: 61 in DL_5139_5421, result: 0 [IDLE]

Check the customer (23006070xxxxx) timezone located here; DL_5139_5421, Dial Id 61. If none is listed, then campaigns will use the default Daylight Savings Zone located under the [Call Target] tab.

Also, check out the following doc if you're using SIP Dialer;

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_11_0_1/User/Guide/UCCE_BK_O2927E6B_00_outbound-option-for-ucce-11-0/UCCE_BK_O2927E6B_00_outbound-option-for-ucce-11-0_chapter_011.html

Mark Swanson · ‎01-09-2018

Do you notice this problem with other Outbound Campaigns, if any? Or, do you notice this problem with other customers within the same campaign? Can you tell me... are your customers consider local (and they reside within the same time zone), long distance (and perhaps, they reside within the same time zone) or international... or, a combination of these?

michal_madejowski · ‎01-10-2018

In dialing list I have no zone selected, in configuration of the campaign I have Warsaw +01: 00 time zone.
For now I have this problem only on one campaign. I have 10 contacts in DL_5139_5421 and 5 with this issue. Every customer number are polish mobile number (with prefix +48) so I be sure that they are from the same time zone.

Mark Swanson · ‎01-10-2018

You previously mentioned a configuration change. What did you change exactly (i.e. campaigns, skill groups, etc.)?

Result code 25 represents;

"Dialer has flushed this record due to a change in the skillgroup or the campaign"

I believe, code 25 also applies to changes in the enterprise/service parameters which directly impact the campaign(s) or skill group(s) configurations.

Have you or your agents attempted to place a call to these numbers yet? What happens? Do you know if the same contacts always fail during the campaign or does it randomly fail?

Also, you mentioned the customers time zone was GMT+1. Where is your system located at? Are you using UTC, GMT or a local time zone? Check the Outbound Dialer and Campaign Manager clocks (time zones), they should be synchronized to the same time zone via ntp - right? I mean, the timestamps in the logs appeared to be synchronized.

What type of campaign do you have? And, which mode?

Mark Swanson · ‎01-10-2018

Notes on Editing a Campaign in Progress

You can edit most campaign configuration settings while a campaign is running. The changes take effect with new calls after the setting has been changed. However, avoid the following edits to a campaign in progress:

Do not modify the Max Attempts value. Modifying this value while a campaign is in progress can cause a long delay in record retrieval and longer agent idle times.
Do not delete a skill group while a campaign is in progress.

michal_madejowski · ‎01-11-2018

unfortunately I do not know what changes was made, another user made them.
no, agents do not tried to ring this number again but numbers are ok, here is screen from contact history.

in campaign I have UTC +01:00 zone. Time from logs are correct. All my UCCE systems have UTC +01:00 time zone.

this is normal agent based campaign in progressive mode. Even the max attemps was changed, the contacts should ring in future.Skill group have never been removed.

Mark Swanson · ‎01-11-2018

How many zones do you have?

Mark Swanson · ‎01-12-2018

Michal,

Are you still experiencing problems? If so, can you please provide;

1) Screenshots of the admin script and schedule?

2) Screenshots of the campaign configurations?

3) Complete trace logs for baimport, campaignmanager and badialer?

Have you recently restarted the loggers?

Thanks!

michal_madejowski · ‎01-15-2018

I do not know where can I check this but every campaign work in 1 time zone - UTC +1.
For now I do not have additional cases, campaign works properly
I send You link with logs but without baimport. The last time I restarted the logger 25 days ago.

Mark Swanson · ‎01-19-2018

Sorry for the delay.

I reviewed your screenshots and logs. I didn't find a smoking gun but I noticed a few questionable things, such as; your admin script containing variables for RAT_SG.Outbound and query rules with what appears to be names beginning with [spaces]. What's the purpose of RAT_SG.Outbound running in progressive mode during the same schedule as KART_SG.Outbound? And, how many agents are typically assigned to each SG? According to the logs, there's 3 agents logged into the KART_SG and 0 agents logged into the RAT_SG. However, the KART_SG doesn't appear to be very active compared to other campaigns - at least during this log capture. One option might be to increase the number of lines per agent, from 1 to 1.5 or something. Does the KART_SG.Outbound handle calls for other campaigns as well? Or, do you have agents assigned to multiple SG (specifically, agents assigned to KART_SG.Outbound)?

Plus, the only non-default campaign setting I noticed was 'No Answer Ring Limit' was changed from 4 to 5. I don't know if this type of change requires a restart or not. Obviously, I don't know when this was changed.

Another thing, the logs revealed the ring timeout value varies. Does that sound right? Most of them timeout at 40 seconds but some of them timeout at 20, 24, 48, etc.

If anything was changed while the campaign was active, most likely, it was the targets (baimports). Cisco docs claim, if you import targets while the campaign is active or if you rearrange the numbers under the Call Target tab... some numbers might become 'unreachable'. Since you already disable the ImportAreaCodeProcDisable setting, the campaign queries the Region_Prefix database for the customer's time zone. If none is listed, the campaign time zone is used. Therefore, check the Region_Prefix table for valid prefixes. Do you know if these query rules are used by other campaigns as well? Are you using SIP Proxy with or without IVR?

Let me know if this is still a problem for you or not. Good luck.

michal_madejowski · ‎01-26-2018

Thanks for answer.
RAT_SG exist because I created 2 campaign which is are similar but they are not always be enable together.
There is about 6 agents on this campaign (KART.SG), it is not a big Campaign. Yes it is possible that agents are assigned more than one skill KART.SG. I don't thik that chanccge "No Answer Ring Limit" will have some impact on this situation. The ring timeout value are varies because we have a lots of campaign and it is possible that they are otherwise configured than this one
I have a lots of records in Region_Prefix table but I am using SIP Proxy to route connection between ports on gateway

Mark Swanson · ‎01-26-2018

Hmmm Ok. What happens if you validate the query rules? Any syntax errors? What do they look like? If everything appears to be Ok, then you can click 'Update' to apply the changes. If you don't update the list, then changes won't apply until the next import. How often do you import (update) the list? According to your logs, it seems like KART_QR and KART_R_QR don't provide records. Only the GOT_U_QR provide records after the FLUSH event.