On Tue, 2008-09-09 at 11:46 -0400, Hesham Abdelrahman wrote: > Nested hunt group problem details > > We want to create a nested hunt groups in here for example will call > them hunt groups A,B and C > > For each hunt group will add some users > > Hunt group A will have user 1 and 2 > > Hunt group B will have user 3 and 4 > > Hunt group C will have user 5 and 6 > > Hunt Group A is configured that it will ring both user 1 and 2 at the > same time for 15 seconds, then if no answer it will fall back to > destination that is hunt group B > > Hunt Group B is configured that it will ring both user 3 and 4 at the > same time for 15 seconds, then if no answer it will fall back to > destination that is hunt group C > > Hunt Group C is configured that it will ring both user 5 and 6 at the > same time for 15 seconds, then if no answer it will fall back to > destination that is operator 100. > > Problem details. > > When user x calls hunt group A, > > user 1 and 2 start to ring, when there is no answer for 15 seconds it > falls to hunt group B > > user 3 and 4 start to ring and the Default Serial Fork Expiration > timer starts "default value is 20 seconds" ,when there is no answer > for 15 seconds it falls to hunt group C > > User 5 and 6 start to ring and when there is no answer for 15 seconds > it falls to the operator ext 100. and the Default Serial Fork > Expiration timer is now at 30 seconds. > > The problem when the Default Serial Fork Expiration timer expires "now > at 20 seconds" the call fails so we need to set the Default Serial > Fork Expiration timer to a long period, like 40 seconds, when that > happen the normal operation of voice mail on no answer, etc. would be > impacted and voice mail will not kick in till 40 seconds when the > Serial Fork Expiration timer expires and that is a long time. > > So we are looking for a work around that would allow nested hunt group > to work with out having the Default Serial Fork Expiration timer to > impact this operation.
Both Robert and Dale are correct. The right way to configure this (and the _only_ way that will work correctly) is to make it all one hunt group; it is easy to configure the behavior you want that way (in fact, it is easier than creating separate hunt groups). Essentially, nested hunt groups do not do what one might think they should, and it would be quite difficult to change this. We could consider actually changing sipXconfig to prohibit configuration of nested hunt groups, but for some very simple configurations it works acceptably, so I don't think that's worth the effort. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
