### Description
We tried to load share 50+ media servers using dispatching algorithm 11 and faced an unexpected behavior when most calls go to very first host in the group.
### Troubleshooting
I tried to start Kamailio like this:
sudo kamailio -f /etc/kamailio/kamailio.cfg -E -d 5 -u 995
but errors were the same when dispatcher group had more than 25 and less than 25 hosts
It was tried different combinations of dispatcher list host group configuration:
100 sip:10.60.27.123:7000 10 rweight=50
100 sip:10.60.27.123:7000 10 weight=50;rweight=50
100 sip:10.60.27.123:7000 rweight=50,maxload=80
When making 100 calls the quarter of them go to the first host in the group.
#### Reproduction
modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_probing_threshold", 3)
modparam("dispatcher", "ds_inactive_threshold", 10)
modparam("dispatcher", "ds_probing_mode", 3)
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_ping_reply_codes", "501,403,404,400,200")
modparam("dispatcher", "ds_ping_from",DS_PING_FROM_PARAM)
modparam("dispatcher", "use_default", 0)
if ( ds_is_from_list("101")) {
sl_send_reply("100","My calls");
ds_select_dst("100", "11");
return;
}
Dispatcher group must have more than 25 hosts, if equal or less than 25 than it is Ok:
100 sip:10.60.27.123:7000 0 10 rweight=50
100 sip:10.60.27.123:7001 0 10 rweight=50
100 sip:10.60.27.123:7002 0 10 rweight=50
100 sip:10.60.27.123:7003 0 10 rweight=50
100 sip:10.60.27.123:7004 0 10 rweight=50
100 sip:10.60.27.123:7005 0 10 rweight=50
100 sip:10.60.27.123:7006 0 10 rweight=50
100 sip:10.60.27.123:7007 0 10 rweight=50
100 sip:10.60.27.123:7008 0 10 rweight=50
100 sip:10.60.27.123:7009 0 10 rweight=50
100 sip:10.60.27.123:7010 0 10 rweight=50
100 sip:10.60.27.123:7011 0 10 rweight=50
100 sip:10.60.27.123:7012 0 10 rweight=50
100 sip:10.60.27.123:7013 0 10 rweight=50
100 sip:10.60.27.123:7014 0 10 rweight=50
100 sip:10.60.27.123:7015 0 10 rweight=50
100 sip:10.60.27.123:7016 0 10 rweight=50
100 sip:10.60.27.123:7017 0 10 rweight=50
100 sip:10.60.27.123:7018 0 10 rweight=50
100 sip:10.60.27.123:7019 0 10 rweight=50
100 sip:10.60.27.123:7020 0 10 rweight=50
100 sip:10.60.27.123:7021 0 10 rweight=50
100 sip:10.60.27.123:7022 0 10 rweight=50
100 sip:10.60.27.123:7023 0 10 rweight=50
100 sip:10.60.27.123:7024 0 10 rweight=50
To emulate call load and multiple media servers, SIPp scenarios were used.
#### Debugging Data
#### Log Messages
#### SIP Traffic
No specific traffic, regular INVITE messages having international numbers.
### Possible Solutions
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
kamailio -v
version: kamailio 5.4.4 (x86_64/linux) e16352
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: e16352
compiled on 15:56:46 Feb 15 2021 with gcc 4.8.5
```
* **Operating System**:
```
CentOS Linux release 7.7.1908 (Core)
Linux test-carrier-1.prd.tc5.ams.nl.kwebbl.loc 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18 17:15:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2698
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- 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 -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] 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)
- [x] 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
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
Hi Maintainers,
I have worked a bit on setting fuzzing up for Kamailio by way of OSS-Fuzz. Essentially, OSS-Fuzz is a free service run by Google that performs continuous fuzzing of important open source projects, and it would be great to have Kamailio integrated. The only expectation of integrating into OSS-Fuzz is that bugs will be fixed. This is not a "hard" requirement in that no one enforces this and the main point is if bugs are not fixed then it is a waste of resources to run the fuzzers, which we would like to avoid.
In this PR https://github.com/google/oss-fuzz/pull/5279 I have done exactly that, namely created the necessary logic from an OSS-Fuzz perspective to integrate Kamailio. If you would like to integrate, could you please provide a set of email(s) that will get access to the data produced by OSS-Fuzz, such as bug reports, coverage reports and more stats. The emails should be linked to a Google account in order to view the detailed reports and notice the emails affiliated with the project will be public in the OSS-Fuzz repo, as they will be part of a configuration file.
At the moment I stored the fuzzers in the Google OSS-Fuzz repository, but we can move them up here to make maintenance easier.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2660
-- Commit Summary --
* Adds initial fuzzer for integration with oss-fuzz.
-- File Changes --
A fuzz/fuzz_uri.c (8)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2660.patchhttps://github.com/kamailio/kamailio/pull/2660.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2660
### Description
Carrierroute module takes now 16 minutes to load about 50'000 entries from postgres-db.
In version 5.0.3 it was 10 seconds from the same db.
### Troubleshooting
#### Reproduction
Install kamailio 5.0.3 and fill your carrierroute table with thousands of entries. See how fast its loaded.
Then install 5.0.4 and see how long it takes now.
You can observe the query "SELECT * FROM carrierroute WHERE carrier=1 and domain=1 and prob>0" multiple times in the postgres-db log.
#### Debugging Data
none.
#### Log Messages
not needed.
#### SIP Traffic
not needed.
### Possible Solutions
Perhaps try to do the check "in-memory" instead generate a new sql-query.
### Additional Information
This bug exists in Kamilio versions >=5.0.4 and is (potentially) introduced by:
commit 9800aba65146b72623bb512049300d1beb8c8ec4
Author: Huseyin Dikme <hueseyin.dikme(a)1und1.de>
Date: Tue Sep 12 15:37:17 2017 +0200
carrierroute: warning for the same carrier/domain having routes with only 0 probability
- While starting kamailio or reloading the routes, if the same carrier/domain pairs do not have
any route with a probability other than 0 (zero) then an error log will be printed on the screen.
Besides, the log "invalid dice_max value" in the cr_func.c has been made more clear.
(cherry picked from commit 9741bee7af8136b35af8e6279e530aa0ad54f574)
* **Operating System**:
Ubuntu 20.04.2 LTS
Linux 5.4.0-66-generic #74-Ubuntu SMP Wed Jan 27 22:54:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2653
### Description
Could you extend `import_file` directive to support wildcards like
```
import_file "/run/kamailio/cfg/*"
```
This will allow place runtime config files with public IP of VM. Useful for cloud installation.
```
listen=udp:eth0 advertise 52.24.72.57:5060
listen=tcp:eth0 advertise 52.24.72.57:5060
```
### Expected behavior
All files matched to wildcard included into config
#### Actual observed behavior
wildcard ignored
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2125