Step 5: Limiting the queue capacity

Last Updated : Jun 04, 2018 |

Hunt group queue slots are allocated dynamically. Therefore, there is no need to include vector steps to ensure that pre-allocated queue slots in a hunt group have not been exhausted. The existing vector steps that checked for exhaustion also serve as queue-limiting vectors as is, or modified to limit a different number of calls. The following vector example describes provisions for limiting the number of calls that queue to a split/skill or a hunt group.

Limiting number of queued calls

                                                         Page 1 of 1
                           CALL VECTOR
 Number: 27            Name: base                Multimedia? n    Lock? n
Multimedia? n      Attendant Vectoring? n    Meet-me Conf? n           Lock? y
     Basic? y   EAS? n   G3V4 Enhanced? n   ANI/II-Digits? n   ASAI Routing? n
 Prompting? n   LAI? n  G3V4 Adv Route? n   CINFO? n   BSR? y      Holidays? y

 01 goto step 10 if calls-queued in split 5 pri l > 20
 02 queue-to split 5 pri l
 03 wait-time 10 seconds hearing ringback
 04 announcement 2771
 05 wait-time 10 seconds hearing music
 06 check split 7 pri m if calls-queued < 5
 07 wait-time 60 seconds hearing music
 08 announcement 2881
 09 goto step 6 if unconditionally
 10 busy
 11 _______________

A check of split 5 is implemented by the goto step command in step 1. The goto step command tests if the split contains more than 20 calls using the condition if calls-queued in split 5 pri l > 20. If this test is successful, control is passed to the busy command in vector step 10. The busy command provides a busy signal to the caller and eventually causes the call to drop.

Alternately, if 20 or less medium priority calls are already queued to the main split when step 1 executes, the queue-to split command in step 2 queues the call and vector processing continues at step 3.