cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2523
Views
7
Helpful
12
Replies

Behaviour of LAA node in ICM scripting

piyush aghera
Spotlight
Spotlight

Hi All,

Could anyone please help me with the behaviour of LAA node in ICM scripting. 

My basic need is to know when the call will come out of the failed node of the LAA node.

What basically i am doing is:

- first i am checking if any agent is available in a particular skill group

- if available, then check the longest available agent by LAA node

- and forward that call to that agent

But i am seeing many calls are coming out of failed node of LAA node, on an average 150 such instances; but i am not able to re-create the similar issue in my Lab; nor in live environment.

How do i trace what exactly happened to these calls, are there any specific logs available to do so?

Any help in understanding this will be of a great help.

i am using ICM 8.0

Thanks in advance.                  

1 Accepted Solution

Accepted Solutions

The fix to your issue it to change your if on the agent availability if agents.avail >0 will work for you


See below a discussion on extrapolation





Extrapolation Example

Assume that a simple routing script attempts to load balance calls based only on the number of calls in queue, and sends the call to the site with the fewest calls.

Note: Although this example refers to calls in queue, the same mechanism is used for a number of other variables, listed later in the document.

A call arrives.

The router picks a site, and sends the call.

The network delivers the call.

The ACD sees the call arrive, and runs an internal script that places the call in queue.

Cisco ICM (through the PIM and OPC) notices the call and the change in queue statistics.

Cisco ICM reports back to the router, where the number of calls in queue is updated.

All of this takes time to happen. It can take seven seconds for all these steps to occur. For those seven seconds, the router still thinks the number of calls in queue is the original value. If the router is given a new call to route, the router still thinks the same site is the best site. In a high volume application, you can easily send dozens of calls to the site before you finally receive an updated queue count from the PG. At that point, some other site suddenly looks much better, and the router sends all calls to that site. The phenomenon is called “fire hose routing”.

This is simply an example. The amount of time depends on the network, ACDs, or VRUs involved. The router has limited information to resolve this issue. In particular, there is no way for the router to match incoming data from the PG with actual calls that are routed. Therefore there is no way to know, for example, which calls are included in the calls in queue metric when the PG reports the queue count.

The extrapolation mechanism in the router is a solution implemented in Cisco ICM. The mechanism is used to try to estimate the real value. Here is how extrapolation works for a variable like CallsQueueNow for a service:

Internally, CallsQueueNow is managed in two parts:

CallsQueueNow base value, which is the value last reported by the PG.

CallsQueueNow adjustment, which is managed by the router.

When a routing script references CallsQueueNow, it sees the sum of the base value and the adjustment. When CallsQueueNow is sent in the real time feed to the AW, only the base value is sent. In order to manage the adjustment, the router adds 1 when the call is routed to the service, and then sets a timer. The default value for the timer is 10 seconds. When the timer expires, the router subtracts 1 from the adjustment.

Here is an example with actual numbers:

Assume that there are 3 calls in queue:

At the start, base=3, adjustment=0

A call arrives, and is routed to the service, base=3, adjustment=1. Other calls routed at this point see 3+1=4 calls in queue.

Seven seconds later, the PG reports there are 4 calls in queue. Now base=4, adjustment=1 (still). Calls routed at this point see an overestimated value of 5 calls in queue.

Three seconds later, the 10-second extrapolation timer expires. Now base=4, adjustment=0.

This example indicates an overestimation of the number of calls in queue.

Similar mechanisms are used on a number of routing parameters. This table lists the variables that are extrapolated:

Object Fields Direction
Service CallsQNow Up
ExpectedDelay Up
CallsInProgress Up
CallsInNow Up
Skill Group AgentsAvailable Down
NetworkTrunkGroup TrunksIdle Down
CallsInNow Up
The direction column indicates the direction in which the adjustment is made [+1 (Up) or –1 (Down)]. An extrapolation mechanism is also used to manage agents.

In particular, the LongestAvailableAgent variable is managed through a mechanism that is entirely different from what is described here. The router receives status on individual agents from the PG. Internally, it maintains a list of all available agents, ordered by the time when the agent becomes available.

