Not sure if I should report this as a 'feature request' {this this 'feature' is not yet available..} or as a 'problem' since it's a great limitation/problem for us..
When checking off 'disallow loop' the sippy system seems to overreact even for calls which could not possibly be considered a loop. Whenever there's an active call (even just one), than any subsequent call would be detected if the ANI & DNIS are matching. even if the second call began 3 minutes later (or more...)
We've had numerous complains from customers where 3-5 people of an office were trying to call in to a given conference bridge, and the 2nd call was already rejected.
I propose that Sippy allows some more 'reasonable' detectors to the call, (or perhaps allow choosing a moderate version of disallowing loops) which would 'allow' calls after xx amount of seconds from the first call. We'd probably choose to 'allow' any 'loop' call as long it's 2 seconds away from the original call..
Yisro / Softswitch
Not sure if I should report this as a 'feature request' {this this 'feature' is not yet available..} or as a 'problem' since it's a great limitation/problem for us..
When checking off 'disallow loop' the sippy system seems to overreact even for calls which could not possibly be considered a loop. Whenever there's an active call (even just one), than any subsequent call would be detected if the ANI & DNIS are matching. even if the second call began 3 minutes later (or more...)
We've had numerous complains from customers where 3-5 people of an office were trying to call in to a given conference bridge, and the 2nd call was already rejected.
I propose that Sippy allows some more 'reasonable' detectors to the call, (or perhaps allow choosing a moderate version of disallowing loops) which would 'allow' calls after xx amount of seconds from the first call. We'd probably choose to 'allow' any 'loop' call as long it's 2 seconds away from the original call..
Thanks for your consideration (hopefully ;)
1 person likes this idea