### 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