Hi,
I'm having troules with a huntgroup and an overflow group.
HG "A" with 1 member in it (no VM, queing on, no answer time = 10sec, overflow time = 15sec)
Overflow group list is set to HG "B" (with multiple phones in it, collective, no VM, queing on, no answer time 60, overflow off)
When pointing an incoming call route to HG "A" the following happens:
- the only member of HG A rings for 20sec
- overflow kicks in -> HG B (all the members) ring for 10sec
- HG A starts again for 10sec
- HG B again for 10sec
- loop (A for 10sec, B for 10sec)
I have no idea why it uses 20sec the 1st time (I changed the system default settings to 60sec, ...), rebooted the PBX, ...
I thought it would work like this:
- HG A rings untill the overflow time is reached (the no answer time is not used for collective hunt groups). When the overflow time is reached, the call goes to the overflow HG (if set!).
It stays in this overflow group (or it returns to the first group when the overflow time of the 1st HG is reached again)
Testing environment is R5.0(22) with 54xx phones. However I started to test this after a message from a colleague who had similar problems on a 6.1 release.
I'm having troules with a huntgroup and an overflow group.
HG "A" with 1 member in it (no VM, queing on, no answer time = 10sec, overflow time = 15sec)
Overflow group list is set to HG "B" (with multiple phones in it, collective, no VM, queing on, no answer time 60, overflow off)
When pointing an incoming call route to HG "A" the following happens:
- the only member of HG A rings for 20sec
- overflow kicks in -> HG B (all the members) ring for 10sec
- HG A starts again for 10sec
- HG B again for 10sec
- loop (A for 10sec, B for 10sec)
I have no idea why it uses 20sec the 1st time (I changed the system default settings to 60sec, ...), rebooted the PBX, ...
I thought it would work like this:
- HG A rings untill the overflow time is reached (the no answer time is not used for collective hunt groups). When the overflow time is reached, the call goes to the overflow HG (if set!).
It stays in this overflow group (or it returns to the first group when the overflow time of the 1st HG is reached again)
Testing environment is R5.0(22) with 54xx phones. However I started to test this after a message from a colleague who had similar problems on a 6.1 release.