
Originally Posted by
VOIPoTim
What basically happened is that a VM notification went out from our VM servers and since the system detected you were on two servers, it would send to one and that one would send to the other, on and on.
This used to not happen, but since the VOIPo to VOIPo internal calling fix, things are organized a little differently in terms of how on network packets are handled and this was an unforseen effect of that.
The loop created some sporadic behavior on central01 and central02 since those were the servers involved. In a situation like this, the top priority is to minimize impact and restore service as a whole. From what I understand they put the temporary block on was they were concerned that once they stopped the loop, the ATA and softphone would be "fighting with each other" to re-register and both would end up doing so then if a VM MWI notification was triggered somehow, it'd just happen again. So that's why they blocked it.
I agree though that you should have been notified and am going to look into it a little more to make sure this stuff is handled better in the future. Sorry for the inconvenience.
We also have a few changes that are being finalized/tested in terms of the way multiple registrations are handled and also how we deal with softphone/grandfathered BYOD accounts so that they're not able to impact the "general population" as a whole (whether intentionally or unintentionally).
Bookmarks