Queue caps not working as expected

[hartlm]

I have the following set up in a queue. It is designed to restrict the number of callers who can queue to a skill towards the end of the day:
01 wait-time 1 secs hearing ringback
02 queue-to skill 4 pri m
03 goto step 33 if calls-queued in skill 4 pri m > 99
04 goto step 36 if time-of-day is all 16:59 to all 17:29
05 goto step 39 if time-of-day is all 17:30 to all 17:44
06 goto step 42 if time-of-day is all 17:45 to all 17:59

33 busy
34 stop
35
36 goto step 33 if calls-queued in skill 4 pri m >= 10
37 goto step 7 if unconditionally
38 stop
39 goto step 33 if calls-queued in skill 4 pri m >= 5
40 goto step 7 if unconditionally
41 stop
42 goto step 33 if calls-queued in skill 4 pri m >= 1
43 goto step 7 if unconditionally
44 stop

So for example, if a call was queued to the skill after 17:30 and there were 5 calls already in the queue, it would be forced busy.
Historical CMS reporting shows that calls are being forced busy, but the integrated reporting on the day shows that more calls are being allowed to queue than the cap is set at. For example, at 17:47 one there were 9 calls queueing; at the most there should have been 5, even allowing for calls still waiting from the earlier, higher cap interval.

Anyone have any ideas why that would be?

 

[AvayaTier3]

You should make test calls to your vdn while using list trace vdn and check to see if it's steps are working.

different vdns or calling the hunt-group directly would certainly allow someone to bypass your vector

A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"

bsh

37 years Bell, AT&T, Lucent, Avaya
Tier 3 for 27 years and counting

http://bshtele.com

 

[hartlm]

AvayaTier3 - There are only 2 VDNs pointing to the vector that the Q capping steps are in, so any calls queuing to the skill would have to pass through those steps. I will certainly make some test calls though, and comment on the results. Thanks

 

[europe]

there are a few pointers I can think of.

- I would perform the check before you queue the calls:

01 wait-time 1 secs hearing ringback
02 goto step 33 if calls-queued in skill 4 pri m > 99
03 goto step 36 if time-of-day is all 16:59 to all 17:29
04 goto step 39 if time-of-day is all 17:30 to all 17:44
05 goto step 42 if time-of-day is all 17:45 to all 17:59
06 queue-to skill 4 pri m

- I would change the 1st lineinto this:
01 wait-time 0 secs hearing silence

The way I was brought up in the Avaya world you can only do a BUSY signal on calls that have NOT yet received RING-BACK.
(it will work on internal calls, but the CO will not accept it)

The list trace would be a good starter







Please let me know if the information that was provided is helpfull.
Edwin Plat
A.K.A. Europe

 

[hartlm]

Thank you, Europe. I know the force busy is working as the CMS reporting shows calls being forced busy during the cap intervals, but I will make the change you have suggested and see if that helps keep the calls queuing to the defined limits.