When an agent is selected (for example in LAA), the router marks the agent at the head of the list as “temporarily unavailable” for 10 seconds. During this time, the PG ignores the state report, and the router assumes that the agent is unavailable. After that time, the agent state reverts to whatever the PG last reported. This mechanism allows the router to account for the use of specific agents, and enables recovery if the ACD happens to send a call to the wrong agent. This kind of routing can be more precise than the other metrics. This is because no adjustments are made as long as the ACD sends the calls to the agents that the router guesses.

Sometimes, there can be a confusion about the behavior of AgentsAvailable and LongestAvailable. AgentsAvailable is adjusted by the up/down algorithm, and can underestimate the number of agents available. LongestAvailable is computed independently from the available agent list. LongestAvailable can show an agent available even though AgentsAvailable indicates zero. Therefore, LongestAvailable is more accurate, as mentioned earlier.

Sent from Cisco Technical Support iPad App

View solution in original post

12 Replies 12

Senthil Kumar Sankar
Cisco Employee
Cisco Employee

Hi Piyush,

Does the agents have Auto Answer enabled or it will ring ?

You can track a single of such behviour, the Wrong branch of LAA reach to a destination or IVR. Use that finalobjecID of that script and run the query in RCD and find exactly what happens in the call.

You can also check RTR logs as well

I would also suggest you to check Target Requey Feature. You have an option to check Target Requey option.

If there are transient failures, Router serches for the second target.

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_7_0/user/guide/ipce70sg.pdf

Regards,

Senthil

Hi Senthilkumar,

Thanks for looking into this.

Few agents do have auto answer enabled, will it make any problem?

also currently i am not using the Target Requery Feature.

Could you please let me know how do i get the finalobjectID for a script.

Thanks again.

Hi Piyush,

No Auto answer should not make any problem.

Probably you may need to check is there any routing issues or network issues.

You will get the FinalObjectID and ScriptID for a call from the Route_Call_Detail table. Just have a look at the below link

https://supportforums.cisco.com/docs/DOC-16491

Regards,

Senthil

Can you post a picture of your script and of your queue to skill group node please?

david

Hi David and Senthil,

Please find the attached screenshot of the script.

Also please find attached RCD and TCD logs for one of the calls which came out of the failed connection of LAA node of the same script; but again i could not find a particular reason why it came out of the failed connection.

Please review the logs and let me know if it is possible to identify the reason of this behaviour.

Thanks.


Couldnt find how to upload an excel file, so please find below logs:

RCD:

RecoveryKeyDialedNumberIDRouterCallKeyDayRouterCallKeyRouteIDDateTimeRequestTypeRoutingClientIDOriginatorTypeUnusedRoutingClientCallKeyPriorityMsgOriginVariable1Variable2Variable3Variable4Variable5UserToUserANICDPDCEDScriptIDFinalObjectIDCallSegmentTimeNetQTimeCallTypeIDRouterErrorCodeCallTraceRecoveryDayTimeZoneNetworkTargetIDLabelIDOriginatorVariable6Variable7Variable8Variable9Variable10TargetLabelIDRouterCallKeySequenceNumberRouterQueueTimeVruScriptsLabelTargetLabelDialedNumberStringBeganRoutingDateTimeBeganCallTypeDateTimeTargetTypeMRDomainIDRequeryResultVruProgressDbDateTimeECCPayloadID
5956312233256312150578999536805:17.065007NULLNULL35164303NULL1937003frFRNULLAXA-BNF-frFRNULLNULLNULL33237300253NULL115629880066460NULL0300NULL12831-1NULLNULLNULLNULLNULL128311062650926509496920174441404:21.005:17.0410005:32.1NULL

TCD:

