I never said there was a bug. I don't think it is a bug. For me a bug is something wrong in the code, so the application does not behave as it is expected. In this case the code is right. It does what it is expected to do. Problem is, I think the expected behavior is a bad behavior. Maybe the original developer did not think carefully about this. There is very little use on real life scenarios, unless all destinations have plenty of free resources, so they can process double or triple load. Maybe the guy would say "yeah, it's a good improvement! Let's do it in a backward compatible way!"

Please, take a look at issue #2361. if, instead of Calls, those were CAPS, so every destination processes 1000CAPS. What if those nodes can't process 2000 CAPS? For instance they are capable of processing 1500CAPS. When one destination fails, the next will receive 2000 CAPS. But it can't. Currently Kamailio can't solve that scenario. Wouldn't it be better that every destination now processes 1200 CAPS?

That was the point I wanted to discuss. A better distribution. If everything is normal. Every destination receives, more or less, same amount of calls (it's just hash, not fair distribution). If some destinations fail, the calls they were supposed to receive are better distributed over the remaining destinations, but respecting the hash : same hash, same destination.

If servers active change between INVITE and other messages, I don't think there is a stateless way to solve it. The current implementation also fails. First, for what I saw in the code, the list contains all destinations, not just those active. Once hashid is obtained, modulo #total destination is applied, and then state of destination is checked. If it's not active, next is selected. if next is active, INVITE is sent to it.

What if, when CANCEL is received, the original destination was again active? Hashid is obtained, modulo #total, server is active, CANCEL is sent to wrong server. As I said, I don't think there is a fully stateless way to solve it. kamailio should memorize original destination, or something complex, beyond the scope of a simple hash.

I did care about continuing service. OK, if a server goes down and later goes up, it will cause some calls to fail, with current implementation and also mine. But, service should continue. It would be a high availability platform, that can continue providing service to new calls, but failing on transient ones. And with a better distribution.

I did not want to add a new feature. I wanted to improve existing ones. The hash algorithms can be improved, as any part of the code may eventually be improved.

Now, if I wanted to implement it your way, in a new algorithm, I have no idea about how could I get inside function ds_manage_routes() the value to be used as a hash. You said, for instance, $var(dshash) = $ci . How can I get the content of dshash inside that function?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.