### 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
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3786
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3786(a)github.com>
Added enable_register_publish parameter to enable REGISTER and PUBLISH method for topos
If set to 1 REGISTER and PUBLISH will be enabled for topos Currently only via header will be applied for topos and if mask_callid is set to 1 call-ID will be masked. Other headers should be manged by the user as required.
<!-- 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, ...)
- [ ] 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 #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3766
-- Commit Summary --
* add enable_register_publish
-- File Changes --
M src/modules/topos/topos_mod.c (2)
M src/modules/topos/tps_msg.c (132)
M src/modules/topos/tps_msg.h (2)
M src/modules/topos/tps_storage.c (6)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3766.patchhttps://github.com/kamailio/kamailio/pull/3766.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3766
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3766(a)github.com>
### Description
After installing kamailio on Ubuntu (20.04 and 22.04) using normal kamailio.org instructions, things work fine. However, a developer is working on a large project as root, and occasionally restarts kamailio with the command "kamctl <start|stop|restart>", rather than the OS command "systemctl <stop|start|restart> kamailio". After that, any attempt to restart or check status using systmectl fails, and rebooting the server occasionally fails to restart kamailio.
### Troubleshooting
#### Reproduction
Install ubuntu 22.04 or 20.04. When up and running, try this:
`systemctl status kamailio` (everything looks good)
`ps -C kamailio -o comm,uid,euid,pid,ppid` (all happy, Kamailio running as user kamailio)
`kamctl restart`
`ps -C kamailio -o comm,uid,euid,pid,ppid` (Yes it's running, but as root, not kamailio)
`systemctl status kamailio` (FAILS, 20.04 reports "Failed to start", 22.04 reports "kamailio.service: Deactivated successfully")
`systemctl restart kamailio` (FAILS - same reports as preceding "status" command)
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
After command systemctl restart kamailio:
```
Feb 9 18:30:02 usdc2-lab-drproxy02 kamailio: INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module
Feb 9 18:30:02 usdc2-lab-drproxy02 kamailio: INFO: <core> [core/tcp_main.c:5042]: init_tcp(): using epoll_lt as the io watch method (auto detected)
Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded
Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: rr [rr_mod.c:177]: mod_init(): outbound module not available
Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: auth [auth_mod.c:345]: mod_init(): qop set, but nonce-count (nc_enabled) support disabled
Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [main.c:2779]: main(): processes (at least): 32 - shm size: 67108864 - pkg size: 8388608
Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992
Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984
Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992
Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984
Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: ERROR: <core> [core/tcp_main.c:3162]: tcp_init(): bind(c, 0x7f49b0475c74, 16) on 127.0.0.1:5060 : Address already in use
Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
Modify kamctl et. al. to call systemctl for start, stop, restart commands. Alternatively have kamctl call setuid() before start, restart, stop commands.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
On ubuntu 20.04:
```
version: kamailio 5.3.2 (x86_64/linux)
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, TLS_PTHREAD_MUTEX_SHARED
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: unknown
compiled with gcc 9.2.1
```
For ubuntu 22.04:
```
version: kamailio 5.6.5 (x86_64/linux)
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_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
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: unknown
compiled with gcc 11.4.0
```
* **Operating System**:
For ubuntu 22.04:
```
root@my_22.04_ubuntu:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy
root@my_22.04_ubuntu:~# uname -a
Linux my_22.04_ubuntu 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
root@my_22.04_ubuntu:~#
```
For ubuntu 20.04
```
root@my_20.04_ubuntu:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
root@my_20.04_ubuntu:~# uname -a
Linux my_20.04_ubuntu 5.4.0-171-generic #189-Ubuntu SMP Fri Jan 5 14:23:02 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
root@my_20.04_ubuntu:~#
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3752
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3752(a)github.com>
Situation: Two Kamailio nodes syncing dialog profiles via DMQ
Observation: When a dialog timeout is encountered, about half of the time, the timeout is triggered on the peer node not handling the dialog preventing the call to be correctly terminated and also leaving entries in the dialog database which never get deleted.
https://kamailio.org/docs/modules/5.7.x/modules/dialog.html#dialog.p.enable…
Makes clear, that only the node which is handling the dialog in question, can make changes not related to the dialog profiles. So when a dialog times out, it is this node which has to trigger the timeout, not any other one.
When looking at the source code, it is clear, that the 'lifetime' is transmitted via DMQ dialog message to the peer nodes, which in turn arm a timer. So it is obvious, this time will trigger, sometimes before the instance handling the dialog itself triggers that timer.
With some assistance of @oej I found a way to alter the JSON payload to extend the lifetime on the peer nodes:
```
route[DMQ_CAPTURE]
{
if(is_method("KDMQ"))
{
if(has_body("application/json") && $fU == 'dialog')
{
if (jansson_get("lifetime", $rb, "$var(lifetime)"))
{
$var(new_lifetime) = $var(lifetime) + 60; # Add 60 seconds on DMQ peer to make sure it expires AFTER main node.
$var(newrb) = $rb;
jansson_set("integer", "lifetime", $var(new_lifetime), "$var(newrb)");
set_body("$var(newrb)","application/json");
msg_apply_changes();
}
}
dmq_handle_message();
exit;
}
}
```
Testing with this config fixed the issue of the timeout firing on a peer node instead of the node handling the dialog.
Issue is present in 5.5, 5.6 and after looking at the code, I assume also on 5.7
-Benoît
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3656
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3656(a)github.com>
### Description
Kamailio segfaults when KEMI functions are invoked from app_python script
### Troubleshooting
The same code was running ok with the 5.6 branch.
It seems that the function sr_apy_kemi_exec_func_ex has been re-written in 5.7 with the following main changes :
- The long IF/ELSE statement was replace by a FOR loop
- The call to PyArg_ParseTuple function was replaced by the call to PyList_GetItem ==> **This seems to be the cause. The value returned by this function is alway NULL**
#### Reproduction
Any call to KSR.pv.seti function from a PYTHON 2 script would cause this error.
#### Log Messages
```
sbin/kamailio[18449]: ERROR: app_python [apy_kemi.c:280]: sr_apy_kemi_exec_func_ex(): null parameter - func: seti idx: 0 argc:
2
Feb 6 11:34:16 .../sbin/kamailio[18509]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 37
Feb 6 11:34:16 .../sbin/kamailio[18380]: ALERT: <core> [main.c:793]: handle_sigs(): child process 18449 exited by a signal 11
Feb 6 11:34:16 .../sbin/kamailio[18380]: ALERT: <core> [main.c:796]: handle_sigs(): core was not generated
Feb 6 11:34:16 .../sbin/kamailio[18380]: INFO: <core> [main.c:818]: handle_sigs(): terminating due to SIGCHLD
Feb 6 11:34:16 .../sbin/kamailio[18509]: INFO: <core> [main.c:874]: sig_usr(): signal 15 received
Feb 6 11:34:16 .../sbin/kamailio[18502]: INFO: <core> [main.c:874]: sig_usr(): signal 15 received
Feb 6 11:34:16 .../sbin/kamailio[18495]: INFO: <core> [main.c:874]: sig_usr(): signal 15 received
Feb 6 11:34:16 .../sbin/kamailio[18482]: INFO: <core> [main.c:874]: sig_usr(): signal 15 received
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3746
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3746(a)github.com>
### Description
All kamailio versions on the 5.7.x train and additionally point release 5.6.5 break early dialog transactions, at least when the following conditions are (cumulatively) met:
* topos-redis is enabled (haven't tested other storage backends yet, let me know if needed)
* kamailio is multihomed
* enable_double_rr is enabled (the default)
### Troubleshooting
#### SIP Traffic
Here's an exchange demonstrating the problem:
```
kamailio instance
──────────┬──────────────────┬─────────
internal external peer
172.30.154.1:5060 185.73.43.241:5060 195.167.21.66:5060
──────────┬──────────────────┬───────── ──────────┬─────────
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ INVITE (SDP) │
│ │ ──────────────────────────> │
│ │ 100 Trying │
│ │ <────────────────────────── │
│ │ 183 Session Progress (SDP) │
│ │ <────────────────────────── │
│ │ PRACK │
│ │ ──────────────────────────> │
│ │ 200 OK │
│ │ <────────────────────────── │
│ │ UPDATE (SDP) │
UPDATE (SDP) │ │
<─────────────────────────── │ │
```
Whereas the expected behaviour should be:
```
│ │ UPDATE (SDP) │
| <────────────────────────── │
UPDATE (SDP)│ │ │
<───────── │ │ │
```
This is also exemplified by examining the Via headers as rewritten by kamailio.
Not working (>= 5.6.5, 5.7.x):
* Inbound Via: `Via: SIP/2.0/UDP 195.167.21.66:5060;branch=z9hG4bKtjlwcpvfh03epe0thhtjhq3qg;Role=3;Hpt=8e58_16`
* Oubound Via: `Via: SIP/2.0/UDP 185.73.43.241;branch=z9hG4bK66c4.3453dd9a219858819d528b9da671e39e.0`
Working (5.6.4):
* Inbound Via: `Via: SIP/2.0/UDP 195.167.21.66:5060;branch=z9hG4bK8lj1ahz6npz65khd8jkzl1ohh;Role=3;Hpt=8e68_16`
* Oubound Via: `Via: SIP/2.0/UDP 172.30.154.1;branch=z9hG4bK4dce.4f5448efd64465fa5dbaf5eef0dc35b7.0`
### Possible Solutions
Only solution I have found so far is to downgrade to kamailio 5.6.4
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
```
version: kamailio 5.7.4 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, 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_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
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: unknown
compiled with gcc 10.2.1
```
But I have also tested all 5.7.x versions, which are all affected, as well 5.6.5.
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
Linux host 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3757
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3757(a)github.com>
#### 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:
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
This patch introduces a new "time" field for JSON logging to stderr. The CEE format already includes this field, but the Kamailio-specific format doesn't. If you need timestamps in your structured logs, but don't want to use the CEE format due to its limitations, this patch'd give you the best of both worlds.
I know this comes a little out of the blue, so any feedback is welcome.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3795
-- Commit Summary --
* core: dprint - include time in stderr json log
-- File Changes --
M src/core/dprint.c (44)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3795.patchhttps://github.com/kamailio/kamailio/pull/3795.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3795
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3795(a)github.com>
#### 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:
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
Enhance xhttp_prom module to export pkgmem stats.
The new stats can be enabled via a new module parameter: `xhttp_prom_pkgmem_stats_enabled`.
Default value for the new module parameter: 0 (no pkg mem stats are generated).
Any value different then 0 will export the pkg mem statistics.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3793
-- Commit Summary --
* kex: expose access to pkg mem stats
* xhttp_prom: export pkg mem stats
-- File Changes --
A src/modules/kex/api.c (54)
A src/modules/kex/api.h (69)
M src/modules/kex/kex_mod.c (2)
M src/modules/kex/pkg_stats.c (24)
M src/modules/kex/pkg_stats.h (17)
M src/modules/xhttp_prom/prom.c (66)
M src/modules/xhttp_prom/xhttp_prom.c (44)
M src/modules/xhttp_prom/xhttp_prom.h (16)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3793.patchhttps://github.com/kamailio/kamailio/pull/3793.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3793
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3793(a)github.com>
Hello,
with many countries having public holidays around Catholic Easter, I am
considering to release Kamailio v5.8.1 (out of branch 5.8) on Wednesday,
April 3, 2024. If anyone is aware of issues not yet on the bug tracker,
report them there asap in order to have a better chance to be fixed.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com