RecoveryKeyMRDomainIDAgentSkillTargetIDSkillGroupSkillTargetIDServiceSkillTargetIDPeripheralIDRouteIDRouterCallKeyDayRouterCallKeyDateTimePeripheralCallTypeDigitsDialedPeripheralCallKeyCallDispositionNetworkTimeDurationRingTimeDelayTimeTimeToAbandHoldTimeTalkTimeWorkTimeLocalQTimeBillRateCallSegmentTimeConferenceTimeVariable1Variable2Variable3Variable4Variable5UserToUserNewTransactionRecoveryDayTimeZoneNetworkTargetIDTrunkGroupIDDNISInstrumentPortNumberAgentPeripheralNumberICRCallKeyICRCallKeyParentICRCallKeyChildVariable6Variable7Variable8Variable9Variable10ANIAnsweredWithinServiceLevelPriorityTrunkWrapupDataSourceAgentPeripheralNumberSourceAgentSkillTargetIDCallDispositionFlagRouterCallKeySequenceNumberCEDCallTypeIDBadCallTagApplicationTaskDispositionApplicationDataNetQTimeDbDateTimeECCPayloadIDCallTypeReportingDateTimeRoutedSkillGroupSkillTargetIDRoutedServiceSkillTargetIDRoutedAgentSkillTargetIDOriginatedCallReferenceIDCallGUIDLocationParamPKIDLocationParamNamePstnTrunkGroupIDPstnTrunkGroupChannelNumberNetworkSkillGroupQTimeEnterpriseQueueTimeStartDateTimeUTCProtocolID
5956485115561NULLNULLNULL5007NULL15057899904:21.31NULL351643037000000000NULLNULL0NULLNULLNULLNULLNULLNULLN0300NULLNULL4969201744414NULLNULL269663443NULLNULLNULLNULLNULLNULLNULL33237300253NNULLNULLNULLNULLNULL31NULL-1N0NULL004:39.1NULL00:00.0NULLNULLNULLNULLNULLNULLNULLNULLNULL00004:21.31
5956485115711NULLNULL70465008511015057899905:17.314969201744414898328056056560000NULLNULL0937003frFRNULLAXA-BNF-frFRNULLNULL1609871/2N030062385007NULLNULLNULL269663444NULLNULLNULLNULLNULLNULLNULL33237300253NNULLNULLNULLNULLNULL1216646N0NULL005:30.3NULL00:00.0NULLNULLNULLNULLNULLNULLNULLNULLNULLNULL0004:21.33
595648511630196659658NULL5007536815057899910:53.8249692017444143516430313133881002091200NULLNULL0937003frFRNULLAXA-BNF-frFRNULLNULLNULLN03007357NULL2650926509100011269663462NULLNULLNULLNULLNULLNULLNULL33237300253NNULLNULLNULLNULLNULL1316646N0NULL011:11.2NULL00:00.09658-19665NULL000000000018908F029C727800000000NULLNULLNULLNULL00005:15.81

Couple of things here,

1) What exactly you have given in the IF condition to check, Can you use a Set Variable to store that number of agents Aailable in the Skillgroup you are checking in any of the free Peripheral Variables before reaching the LAA and after the Wrong branch of the LAA in another Peripheral Vairble.

In formula Editor of Set Variable

SkillGroup.Test_Sg.Avail

2) Did you had a chance to look into the Router Logs.

Regards,

Senthil

Hi Senthil,

1) If condition is as below to check the availability of the agent in a particular skill group:

SkillGroup.Test_Sg.Avail

I have lot of scripts in production, so i can not change all the scripts as per your advice.  however i have updated a script which is generating the most number of failed LAA connections.

I will keep you posted once i'll get hit on this script.

2) no, i haven't got chance to check the router logs.

Thanks.

Hi Senthil,

The script which i had modified to capture the availabel agent before and after LAA node as per your advice had captured some data.

For all the instances where the call came out of the failed connection of LAA node, the variables had captured value of available agent as -1.

The latest incident happened today morning at 08:30 IST, for which i had checked the rotuer logs, but no errors found.

Would you like to have logs for these instances to help me further on what could be causing this.

Thanks.

Hi Senthil,

I have found answers to my queries, the behaviour is described as extrapolation mechanism by Cisco.

Also i have got answer that the IF conditon to check agent availability with .Avail condition will return true for all the values except 0.  Due to extrapolation mechanism, this condition will return -1 value for high volume call centers and condition becomes true.

Thank you very much for all your time and efforts in trying to help me out with this discussion.

The fix to your issue it to change your if on the agent availability if agents.avail >0 will work for you


See below a discussion on extrapolation





Extrapolation Example

