[sr-dev] [kamailio/kamailio] Extend rtpengine hashing algorithms (#1986)

Ionut Ionita notifications at github.com
Wed Jun 19 10:43:40 CEST 2019

<!-- Kamailio Pull Request Template -->

  - for detailed contributing guidelines, read:
  - pull requests must be done to master branch, unless they are backports
    of fixes from master branch to a stable branch
  - backports to stable branches must be done with 'git cherry-pick -x ...'
  - code is contributed under BSD for core and main components (tm, sl, auth, tls)
  - code is contributed GPLv2 or a compatible license for the other components
  - GPL code is contributed with OpenSSL licensing exception

#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [ ] Commit message has the format required by CONTRIBUTING guide
- [ ] Commits are split per component (core, individual modules, libs, utils, ...)
- [ ] Each component has a single commit (if not, squash them into one commit)
- [ ] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)

#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)

#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [ ] Tested changes locally
- [ ] Related to issue #1911 

#### Description
<!-- Describe your changes in detail -->

The goal was to have a different, more complex hashing algorithm that would offer a better distribution among nodes. We've seen in production that the current algorithm does not perform well under heavy load therefore we decided to add SHA1 hashing. After running performance tests we've decided that we need a cryptographic function in order to have the best results mostly when the callids have small entropy. 
In order to add SHA1, a new API was added in crypto module exporting a function applying SHA1 to a string. The API was used in rtpengine module over the callid. After this operation the hash was calculated as before except for applying 0xFF mask over the hash as it was done before, which restrains the power of this algorithm.
You can view, comment on, or merge this pull request online at:


-- Commit Summary --

  * crypto: add exportable API and expose SHA1 hashing function
  * rtpengine: use SHA1 over callid for better distribution among nodes
  * rtpengine: add modparam to switch between legacy hashing algorithm and SHA1
  * rtpengine: update README

-- File Changes --

    A src/modules/crypto/api.c (30)
    A src/modules/crypto/api.h (63)
    M src/modules/crypto/crypto_mod.c (2)
    M src/modules/crypto/crypto_uuid.c (34)
    M src/modules/crypto/crypto_uuid.h (8)
    M src/modules/rtpengine/doc/rtpengine_admin.xml (25)
    M src/modules/rtpengine/rtpengine.c (53)
    M src/modules/rtpengine/rtpengine.h (1)

-- Patch Links --


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20190619/b13f2aa1/attachment-0001.html>

More information about the sr-dev mailing list