#### Pre-Submission Checklist
- [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
- [x] 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:
- [x] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
I have refactored the rpm packaging and am now using the GitHub actions.
Now `tar.gz` archive with rpm packages, source rpm and deps rpm files attached to the release message like.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4194
-- Commit Summary --
* generate rpm packages using github actions
-- File Changes --
A .github/workflows/rpm.yml (57)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4194.patchhttps://github.com/kamailio/kamailio/pull/4194.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4194
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4194(a)github.com>
- fixed log message in MAR Async CDP callback
- fixed executing cfg_action after sending MAR Diameter request
- cfg_action is the callback parameter of the ims_www_challenge function
<!-- 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)
- [ ] 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 #4205 (replace XXXX with an open issue number)
#### Description
Based on the description in issue #4205, this PR will fix a bug in ims_auth module related to MAR Diameter request callbacks, by replacing the call to t_continue function with t_continue_skip_timer, after the MAR request is sent, the control will successfully move to the cfg action in Kamailio scripts. Just like what we already have in ims_registrar_scscf module, using t_continue_skip_timer instead of t_continue cause the transaction to be found and resumed.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4206
-- Commit Summary --
* ims_auth: replaced t_continue_skip_timer with t_continue in cxdx_mar.c
-- File Changes --
M src/modules/ims_auth/cxdx_mar.c (6)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4206.patchhttps://github.com/kamailio/kamailio/pull/4206.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4206
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4206(a)github.com>
nochnoi82 created an issue (kamailio/kamailio#4243)
Greetings folks.
Need your help or conclusion.
Debian 12
Kamailio 6.0.1 (Open source installed)
Init script and systemd script were applied.
kamctl start (/usr/local/sbin)
ERROR: PID file /var/run/kamailio.pid does not exist -- Kamailio start failed
kamailio start (/usr/local/sbin)
error: 'start' is not a supported argument
error: stopping kamailio ...
sudo journalctl -xeu kamailio
ERROR: db_mysql [km_my_con.c:219]: db_mysql_new_connection(): driver error: Access denied for user 'kamailio'@'localhost' (using password: YES)
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: <core> [lib/srdb1/db.c:326]: db_do_init2(): could not add connection to the pool
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: usrloc [dlist.c:848]: register_udomain(): failed to open database connection
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: registrar [registrar.c:773]: domain_fixup(): failed to register domain
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: <core> [core/route.c:1195]: fix_actions(): fixing failed (code=-1) at cfg:/usr/local/etc/kamailio/kamailio.cfg:750
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: <core> [core/rvalue.c:3816]: fix_rval_expr(): failure in cfg at line: 750 col: 22
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: <core> [core/rvalue.c:3816]: fix_rval_expr(): failure in cfg at line: 750 col: 22
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: <core> [core/route.c:1195]: fix_actions(): fixing failed (code=-1) at cfg:/usr/local/etc/kamailio/kamailio.cfg:753
Kamailio acts as proxy server only.
What did i miss?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4243
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4243(a)github.com>
Pandi1981 created an issue (kamailio/kamailio#4208)
We are facing an issue while using TOPOS in Kamailio P-CSCF (running under Docker).
Kamailio version: 6.0.0
operating system: "10 (buster)"
**Call Flow & Issue Description:**
Note: Public IP and Private IP mapping using the below configuration.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
listen=udp:LOCAL_IP:5060 name "internal"
listen=udp:LOCAL_IP:6080 advertise PUBLIC_IP:6080 name "external"
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
**Call Flow (INVITE):**
A-Party --> Kamailio P-CSCF (Public IP) --> Kamailio P-CSCF (Private IP) --> Kamailio S-CSCF (Private IP)
B-Party <-- Kamailio P-CSCF (Public IP) <-- Kamailio P-CSCF (Private IP) <-- Kamailio S-CSCF (Private IP)
Everything works correctly up to the point where the 200 OK is received by the A-Party. However, when the A-Party sends the ACK, it is received by the Kamailio P-CSCF but is not forwarded to the B-Party.
Upon investigation, we found that when Kamailio receives the ACK from the A-Party, the rr (Record-Route) module fails to recognize its own Route header and thus falls back to strict routing instead of performing loose routing. This results in an incorrect rewrite of the Request-URI of the ACK, causing it to fail to reach the B-Party. Essentially, the Route header is not popped as expected and the ACK routing breaks.
TOPOS module is configured as follows:
loadmodule "topos_redis.so"
loadmodule "ndb_redis.so"
loadmodule "topos.so"
modparam("ndb_redis", "server", "name=tps;addr=127.0.0.1;port=6379;db=0")
modparam("topos", "storage", "redis")
modparam("topos_redis", "serverid", "tps")
modparam("topos", "rr_update", 1)
modparam("topos", "contact_mode", 1)
modparam("topos", "xavu_field_a_contact", "a_contact")
modparam("topos", "xavu_field_b_contact", "b_contact")
modparam("topos", "xavu_cfg", "tps")
Please guide us how to achieve and what we are doing wrong.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4208
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4208(a)github.com>
sergey-safarov created an issue (kamailio/kamailio#4180)
### Description
I have installed two `rtpengine` instances and want to use them as an `active backup`. I want to use `backup` only when `active` is unavailable.
Closest settings for this rtpengine node `weight` and want to use settings like
```
MariaDB [kamailio]> select * from rtpengine;
+----+-------+---------------------------------+--------+----------+---------------------+
| id | setid | url | weight | disabled | stamp |
+----+-------+---------------------------------+--------+----------+---------------------+
| 1 | 0 | udp6:[2005:84c0:bf:11::20]:2223 | 1 | 0 | 1900-01-01 00:00:01 |
| 2 | 0 | udp6:[2005:84c0:bf:11::21]:2223 | 0 | 0 | 1900-01-01 00:00:01 |
+----+-------+---------------------------------+--------+----------+---------------------+
```
But in case `weight=0` node is not selected and handled as disabled.
It will be fine do not use rtpengine nodes with `weight=0` when other rtpengine with `weight!=0` are available. But if no other nodes are available, use `weight=0` nodes as last resort.
### Expected behavior
Do not use rtpengine nodes with `weight=0` when other rtpengine with `weight!=0` are available. But if no other nodes are available, use `weight=0` nodes as last resort.
#### Actual observed behavior
The node is not selected and handled as disabled when `weight=0`.
#### Log Messages
```
rtpengine [rtpengine.c:3430]: rtpp_test(): rtpengine instance <udp6:[2005:84c0:bf:11::21]:2223> found, support for it enabled
rtpengine [rtpengine.c:3883]: select_rtpp_node(): rtpengine failed to select new for calllen=27 callid=1-10824@2005:84c0:bf:11::22
rtpengine [rtpengine.c:3183]: rtpp_function_call(): no available proxies
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4180
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4180(a)github.com>
ChristianBergerSipgate created an issue (kamailio/kamailio#4167)
Hi,
we have found a potential bug. The pseudo variables return null for WSS connections.
Example config:
`xlog("L_INFO", "<mainLogic> REGISTER: TLS or WSS detected: fU=$fU tls_version=$tls_version tls_cipher_info=$tls_cipher_info ua=$ua\n");`
Log output:
`Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "ERROR", "module": "tls", "file": "tls_select.c", "line": 131, "function": "get_cur_connection", "message": "Transport protocol is not TLS (bug in config)\n" }
Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "INFO", "module": "tls", "file": "tls_select.c", "line": 310, "function": "get_version", "message": "TLS connection not found in select_version\n" }
Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "ERROR", "module": "tls", "file": "tls_select.c", "line": 131, "function": "get_cur_connection", "message": "Transport protocol is not TLS (bug in config)\n" }
Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "INFO", "module": "tls", "file": "tls_select.c", "line": 201, "function": "get_cipher", "message": "TLS connection not found in select_cipher\n" }
Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "INFO", "module": "xlog", "file": "xlog.c", "line": 278, "function": "", "message": "<mainLogic> REGISTER: TLS or WSS detected: fU=1125411e0 tls_version=<null> tls_cipher_info=<null> ua=webphone\n" }`
As you can see both tls_version and tls_cipher_info return <null> even though the underlying connection is via WSS.
We have looked into it, and it seems like `get_cur_connection` in `modules/tls/tls_select.c` only checks for TLS, but not WSS.
```
struct tcp_connection *get_cur_connection(struct sip_msg *msg)
{
struct tcp_connection *c;
if(_tls_pv_con != 0)
return _tls_pv_con;
if(msg->rcv.proto != PROTO_TLS) {
ERR("Transport protocol is not TLS (bug in config)\n");
return 0;
}
c = tcpconn_get(msg->rcv.proto_reserved1, 0, 0, 0,
cfg_get(tls, tls_cfg, con_lifetime));
if(c && c->type != PROTO_TLS) {
ERR("Connection found but is not TLS\n");
tcpconn_put(c);
return 0;
}
return c;
}
```
We think that checking for `PROTO_WSS` might solve the issue.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4167
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4167(a)github.com>
Hello,
If somebody is using Kamailio in a larger environment with TLS, this new technical analysis and performance report from haproxy could be interesting: https://www.haproxy.com/blog/state-of-ssl-stacks
The bottom-line - OpenSSL 3.0 will show serious performance regressions for larger TLS services with higher performance requirements. OpenSSL 3.1 and newer versions are a bit better, but still much slower in key operations. You should consider using the tls_wolfssl module or stay on OpenSSL 1.1.1. For the medium- to long-term we probably should observe how other OpenSSL libraries are developing and act accordingly for the tls modules.
The haproxy project recommends besides using wolfssl also the aws-lc library. The situation regarding OpenSSL 3.x seems to be not easily fixable, as these regressions are caused from internal design decisions.
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com<https://gilawa.com/>
Module: kamailio
Branch: master
Commit: 57316690e96f8c458e9f83af7e102bfa816bf2cf
URL: https://github.com/kamailio/kamailio/commit/57316690e96f8c458e9f83af7e102bf…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2025-05-11T15:57:50+02:00
pv: docs for the new xavp/i rm all functions
---
Modified: src/modules/pv/doc/pv_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/57316690e96f8c458e9f83af7e102bf…
Patch: https://github.com/kamailio/kamailio/commit/57316690e96f8c458e9f83af7e102bf…
---
diff --git a/src/modules/pv/doc/pv_admin.xml b/src/modules/pv/doc/pv_admin.xml
index 6a06bb717de..0d962a81ca5 100644
--- a/src/modules/pv/doc/pv_admin.xml
+++ b/src/modules/pv/doc/pv_admin.xml
@@ -726,6 +726,29 @@ xavi_child_sets("WhatEver", "FoO", "Count: $var(n)");
...
xavp_rm("x");
# same result as: $xavp(x) = $null;
+...
+ </programlisting>
+ </example>
+ </section>
+ <section id="pv.f.xavp_rm_all">
+ <title>
+ <function moreinfo="none">xavp_rm_all(rname)</function>
+ </title>
+ <para>
+ Remove all the values of $xavp(rname).
+ </para>
+ <para>
+ The parameter has to be the name of XAVP in the root list.
+ It can be static or dynamic string (to include variables).
+ </para>
+ <para>
+ Function can be used from ANY ROUTE.
+ </para>
+ <example>
+ <title><function>xavp_rm_all</function> usage</title>
+ <programlisting format="linespecific">
+...
+xavp_rm_all("x");
...
</programlisting>
</example>
@@ -750,6 +773,29 @@ xavp_rm("x");
...
xavi_rm("WhatEver");
# same result as: $xavi(whatever) = $null;
+...
+ </programlisting>
+ </example>
+ </section>
+ <section id="pv.f.xavi_rm_all">
+ <title>
+ <function moreinfo="none">xavi_rm_all(rname)</function>
+ </title>
+ <para>
+ Remove all the values of $xavi(rname).
+ </para>
+ <para>
+ The parameter has to be the name of XAVI in the root list.
+ It can be static or dynamic string (to include variables).
+ </para>
+ <para>
+ Function can be used from ANY ROUTE.
+ </para>
+ <example>
+ <title><function>xavi_rm_all</function> usage</title>
+ <programlisting format="linespecific">
+...
+xavi_rm_all("WhatEver");
...
</programlisting>
</example>
Opening this generic issue to track issues when trying to switch deb package generation to cmake:
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4053
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4053(a)github.com>
<!-- 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 -->
- [*] 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 #4232
#### Description
not all versions of rtpengine sends a key SSRC per stream. For those that do not the same information can be found in ingress SSRCs. Add logic to check for the SSRC value there if the SSRC key is not present.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4233
-- Commit Summary --
* rtpengine: improve compatibility of rtpengine per call leg stats parsing
-- File Changes --
M src/modules/rtpengine/rtpengine.c (19)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4233.patchhttps://github.com/kamailio/kamailio/pull/4233.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4233
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4233(a)github.com>
tsearle created an issue (kamailio/kamailio#4232)
### Description
For getting A and B leg QoS stats, Kamailio expects there to be a SSRC key inside the Stream object.
However some versions of rtpengine (tested with mr13.3.1.1) do not send this key. Looking at the master version of rtpengine, I see this key has been added to correspond to ingress SSRCs[0].
This patch adds a checking ingress SSRCs[0] as a fallback if SSRC
### Troubleshooting
#### Reproduction
use kamailio 6.0.1 and rtpengine mr13.3.1.1 using baresip as the calling and called party
the following in the kamailio.cfg
```
modparam("rtpengine", "mos_A_label_pv", "$avp(mos_A_label)")
#The name of a pseudovariable to hold the minimum encountered MOS value for the call. The value typically has a range of 1.0 through 5.0.
modparam("rtpengine", "mos_min_A_pv", "$avp(mos_min_mos_A)")
#The name of a pseudovariable to hold the amount of packetloss in percent at the time the minimum MOS value was encountered;
modparam("rtpengine", "mos_min_packetloss_A_pv", "$avp(mos_min_packetloss_A)")
#The name of a pseudovariable to hold the amount of jitter in milliseconds at the time the minimum MOS value was encountered;
modparam("rtpengine", "mos_min_jitter_A_pv", "$avp(mos_min_jitter_A)")
#The name of a pseudovariable to hold the packet round-trip time in microseconds at the time the minimum MOS value was encountered;
modparam("rtpengine", "mos_min_roundtrip_A_pv", "$avp(mos_min_roundtrip_A)")
#The name of a pseudovariable to hold the maximum encountered MOS value for the call. The value typically has a range of 1.0 through 5.0.
modparam("rtpengine", "mos_max_A_pv", "$avp(mos_max_mos_A)")
#The name of a pseudovariable to hold the amount of packetloss in percent at the time the maximum MOS value was encountered;
modparam("rtpengine", "mos_max_packetloss_A_pv", "$avp(mos_max_packetloss_A)")
#The name of a pseudovariable to hold the amount of jitter in milliseconds at the time the maximum MOS value was encountered;
modparam("rtpengine", "mos_max_jitter_A_pv", "$avp(mos_max_jitter_A)")
#The name of a pseudovariable to hold the packet round-trip time in microseconds at the time the maximum MOS value was encountered;
modparam("rtpengine", "mos_max_roundtrip_A_pv", "$avp(mos_max_roundtrip_A)")
#The name of a pseudovariable to hold the average (median) MOS value for the call. The value typically has a range of 1.0 through 5.0.
modparam("rtpengine", "mos_average_A_pv", "$avp(mos_average_mos_A)")
#The name of a pseudovariable to hold the average (median) amount of packetloss in percent present throughout the call.
modparam("rtpengine", "mos_average_packetloss_A_pv", "$avp(mos_average_packetloss_A)")
#The name of a pseudovariable to hold the average (median) amount of jitter in milliseconds present throughout the call.
modparam("rtpengine", "mos_average_jitter_A_pv", "$avp(mos_average_jitter_A)")
#The name of a pseudovariable to hold the average (median) packet round-trip time in microseconds present throughout the call.
modparam("rtpengine", "mos_average_roundtrip_A_pv", "$avp(mos_average_roundtrip_A)")
modparam("rtpengine", "mos_B_label_pv", "$avp(mos_B_label)")
#The name of a pseudovariable to hold the minimum encountered MOS value for the call. The value typically has a range of 1.0 through 5.0.
modparam("rtpengine", "mos_min_B_pv", "$avp(mos_min_mos_B)")
#The name of a pseudovariable to hold the amount of packetloss in percent at the time the minimum MOS value was encountered;
modparam("rtpengine", "mos_min_packetloss_B_pv", "$avp(mos_min_packetloss_B)")
#The name of a pseudovariable to hold the amount of jitter in milliseconds at the time the minimum MOS value was encountered;
modparam("rtpengine", "mos_min_jitter_B_pv", "$avp(mos_min_jitter_B)")
#The name of a pseudovariable to hold the packet round-trip time in microseconds at the time the minimum MOS value was encountered;
modparam("rtpengine", "mos_min_roundtrip_B_pv", "$avp(mos_min_roundtrip_B)")
#The name of a pseudovariable to hold the maximum encountered MOS value for the call. The value typically has a range of 1.0 through 5.0.
modparam("rtpengine", "mos_max_B_pv", "$avp(mos_max_mos_B)")
#The name of a pseudovariable to hold the amount of packetloss in percent at the time the maximum MOS value was encountered;
modparam("rtpengine", "mos_max_packetloss_B_pv", "$avp(mos_max_packetloss_B)")
#The name of a pseudovariable to hold the amount of jitter in milliseconds at the time the maximum MOS value was encountered;
modparam("rtpengine", "mos_max_jitter_B_pv", "$avp(mos_max_jitter_B)")
#The name of a pseudovariable to hold the packet round-trip time in microseconds at the time the maximum MOS value was encountered;
modparam("rtpengine", "mos_max_roundtrip_B_pv", "$avp(mos_max_roundtrip_B)")
#The name of a pseudovariable to hold the average (median) MOS value for the call. The value typically has a range of 1.0 through 5.0.
modparam("rtpengine", "mos_average_B_pv", "$avp(mos_average_mos_B)")
#The name of a pseudovariable to hold the average (median) amount of packetloss in percent present throughout the call.
modparam("rtpengine", "mos_average_packetloss_B_pv", "$avp(mos_average_packetloss_B)")
#The name of a pseudovariable to hold the average (median) amount of jitter in milliseconds present throughout the call.
modparam("rtpengine", "mos_average_jitter_B_pv", "$avp(mos_average_jitter_B)")
#The name of a pseudovariable to hold the average (median) packet round-trip time in microseconds present throughout the call.
modparam("rtpengine", "mos_average_roundtrip_B_pv", "$avp(mos_average_roundtrip_B)")
```
#### 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.
-->
```
(paste your debugging data here)
```
#### Log Messages
```
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 3684, "function": "rtpp_function_call", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine hash table remove entry for callen=16 callid=3df537fef966eb1a viabranch=" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4508, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: looking for label 'Aleg_label'" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4514, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got tags" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4517, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got tag" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4522, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got label Aleg_label" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4525, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX label match" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4530, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got medias" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4532, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got media" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4537, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got streams" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4542, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got stream type 4" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4543, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX stream child 'local port'" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4546, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX stream child val type 2" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4517, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got tag" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4522, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got label Bleg_label" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4508, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: looking for label 'Bleg_label'" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4514, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got tags" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4517, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got tag" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4522, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got label Aleg_label" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4517, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got tag" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4522, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got label Bleg_label" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4525, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX label match" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4530, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got medias" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4532, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got media" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4537, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got streams" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4542, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX got stream type 4" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4543, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX stream child 'local port'" }
May 07 06:12:56 tst-ec1-blue-app-116 /usr/sbin/kamailio[3299]: { "level": "DEBUG", "module": "rtpengine", "file": "rtpengine.c", "line": 4546, "function": "parse_call_stats_1", "callid": "3df537fef966eb1a", "logprefix": "{BYE <null> 10.152.8.37 3df537fef966eb1a } ", "message": "rtpengine: XXX stream child val type 2" }
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4232
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4232(a)github.com>
Module: kamailio
Branch: master
Commit: 2e20c74fb03f2442cde5f3f69989a0ed914f542c
URL: https://github.com/kamailio/kamailio/commit/2e20c74fb03f2442cde5f3f69989a0e…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2025-05-06T14:38:02+02:00
app_jsdt: doc - fix section tags for loaddir
---
Modified: src/modules/app_jsdt/doc/app_jsdt_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/2e20c74fb03f2442cde5f3f69989a0e…
Patch: https://github.com/kamailio/kamailio/commit/2e20c74fb03f2442cde5f3f69989a0e…
---
diff --git a/src/modules/app_jsdt/doc/app_jsdt_admin.xml b/src/modules/app_jsdt/doc/app_jsdt_admin.xml
index 6d139c29428..bbf2148b9b4 100644
--- a/src/modules/app_jsdt/doc/app_jsdt_admin.xml
+++ b/src/modules/app_jsdt/doc/app_jsdt_admin.xml
@@ -107,35 +107,31 @@ modparam("app_jsdt", "load", "/usr/local/etc/kamailio/js/myscript.js")
</programlisting>
</example>
</section>
- <section>
- <title>Parameters</title>
- <section id="app_jsdt.p.loaddir">
- <title>
- <varname>loaddir</varname> (str)
- </title>
- <para>
- Set the path to the folder containing JavaScript files to be loaded at startup. All
- .js files in the folder will be loaded and combined into a single javascript script.
- Then you can use jsdt_run(function, params) to execute a function from the
- script at runtime. If you use it for KEMI configuration,
- then it has to include the required functions.
- </para>
- <para>
- <emphasis>
- Default value is <quote>null</quote>.
- </emphasis>
- </para>
- <example>
- <title>
- Set <varname>loaddir</varname> parameter
- </title>
- <programlisting format="linespecific">
- ...
- modparam("app_jsdt", "loaddir", "/usr/local/etc/kamailio/js")
- ...
- </programlisting>
- </example>
- </section>
+ <section id="app_jsdt.p.loaddir">
+ <title><varname>loaddir</varname> (str)</title>
+ <para>
+ Set the path to the folder containing JavaScript files to be loaded at startup. All
+ .js files in the folder will be loaded and combined into a single javascript script.
+ Then you can use jsdt_run(function, params) to execute a function from the
+ script at runtime. If you use it for KEMI configuration,
+ then it has to include the required functions.
+ </para>
+ <para>
+ <emphasis>
+ Default value is <quote>null</quote>.
+ </emphasis>
+ </para>
+ <example>
+ <title>
+ Set <varname>loaddir</varname> parameter
+ </title>
+ <programlisting format="linespecific">
+...
+modparam("app_jsdt", "loaddir", "/usr/local/etc/kamailio/js")
+...
+</programlisting>
+ </example>
+ </section>
<section id="app_jsdt.p.mode">
<title><varname>mode</varname> (int)</title>
<para>
@@ -328,4 +324,3 @@ request_route {
</programlisting>
</section>
</chapter>
-
<!-- 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
- [x] 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
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
We've been running the ims_charging module in production for quite some time, without any issues.
A couple of days ago the whole instance freezed, but I was able to get a dump before the stuck processes before restarting. The traffic volume has gradually increased over time, so it's likely related to that.
I then did a summary of the different types of stuck processes. Which locks they're holding, and what they're waiting for:
```
holding lock:
AAASessionsLock
waiting for lock:
lock_get(peer_list_lock);
#1 0x00007fe70eba8cde in futex_get (lock=0x7fe6e4a5c680) at ../../core/futexlock.h:108
#2 0x00007fe70ebaaca2 in get_peer_by_fqdn (fqdn=0x7fe6e4a5ba30) at peermanager.c:259
#3 0x00007fe70ebb64b7 in get_first_connected_route (cdp_session=0x7fe6e5cc5350, r=0x7fe6e4a5ba30, app_id=4, vendor_id=10415) at routing.c:115
#4 0x00007fe70ebb9a37 in get_routing_peer (cdp_session=0x7fe6e5cc5350, m=0x7fe6e5447ab0) at routing.c:293
#5 0x00007fe70ebcaf8c in AAASendMessage (message=0x7fe6e5447ab0, callback_f=0x7fe707a9e323 <resume_on_initial_ccr>, callback_param=0x7fe6e5297110) at diameter_comm.c:139
#6 0x00007fe707a9d3e0 in Ro_Send_CCR (msg=0x7fe70f011100, dlg=0x7fe6e5c571f0, dir=0, reservation_units=30, incoming_trunk_id=0x7ffe50efb060, outgoing_trunk_id=0x7ffe50efb050, pani=0x7ffe50efaee0, action=0x7fe70efa4730, tindex=10484, tlabel=677172593) at ims_ro.c:1511
#7 0x00007fe707a8285d in ki_ro_ccr (msg=0x7fe70f011100, s_route_name=0x7ffe50efb080, s_direction=0x7ffe50efb070, reservation_units=30, s_incoming_trunk_id=0x7ffe50efb060, s_outgoing_trunk_id=0x7ffe50efb050) at ims_charging_mod.c:742
#8 0x00007fe707a7bf01 in w_ro_ccr (msg=0x7fe70f011100, c_route_name=0x7fe70ef8b8d0 "\220\311\371\016\347\177", c_direction=0x7fe70ef8b980 "p\240\371\016\347\177", reservation_units=30, c_incoming_trunk_id=0x7fe70ef8ba30 "p\241\371\016\347\177", c_outgoing_trunk_id=0x7fe70ef8bae0 "\360\241\371\016\347\177") at ims_charging_mod.c:507
#9 0x00000000004858d8 in do_action (h=0x7ffe50efb970, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1144
#10 0x00000000004928d6 in run_actions (h=0x7ffe50efb970, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1618
#11 0x0000000000492f52 in run_actions_safe (h=0x7ffe50eff1e0, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1681
#12 0x0000000000450156 in rval_get_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, i=0x7ffe50efbec8, rv=0x7fe70ef9c1d8, cache=0x0) at core/rvalue.c:973
#13 0x0000000000454d24 in rval_expr_eval_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, res=0x7ffe50efbec8, rve=0x7fe70ef9c1d0) at core/rvalue.c:1854
#14 0x0000000000454d52 in rval_expr_eval_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, res=0x7ffe50efc448, rve=0x7fe70ef9b920) at core/rvalue.c:1864
#15 0x00000000004850ce in do_action (h=0x7ffe50eff1e0, a=0x7fe70ef9b070, msg=0x7fe70f011100) at core/action.c:1097
--
holding lock:
AAASessionsLock
waiting for lock:
lock_get(peer_list_lock);
#1 0x00007fe70eba8d4f in futex_get (lock=0x7fe6e4a5c680) at ../../core/futexlock.h:121
#2 0x00007fe70ebaaca2 in get_peer_by_fqdn (fqdn=0x7ffe50efab90) at peermanager.c:259
#3 0x00007fe70ebb8e89 in get_routing_peer (cdp_session=0x7fe6e5ab6910, m=0x7fe6e5435be0) at routing.c:252
#4 0x00007fe70ebcaf8c in AAASendMessage (message=0x7fe6e5435be0, callback_f=0x7fe707a95edc <resume_on_termination_ccr>, callback_param=0x0) at diameter_comm.c:139
#5 0x00007fe707a95b02 in send_ccr_stop_with_param (ro_session=0x7fe6e5ab65e0, code=0, reason=0x7ffe50efb060) at ims_ro.c:1181
#6 0x00007fe707a72ff7 in dlg_terminated (dlg=0x7fe6e623d7a0, type=64, termcode=0, reason=0x7fe707ab72b3 "normal call clearing", _params=0x7fe707f67280 <params>) at dialog.c:249
#7 0x00007fe707a6a729 in dlg_callback_received (dlg=0x7fe6e623d7a0, type=64, _params=0x7fe707f67280 <params>) at dialog.c:25
#8 0x00007fe707d341b9 in run_dlg_callbacks (type=64, dlg=0x7fe6e623d7a0, req=0x7fe70f011100, rpl=0x0, dir=1, dlg_data=0x0) at dlg_cb.c:271
#9 0x00007fe707cf4db4 in dlg_terminated (req=0x7fe70f011100, dlg=0x7fe6e623d7a0, dir=1) at dlg_handlers.c:413
#10 0x00007fe707cfddeb in dlg_onroute (req=0x7fe70f011100, route_params=0x7ffe50efb6d0, param=0x0) at dlg_handlers.c:1097
#11 0x00007fe70ad285f6 in run_rr_callbacks (req=0x7fe70f011100, rr_param=0x7ffe50efb7c0) at rr_cb.c:96
#12 0x00007fe70ad3ae92 in after_loose (_m=0x7fe70f011100, preloaded=0) at loose.c:1021
#13 0x00007fe70ad3b5ce in loose_route_mode (_m=0x7fe70f011100, _mode=0) at loose.c:1056
#14 0x00007fe70ad3f74f in w_loose_route (msg=0x7fe70f011100, p1=0x0, p2=0x0) at rr_mod.c:273
#15 0x00000000004855ff in do_action (h=0x7ffe50efc390, a=0x7fe70efe0d40, msg=0x7fe70f011100) at core/action.c:1121
--
holding lock:
lock_get(peer_list_lock);
waiting for lock:
lock_get(p->lock);
#1 0x00007fe70eba8d4f in futex_get (lock=0x7fe6e4a5cbd0) at ../../core/futexlock.h:121
#2 0x00007fe70ebab0ae in peer_timer (now=1742807320, ptr=0x0) at peermanager.c:286
#3 0x00007fe70ebd0f39 in timer_loop () at timer.c:116
#4 0x00007fe70ebd21b2 in timer_process (returns=0) at timer.c:216
#5 0x00007fe70eb8ccf8 in diameter_peer_start (blocking=0) at diameter_peer.c:350
#6 0x00007fe70eb7cbb2 in cdp_child_init (rank=0) at cdp_mod.c:272
--
holding lock:
lock_get(p->lock)
waiting for lock:
AAASessionsLock
#1 0x00007fe70ebf2597 in futex_get (lock=0x7fe6e4a5d490) at ../../core/futexlock.h:108
#2 0x00007fe70ebf26f1 in AAASessionsLock (hash=0) at session.c:79
#3 0x00007fe70ebf5e6e in cdp_get_session (id=...) at session.c:316
#4 0x00007fe70eba6892 in Snd_Message (p=0x7fe6e4a5c880, msg=0x7fe6e63998d0) at peerstatemachine.c:1237
#5 0x00007fe70eba003e in sm_process (p=0x7fe6e4a5c880, event=Send_Message, msg=0x7fe6e63998d0, peer_locked=0, sock=0) at peerstatemachine.c:429
#6 0x00007fe70ebcbdc6 in AAASendMessage (message=0x7fe6e63998d0, callback_f=0x7fe707a8f208 <resume_on_interim_ccr>, callback_param=0x7fe6e6190a90) at diameter_comm.c:166
#7 0x00007fe707a8edb3 in send_ccr_interim (ro_session=0x7fe6e5399160, used=60, reserve=30) at ims_ro.c:847
#8 0x00007fe707a68bd6 in ro_session_ontimeout (tl=0x7fe6e5399200) at ro_timer.c:513
#9 0x00007fe707a63078 in ro_timer_routine (ticks=114862426, attr=0x0) at ro_timer.c:279
#10 0x00000000004fd33e in compat_old_handler (ti=1837798827, tl=0x7fe6e4cf6260, data=0x7fe6e4cf6260) at core/timer.c:980
#11 0x00000000004fde7a in slow_timer_main () at core/timer.c:1103
#12 0x000000000042e4e7 in main_loop () at main.c:1911
#13 0x000000000043876c in main (argc=10, argv=0x7ffe50f001c8) at main.c:3236
```
In `get_first_connected_route()` in `routing.c` of the cdp module there are two places `get_peer_by_fqdn()` are called. One of them has an unlock/relock of the session list before and after (and a comment about holding two locks at a time), while the other doesn't.
I'm currently testing two version of this. The first by just doing the some relock for the other `get_peer_by_fqdn()`, but this PR got an approach for maybe fixing more latent issues. `sm_process()` also got some strange handling by `Rcv_Process()` after the peer lock is released, which seems to be about the same thing. My deadlock is for the `Snd_Message()` equivalent.
I've now removed this queueing behaviour, and instead doing a re-lock of the peer to (hopefully) have the same locking order as the other operations.
The problem with this thing is how rare it occurs. Just wanted to share my findings for others with more knowledge to the cdp module for comments, suggestions and hopefully some extra testing.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4191
-- Commit Summary --
* cdp: restructure locking order to prevent rare deadlock
-- File Changes --
M src/modules/cdp/peerstatemachine.c (25)
M src/modules/cdp/routing.c (6)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4191.patchhttps://github.com/kamailio/kamailio/pull/4191.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4191
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4191(a)github.com>
<!-- 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
- [x] 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
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
Currently `stirshaken` module performs x509 certificate path check twice (when enabled):
- first by calling `stir_shaken_verify_cert_path` directly from the [`stirshaken_mod.c`](https://github.com/kamailio/kamailio/blob/330543f46cbb6bf815ebf77c98378314091197ce/src/modules/stirshaken/stirshaken_mod.c#L626)
- second time from the [`libstirshaken`](https://github.com/signalwire/libstirshaken/blame/cb6ede40b3ce12ab76e370186a14dc141839ef07/src/stir_shaken_verify.c#L445)
`libstirshaken` had the path check built in since approx 2020 ([last commit mentioning it as TODO](https://github.com/signalwire/libstirshaken/blame/552650e31e3dc668069… before the `stir_shaken_verify_cert_path` function was introduced). This shouldn't be an issue since `stirshaken` module was added to Kamailio in 2021.
This PR removes the x509 certificate path check from the `stirshaken_mod.c` by passing the responsibility to perform certificate path check to the `libstirshaken`.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4202
-- Commit Summary --
* stirshaken: removed repeated x509 certification path check
-- File Changes --
M src/modules/stirshaken/doc/stirshaken_admin.xml (4)
M src/modules/stirshaken/stirshaken_mod.c (17)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4202.patchhttps://github.com/kamailio/kamailio/pull/4202.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4202
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4202(a)github.com>
Module: kamailio
Branch: master
Commit: f007736ba18f5cc2114ffdd1e6df2b9b03808fe7
URL: https://github.com/kamailio/kamailio/commit/f007736ba18f5cc2114ffdd1e6df2b9…
Author: FelipeCuadra <f.cuadra(a)zaleos.net>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2025-05-06T13:34:41+02:00
stirshaken: removed repeated x509 certification path check
- removed a second check of the x509 certificate path from the module, since it is already done earlier in the library and updated documentation
---
Modified: src/modules/stirshaken/doc/stirshaken_admin.xml
Modified: src/modules/stirshaken/stirshaken_mod.c
---
Diff: https://github.com/kamailio/kamailio/commit/f007736ba18f5cc2114ffdd1e6df2b9…
Patch: https://github.com/kamailio/kamailio/commit/f007736ba18f5cc2114ffdd1e6df2b9…
---
diff --git a/src/modules/stirshaken/doc/stirshaken_admin.xml b/src/modules/stirshaken/doc/stirshaken_admin.xml
index ef07e6a7212..41f72e5c1b7 100644
--- a/src/modules/stirshaken/doc/stirshaken_admin.xml
+++ b/src/modules/stirshaken/doc/stirshaken_admin.xml
@@ -528,6 +528,10 @@ request_route {
...
</programlisting>
</example>
+ <para>
+ To ensure proper functionality, the Kamailio stirshaken module requires a minimum version of libstirshaken that includes the stir_shaken_verify_cert_path function for performing the x509 certificate path check. This functionality was added to libstirshaken around 2020 (<![CDATA[https://github.com/signalwire/libstirshaken/commit/58e740b897ae40e2bb02ada2231a051a7eb55137]]>).
+ If you're using an older version of libstirshaken that predates this commit, the stirshaken module may not function correctly.
+ </para>
</section>
</chapter>
diff --git a/src/modules/stirshaken/stirshaken_mod.c b/src/modules/stirshaken/stirshaken_mod.c
index 95bbdeb5736..5d0bc744885 100644
--- a/src/modules/stirshaken/stirshaken_mod.c
+++ b/src/modules/stirshaken/stirshaken_mod.c
@@ -613,23 +613,6 @@ static int ki_stirshaken_check_identity(sip_msg_t *msg)
goto fail;
}
- if(stirshaken_vs_verify_x509_cert_path) {
-
- LM_DBG("Running X509 certificate path verification\n");
-
- if(!vs) {
- LM_ERR("Verification Service not started\n");
- goto fail;
- }
-
- if(STIR_SHAKEN_STATUS_OK
- != stir_shaken_verify_cert_path(&ss, cert_out, vs->store)) {
- LM_ERR("Cert did not pass X509 path validation\n");
- stirshaken_print_error_details(&ss);
- goto fail;
- }
- }
-
if(stirshaken_vs_pptg_pvname.s != 0) {
memset(&val, 0, sizeof(pv_value_t));
val.flags = PV_VAL_STR;
<!-- 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 -->
- The code that loaded a JavaScript file used a fix buffer length of 128K on the stack. This has been changed so that the file size is determined and an attempt to allocate an appropriate buffer size temporarily is made. The file contents are then loaded into that buffer before being passed to the duktape engine.
- In addition a new module param 'loaddir' has been added that allows you to specify a directory containing .js files rather than specifying a single .js file to load with the existing 'load' param. If loaddir is set it will take a higher priority than load. All .js files in the directory are loaded into a temporary buffer and combined before passing to the duktape engine. This allows you to split logic/routes into separate .js files but load them all into the JavaScript engine.
- Updated documentation
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4221
-- Commit Summary --
* app_jstd: Added dynamic buffer sizing to load bigger .js files and Added ability to load all JavaScript files from a specified directory
-- File Changes --
M src/modules/app_jsdt/app_jsdt_api.c (175)
M src/modules/app_jsdt/app_jsdt_mod.c (2)
M src/modules/app_jsdt/doc/app_jsdt_admin.xml (31)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4221.patchhttps://github.com/kamailio/kamailio/pull/4221.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4221
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4221(a)github.com>
Module: kamailio
Branch: master
Commit: 4ed2449454d07594f9bc30622b7fada9d719c5a3
URL: https://github.com/kamailio/kamailio/commit/4ed2449454d07594f9bc30622b7fada…
Author: ngash <nick.gash(a)ccprosolutions.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2025-05-06T13:33:50+02:00
app_jsdt: Added dynamic buffer sizing to load bigger .js files and Added ability to load all JavaScript files from a specified directory
- The code that loaded a JavaScript file used a fix buffer length of 128K on the stack. This has been changed so that the file size is determined and an attempt to allocate an appropriate buffer size temporarily is made. The file contents are then loaded into that buffer before being passed to the duktape engine.
- In addition a new module param 'loaddir' has been added that allows you to specify a directory containing .js files rather than specifying a single .js file to load with the existing 'load' param. If loaddir is set it will take a higher priority than load. All .js files in the directory are loaded into a temporary buffer and combined before passing to the duktape engine. This allows you to split logic/routes into seperate .js files but load them all inbto the JavaScript engine.
- Updated documentation accordinglyapp_jsdt: Added dynamic buffer sizing to load bigger .js files and Added ability to load all JavaScript files from a specified directory
- The code that loaded a JavaScript file used a fix buffer length of 128K on the stack. This has been changed so that the file size is determined and an attempt to allocate an appropriate buffer size temporarily is made. The file contents are then loaded into that buffer before being passed to the duktape engine.
- In addition a new module param 'loaddir' has been added that allows you to specify a directory containing .js files rather than specifying a single .js file to load with the existing 'load' param. If loaddir is set it will take a higher priority than load. All .js files in the directory are loaded into a temporary buffer and combined before passing to the duktape engine. This allows you to split logic/routes into seperate .js files but load them all inbto the JavaScript engine.
- Updated documentation accordingly
---
Modified: src/modules/app_jsdt/app_jsdt_api.c
Modified: src/modules/app_jsdt/app_jsdt_mod.c
Modified: src/modules/app_jsdt/doc/app_jsdt_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/4ed2449454d07594f9bc30622b7fada…
Patch: https://github.com/kamailio/kamailio/commit/4ed2449454d07594f9bc30622b7fada…
<!-- 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
PR adds new core option `tls_connection_match_domain` with the default value 0 (old behavior)
to solve the problem when we need to have multiple TLS connections with different SNI to the same host:port endpoint.
for example: multiple customers (authorized by cert) for MS Teams on the single kamailio instance.
originally, functions `_tcpconn_find` and `_tcpconn_add_alias_unsafe` use only endpoint and protocol to match connections.
setting `tls_connection_match_domain` to `1` will match additionaly with `tls_domain_str()` output for matched TLS domain.
as a result, we will be able to establish new TLS connections if TLS domain is changed instead of reusing of the existent one with the wrong SNI.
i'm not considering this PR as the final version but we need something to start with. looking forward for any input.
FIXME: not found the right place where new core option should be documented.
#### Behavior difference example
* /etc/kamailio/kamailio.cfg
(relays all requests to 127.0.0.1:5081 using TLS domain matched by server_id retreived from RURI-User):
```
#!KAMAILIO
listen=udp:127.0.0.1:5060
listen=tls:127.0.0.1:5061
enable_tls = yes
tls_connection_match_domain = 1
debug = 3
loadmodule "tls.so"
modparam("tls", "config", "/etc/kamailio/tls.cfg")
modparam("tls", "xavp_cfg", "tls")
loadmodule "ctl.so"
loadmodule "pv.so"
loadmodule "tm.so"
route {
$xavp(tls=>server_id) = $rU;
t_relay_to_tls("127.0.0.1", 5081);
}
```
* /etc/kamailio/tls.cfg:
```
[server:default]
certificate = /etc/ssl/certs/ssl-cert-snakeoil.pem
private_key = /etc/ssl/private/ssl-cert-snakeoil.key
[client:any]
server_name = server_name_1.invalid
server_id = 1
[client:any]
server_name = server_name_2.invalid
server_id = 2
```
* run tls server:
```bash
$ openssl s_server -port 5081 -cert /etc/ssl/certs/ssl-cert-snakeoil.pem -key /etc/ssl/private/ssl-cert-snakeoil.key
```
* send `INVITE sip:1@127.0.0.1:5060` and `INVITE sip:2@127.0.0.1:5060` using sipp:
```bash
$ for u in 1 2; do sipp -sn uac -m 1 -nd -recv_timeout 1 -bg -s $u 127.0.0.1:5060; done
```
* resulting `tls.list` for kamailio instance WITHOUT `tls_connection_match_domain = 1` (old behavior):
```bash
# kamcmd tls.list
{
id: 1
dom: TLSc<any:server_name_1.invalid>
sni: N/A
timestamp: 2025-04-24 14:07:20
timeout: 118
src_ip: 127.0.0.1
src_port: 5081
dst_ip: 127.0.0.1
dst_port: 58808
cipher: unknown
ct_wq_size: 1162
enc_rd_buf: 0
flags: 1
state: tls_connect
}
```
* `tls.list` for kamailio instance WITH `tls_connection_match_domain = 1` (new behavior):
```bash
# kamcmd tls.list
{
id: 1
dom: TLSc<any:server_name_1.invalid>
sni: N/A
timestamp: 2025-04-24 14:09:10
timeout: 117
src_ip: 127.0.0.1
src_port: 5081
dst_ip: 127.0.0.1
dst_port: 55480
cipher: unknown
ct_wq_size: 581
enc_rd_buf: 0
flags: 1
state: tls_connect
}
{
id: 2
dom: TLSc<any:server_name_2.invalid>
sni: N/A
timestamp: 2025-04-24 14:09:10
timeout: 117
src_ip: 127.0.0.1
src_port: 5081
dst_ip: 127.0.0.1
dst_port: 55488
cipher: unknown
ct_wq_size: 581
enc_rd_buf: 0
flags: 1
state: tls_connect
}
```
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4222
-- Commit Summary --
* core: support tls connection domain matching
* tls: implement match_domain,match_connections_domain hooks
* tls_wolfssl: implement match_domain,match_connections_domain hooks
-- File Changes --
M src/core/cfg.lex (3)
M src/core/cfg.y (9)
M src/core/globals.h (1)
M src/core/tcp_main.c (14)
M src/core/tls_hooks.h (9)
M src/main.c (4)
M src/modules/tls/tls_mod.c (2)
M src/modules/tls/tls_rpc.c (12)
M src/modules/tls/tls_server.c (97)
M src/modules/tls/tls_server.h (8)
M src/modules/tls_wolfssl/tls_rpc.c (12)
M src/modules/tls_wolfssl/tls_server.c (94)
M src/modules/tls_wolfssl/tls_server.h (7)
M src/modules/tls_wolfssl/tls_wolfssl_mod.c (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4222.patchhttps://github.com/kamailio/kamailio/pull/4222.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4222
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4222(a)github.com>