Less predictive algorithm for carrierroute hashing

[whosgonna]

Description

Carrierroute's CRC32 algorithm over call_id tends to produce poor call distribution under real world examples. Having 4 records for a given carrier/domain combo (assuming no flags, mask, or scan_prefix) and a probability of 0.25 using a hash source of call_id I observed over 800 hundred consecutive calls from a carrier (bandwidth.com) where CRC32(call_id) % 1000 was less than 250.

To be fair, the module does what it says - it uses a CRC32 hash over the call id, however the data from the UA generating the call is yielding poor results. Would it be possible to change to an alternate hashing mechanism (or add another hashing mechanism, selectable via modparam) such as MD5?

Expected behavior

Even distribution across all hosts provided.

Actual observed behavior

Uneven distribution under real-world conditions.

Debugging Data

I can provide a list of > 800 call-ids observed that all routed to the same endpoint. These are pulled from real world calls, and while there's not much danger in just having call-id's I would still prefer not to post it into github for posterity.

Log Messages

Log messages end up looking similar to this. I validated that the number is the CRC32 hash of the call id, so it's not a bug in the module.

proxy-1  |  1(7) DEBUG: carrierroute [cr_func.c:449]: rewrite_on_rule(): searching for matching routing rules 1(7) DEBUG: carrierroute [prime_hash.c:66]: hash_func(): hash: 2417021133 % 1000 = 133
proxy-1  |  1(7) INFO: carrierroute [cr_func.c:689]: ki_cr_do_route_helper(): uri service was rewritten to sip:service@host-d, carrier 1, domain 1

Possible Solutions

Ability to use MD5, kamailio's core hash function or other such hashing function

Additional Information

Problem validate in 5.7.3, but since it's correct by module design, it shouldn't have changed in 5.8

[henningw]

The hashing algorithm could be changed, sure. There are some internal hashing algorithms available (e.g. MD5) in the Kamailio core, there is of course also the possibility to use OpenSSL, but we might not want to introduce this depencency for that module.

[whosgonna]

My guess is that md5 would be sufficient. It's still odd feeling that CRC32 wasn't getting sufficient randomization against the actual Call-Ids I was receiving. Anything requiring OpenSSL and actual cryptographic-quality algorithms seems overkill, though.

[github-actions]

This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.