Assume that a simple routing script attempts to load balance calls based only on the number of calls in queue, and sends the call to the site with the fewest calls.

Note: Although this example refers to calls in queue, the same mechanism is used for a number of other variables, listed later in the document.

A call arrives.

The router picks a site, and sends the call.

The network delivers the call.

The ACD sees the call arrive, and runs an internal script that places the call in queue.

Cisco ICM (through the PIM and OPC) notices the call and the change in queue statistics.

Cisco ICM reports back to the router, where the number of calls in queue is updated.

All of this takes time to happen. It can take seven seconds for all these steps to occur. For those seven seconds, the router still thinks the number of calls in queue is the original value. If the router is given a new call to route, the router still thinks the same site is the best site. In a high volume application, you can easily send dozens of calls to the site before you finally receive an updated queue count from the PG. At that point, some other site suddenly looks much better, and the router sends all calls to that site. The phenomenon is called “fire hose routing”.

This is simply an example. The amount of time depends on the network, ACDs, or VRUs involved. The router has limited information to resolve this issue. In particular, there is no way for the router to match incoming data from the PG with actual calls that are routed. Therefore there is no way to know, for example, which calls are included in the calls in queue metric when the PG reports the queue count.

The extrapolation mechanism in the router is a solution implemented in Cisco ICM. The mechanism is used to try to estimate the real value. Here is how extrapolation works for a variable like CallsQueueNow for a service:

Internally, CallsQueueNow is managed in two parts:

CallsQueueNow base value, which is the value last reported by the PG.

CallsQueueNow adjustment, which is managed by the router.

When a routing script references CallsQueueNow, it sees the sum of the base value and the adjustment. When CallsQueueNow is sent in the real time feed to the AW, only the base value is sent. In order to manage the adjustment, the router adds 1 when the call is routed to the service, and then sets a timer. The default value for the timer is 10 seconds. When the timer expires, the router subtracts 1 from the adjustment.

Here is an example with actual numbers:

Assume that there are 3 calls in queue:

At the start, base=3, adjustment=0

A call arrives, and is routed to the service, base=3, adjustment=1. Other calls routed at this point see 3+1=4 calls in queue.

Seven seconds later, the PG reports there are 4 calls in queue. Now base=4, adjustment=1 (still). Calls routed at this point see an overestimated value of 5 calls in queue.

Three seconds later, the 10-second extrapolation timer expires. Now base=4, adjustment=0.

This example indicates an overestimation of the number of calls in queue.

Similar mechanisms are used on a number of routing parameters. This table lists the variables that are extrapolated:

Object Fields Direction
Service CallsQNow Up
ExpectedDelay Up
CallsInProgress Up
CallsInNow Up
Skill Group AgentsAvailable Down
NetworkTrunkGroup TrunksIdle Down
CallsInNow Up
The direction column indicates the direction in which the adjustment is made [+1 (Up) or –1 (Down)]. An extrapolation mechanism is also used to manage agents.

In particular, the LongestAvailableAgent variable is managed through a mechanism that is entirely different from what is described here. The router receives status on individual agents from the PG. Internally, it maintains a list of all available agents, ordered by the time when the agent becomes available.

When an agent is selected (for example in LAA), the router marks the agent at the head of the list as “temporarily unavailable” for 10 seconds. During this time, the PG ignores the state report, and the router assumes that the agent is unavailable. After that time, the agent state reverts to whatever the PG last reported. This mechanism allows the router to account for the use of specific agents, and enables recovery if the ACD happens to send a call to the wrong agent. This kind of routing can be more precise than the other metrics. This is because no adjustments are made as long as the ACD sends the calls to the agents that the router guesses.

Sometimes, there can be a confusion about the behavior of AgentsAvailable and LongestAvailable. AgentsAvailable is adjusted by the up/down algorithm, and can underestimate the number of agents available. LongestAvailable is computed independently from the available agent list. LongestAvailable can show an agent available even though AgentsAvailable indicates zero. Therefore, LongestAvailable is more accurate, as mentioned earlier.

Sent from Cisco Technical Support iPad App

I have already implemented the above solution and monitoring the situation.

Anyways thank you for your input and time.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: