Hello,
we should consider an online devel meeting sometime soon to summarize
what was done at (and still needs to be done after) devel meeting in
Dusseldorf and plan a bit the targets for next major release (5.8 or 6.0)?
If considered useful, I propose Dec 5 at 15:00UTC (16:00
Berlin/Paris/Madrid/Rome), but we can also look for other dates as well.
Topics to be discussed can be added at:
-
https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings…
Pull requests can be made by users without git access.
Cheers,
Daniel
PS: Previous announcement indicated the start time 14:30 UTC, this
message changes it to 15:00 UTC - 30min later due to a constraint in
availability of one of the Kamailio developers.
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hi guys,
Can anybody explain to me this flow.
https://raw.githubusercontent.com/havfo/WEBRTC-to-SIP/master/images/webrtc-…
And
What will be done in 1,2,3,4,5. When a new connection the request flow is 1,2,3,4,5 order is created.
1: webRTC client -> SIp Server
2: SIP server -> SIP client
3: Kmailio -> RTPengine
4: SIP client -> RTPengine
5: RTPengine -> webRTC client
Hello Kamailio team,
I am an enthusiast of the Kamailio project, interested in an IMS project. I am working on integrating Kamailio with SEMS and am keen to utilize SEMS's Announcements (Prompts, Ringbacktones, Pre-call-prompts) feature. However, in the current project's PCSCF module, SEMS is being used as an SBC. Could you possibly provide some .cfg demos for using SEMS specifically for Announcements? I would greatly appreciate your assistance.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3662
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3662(a)github.com>
the function replace_body_all place after rtpengine_offer(), I expect that it will change the SDP however actually It does not.
pseudo code like:
```
rtpengine_offer();
replace_body_all("Asterisk", "NipponMedia");
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3661
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3661(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
Kamailio does not properly release connected WebSocket TCP connections, leading to a situation where the maximum number of allowable connections is reached and new connection requests are rejected.
### Troubleshooting
When examining the logs, we identified an issue where Kamailio is failing to release connected WebSocket TCP connections, causing a backlog of TIME_WAIT connections. The logs show a warning message indicating that the maximum number of allowable sockets per IP has been reached, leading to the rejection of further WebSocket requests.
#### Reproduction
Establish WebSocket connections with Kamailio.
Monitor the number of TIME_WAIT connections using netstat.
Observe the warning message in Kamailio logs when the maximum allowable sockets per IP are reached.
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### 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
<!--
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).
-->
```
2023-10-03T13:19:33.699043+00:00 apps001 kamailio[23781]: WARNING: |<null>|websockets-role.cfg:224 (websocket_request) 223.233.86.93 is at the maximum 50 allowable sockets per IP, rejecting request for another websocket
netstat -punta | grep 223.233.86.93 | grep 5065
tcp 0 0 45.79.166.214:5065 223.233.86.93:52158 TIME_WAIT -
tcp 0 0 45.79.166.214:5065 223.233.86.93:52195 TIME_WAIT -
tcp 0 0 45.79.166.214:5065 223.233.86.93:52292 TIME_WAIT -
tcp 0 0 45.79.166.214:5065 223.233.86.93:52248 TIME_WAIT -
tcp 0 0 45.79.166.214:5065 223.233.86.93:52108 TIME_WAIT -
tcp 0 0 45.79.166.214:5065 223.233.86.93:52071 TIME_WAIT -
```
#### 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
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
restarting kamailio solves the problem.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.7.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, 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 on 14:39:54 Sep 27 2023 with gcc 7.3.1
```
* **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`)
-->
```
CentOS Linux release 7.9.2009 (Core)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3589
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3589(a)github.com>
Hi,
I have sample json data as below:
$var(mapjson) = {"1.1.1.1": "cloudflare", "2.2.2.2": "ANY"};
I add this line to kamailio script but it does NOT work,
jansson_get("1.1.1.1", "$var(mapjson) ", “$var(domain)“);
or
jansson_get("1\.1\.1\.1", "$var(mapjson) ", “$var(domain)“);
Seem kamailio thinks it is a **path** not **a single key**?
Thanks
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3658
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3658(a)github.com>
Module: kamailio
Branch: master
Commit: 006cca915275f8ca3ea52a9d978961e0842f1dcd
URL: https://github.com/kamailio/kamailio/commit/006cca915275f8ca3ea52a9d978961e…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-30T10:18:47+01:00
ims_ipsec_pcscf: docs for ipsec_destroy_by_contact()
---
Modified: src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/006cca915275f8ca3ea52a9d978961e…
Patch: https://github.com/kamailio/kamailio/commit/006cca915275f8ca3ea52a9d978961e…
---
diff --git a/src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml b/src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml
index d50c66ed45a..24d77440d89 100644
--- a/src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml
+++ b/src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml
@@ -367,6 +367,40 @@ ipsec_forward("location", "1");
<programlisting format="linespecific">
...
ipsec_destroy("location");
+...
+ </programlisting>
+ </example>
+ </section>
+ <section>
+ <title><function moreinfo="none">ipsec_destroy_by_contact(domain, aor, recv_host, recv_port)</function></title>
+ <para>The function destroys IPSec tunnel, created with ipsec_create.</para>
+ <para>Meaning of the parameters is as follows:</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis>domain</emphasis> - Logical domain within the registrar.
+ If a database is used then this must be name of the table which
+ stores the contacts.
+ </para>
+ <para>
+ <emphasis>aor</emphasis> - SIP URI to match the record.
+ </para>
+ <para>
+ <emphasis>recv_host</emphasis> - received host to match the record.
+ </para>
+ <para>
+ <emphasis>recv_port</emphasis> - received port to match the record.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>The last three parameters have to be string valies and can contain
+ variables.</para>
+ <example>
+ <title>ipsec_destroy_by_contact()</title>
+
+ <programlisting format="linespecific">
+...
+ipsec_destroy_by_contact("location", "...", "...", "...");
...
</programlisting>
</example>
Module: kamailio
Branch: master
Commit: 279454ff8d4e5804d92a8690c4de3a507efbc44f
URL: https://github.com/kamailio/kamailio/commit/279454ff8d4e5804d92a8690c4de3a5…
Author: Supreeth Herle <herlesupreeth(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-30T10:18:47+01:00
ims_ipsec_pcscf: new function to destroy IPSec based on Contact and received IP and port
- the default ipsec_destroy() cannot be used to used destroy IPSec in any route and
needed to be used exactly after all the de-registration process was complete. But,
as per the kamailio P-CSCF config script, ipsec_destroy() was used in reply route of
NATPING, which didn't have any idea about SIP Register message used for de-registration.
Thus, resulting in IPSec not being destroyed even after de-registration was complete.
- the newly introduced function ipsec_destroy_by_contact() takes domain, contact, received host
and received port in order to determine the exact UE's IPSec tunnel to destroy.
---
Modified: src/modules/ims_ipsec_pcscf/cmd.c
Modified: src/modules/ims_ipsec_pcscf/cmd.h
Modified: src/modules/ims_ipsec_pcscf/ims_ipsec_pcscf_mod.c
---
Diff: https://github.com/kamailio/kamailio/commit/279454ff8d4e5804d92a8690c4de3a5…
Patch: https://github.com/kamailio/kamailio/commit/279454ff8d4e5804d92a8690c4de3a5…
<!-- 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
<!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3657
-- Commit Summary --
* nathelper: Add Max-Forwards to keep-alive
-- File Changes --
M src/modules/nathelper/sip_pinger.h (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3657.patchhttps://github.com/kamailio/kamailio/pull/3657.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3657
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3657(a)github.com>
After 7f07a6ef9ae90baee4281394d0dcf505b30c8fcb, building the ktls group doesn't work as it's not included in the #else statement. I don't have a need for ktlsa at this point.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3660
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3660(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 -->
- [x] PR should be backported to stable branches
- [ ] Tested changes locally
#### Description
If kamailio is in the shutdown phase proc timers should not be executed since memory objects are getting destroyed and cores could happen
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3649
-- Commit Summary --
* core: timer_proc don't execute timers on destroy_modules_phase
-- File Changes --
M src/core/timer_proc.c (19)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3649.patchhttps://github.com/kamailio/kamailio/pull/3649.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3649
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3649(a)github.com>
Module: kamailio
Branch: master
Commit: 9eeab4396d8ec57781244ab80c4a96539d7338ec
URL: https://github.com/kamailio/kamailio/commit/9eeab4396d8ec57781244ab80c4a965…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-28T10:20:41+01:00
jansson: docs updated for jansson_get_field()
---
Modified: src/modules/jansson/doc/jansson_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/9eeab4396d8ec57781244ab80c4a965…
Patch: https://github.com/kamailio/kamailio/commit/9eeab4396d8ec57781244ab80c4a965…
---
diff --git a/src/modules/jansson/doc/jansson_admin.xml b/src/modules/jansson/doc/jansson_admin.xml
index debc9cc5a19..daa5e9ea51e 100644
--- a/src/modules/jansson/doc/jansson_admin.xml
+++ b/src/modules/jansson/doc/jansson_admin.xml
@@ -56,10 +56,16 @@
<title>Functions</title>
<section id="jansson.f.jansson_get">
<title>
- <function moreinfo="none">jansson_get(key/path, src, dst)</function>
+ <function moreinfo="none">jansson_get(path, src, dst)</function>
</title>
<para>
- Copy the value at the location 'path' from the json object 'src' and store it in pvar 'dst'.
+ Copy the value at the location 'path' from the json object 'src'
+ and store it in variable 'dst'. The path can also be a simple field name
+ (a key), if it does not include any path separator. To retrieve the
+ value of a field that includes path separators in the name, use
+ jansson_get_field().
+ </para>
+ <para>
The 'src' can be a static string or a dynamic string with variables.
</para>
<para>
@@ -71,7 +77,7 @@
</para>
<para>
The function can put a string, integer, null, or new json string into destination.
- If the key/path can't be found in the JSON data structure, the pvar is not changed.
+ If the path can't be found in the JSON data structure, the pvar is not changed.
If it had a previous
value, that value remains unchanged.
</para>
@@ -280,22 +286,27 @@ jansson_xencode("a", "$var(js)");
</section>
<section id="jansson.f.jansson_get_field">
<title>
- <function moreinfo="none">jansson_get_field(src, field_name, dst)</function>
+ <function moreinfo="none">jansson_get_field(field_name, src, dst)</function>
</title>
<para>
- Copy field 'field_name' from json object 'src' and store it in pvar 'dst'.
+ Copy the value of the field 'field_name' from json object 'src'
+ and store it in pvar 'dst'. The field name is not evaluated as JSON
+ path, therefore it has a different behaviour than jansson_get() and
+ can be used when the field name contains path delimiters.
</para>
<para>
- <emphasis>This function is deprecated</emphasis> but kept for backwards compatibility.
- Right now it is just a wrapper around <function>jansson_get</function>, and its
- functionality is the same.
+ Note that till version 5.7.x, this function was similar to jansson_get(),
+ after that its behaviour changed to work as described above. Also,
+ the order of parameters changed.
</para>
<example>
<title><function>jansson_get_field</function> usage</title>
<programlisting format="linespecific">
...
-jansson_get_field("{'foo':'bar'}", "foo", "$var(foo)");
+jansson_get_field("foo", "{'foo':'bar'}", "$var(foo)");
xlog("foo is $var(foo)");
+jansson_get_field("foo.foz", "{'foo.foz':'bar.buz'}", "$var(foofoz)");
+xlog("foo.foz is $var(foofoz)");
...
</programlisting>
</example>
Hello,
during the Kamailio Development Meeting that took place in Dusseldorf
earlier this month, one topic was related to administrative tasks
related to project development and management, how to
simplify/automatize such tasks.
To reduce the work load on volunteering contributors, GitHub Actions
were already used for various tasks related to project development and
management (e.g., automatic builds on commits and pull requests to
detect compile errors or code formatting mistakes).
In Dusseldorf another task was configured to be managed with GitHub
Actions, respectively the check of open issues and pull requests to
evaluate the interest of submitters, developers and community users to
pursue them. If there is no activity on an issue (potential bug or
feature request) or a pull request, after 6 weeks it is marked with the
label `stale`. After two more weeks of no activity, the issue or the
pull request is marked with the label `expired` and closed. Note that
any comment postpones the expire timeline, being considered that there
is interest in pursuing the issue or the pull request.
Requests for features were already treated in this way: if nobody
commits to implement it, it can be closed after one month, but it needed
manual work and many were still kept open. Potential bug reports that
become very old are hard to tackle if the source code changes or new
major releases are out, they might even not be valid anymore.
Anyhow, this automatic operations can be reverted if there is still
interest in pursuing the specific issues or pull requests. A registered
developer can remove labels and reopen a closed issue or pull request.
The non-registered-developer contributors have to make a comment that
includes the token `/notstale` to remove the label `stale` or includes
the token `/notexpired` to reopen a closed item.
This new kind of automatic task management might add a little
inconvenience because one has to restate the interest from time to time
for those items that could not be addressed. However, considering that
Kamailio is an open source collaborative project, in order to be fair
for those that volunteer to spend time and resources for development of
Kamailio, also the users/submitters have to stay engaged, not just
report and forget about.
The process to automatize tasks related to Kamailio development and
administration is work in progress. Everything can be adjusted based on
feedback (e.g., time lines), feel free to suggest improvements or new
solutions to make things easier for everyone within the project ecosystem.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training -- asipto.com
Module: kamailio
Branch: master
Commit: 4840ea7536610d07ad6fda76da60ded04dfeabc7
URL: https://github.com/kamailio/kamailio/commit/4840ea7536610d07ad6fda76da60ded…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-27T19:23:36+01:00
.github/CONTRIBUTING.md: section for issue and pr automatic management
---
Modified: .github/CONTRIBUTING.md
---
Diff: https://github.com/kamailio/kamailio/commit/4840ea7536610d07ad6fda76da60ded…
Patch: https://github.com/kamailio/kamailio/commit/4840ea7536610d07ad6fda76da60ded…
---
diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
index 2c5d46842b8..e01dd82c3ce 100644
--- a/.github/CONTRIBUTING.md
+++ b/.github/CONTRIBUTING.md
@@ -20,6 +20,7 @@ changes to this document in a pull request.
* [Commit Message Examples](#commit-message-examples)
* [See Also](#see-also)
* [Reporting Issues](#reporting-issues)
+ * [Issue And PR Automatic Management](#issue-and-pr-automatic-management)
* [License](#license)
* [License Of New Code Contributions](#license-of-new-code-contributions)
* [Further Assistance](#further-assistance)
@@ -251,6 +252,32 @@ Note: replace any sensitive information in the content you add to the issue
(e.g., passwords in modparams can be replaced with xyz, each IP address can be
replaced with tokens like a.b.c.d, f.g.h.j).
+## Issue And PR Automatic Management ##
+
+This section presents details about the automatic management of potential bug
+reports and requests for new features using github actions.
+
+Kamailio is an open source collaborative project, in order to be fair for those
+that volunteer to spend time and resources for development of Kamailio, the users
+have to stay engaged, not just report and forget about.
+
+To reduce the work load on volunteering contributors, GitHub Actions are used
+for various tasks related to project development and management (e.g., automatic
+builds on commits and pull requests to detect compile errors or code formatting
+mistakes).
+
+One task managed with GitHub Actions is related to the check of open
+issues and pull requests to evaluate the interest of submitter, developers and
+community users. If there is no activity on an issue (potential bug or feature
+request) or a pull request, after 6 weeks it is marked with the label `stale`.
+After two more weeks of no activity, the issue or the pull request is marked
+with the label `expired` and closed.
+
+A registered developer can remove labels and reopen a closed issue or pull
+request. The other contributors have to make a comment that includes the token
+`/notstale` to remove the label `stale` or includes the token `/notexpired` to
+reopen a closed item.
+
## License ##
Kamailio Main License: *GPLv2*.
Module: kamailio
Branch: master
Commit: 96300556ea4787f6f99926dcc7305ec6e4e3df75
URL: https://github.com/kamailio/kamailio/commit/96300556ea4787f6f99926dcc7305ec…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-27T17:11:53+01:00
.github/ISSUE_TEMPLATE: notes about expiration of items and how to reopen
---
Modified: .github/ISSUE_TEMPLATE/bug_report.md
Modified: .github/ISSUE_TEMPLATE/feature_request.md
---
Diff: https://github.com/kamailio/kamailio/commit/96300556ea4787f6f99926dcc7305ec…
Patch: https://github.com/kamailio/kamailio/commit/96300556ea4787f6f99926dcc7305ec…
---
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
index e657ee1a979..01b1672bbb7 100644
--- a/.github/ISSUE_TEMPLATE/bug_report.md
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -17,6 +17,15 @@ If you have questions about developing extensions to Kamailio or its existing C
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
+Note that an issue report may be closed automatically after about 2 months
+if there is no interest from developers or community users on pursuing it, being
+considered expired. In such case, it can be reopened by writing a comment that includes
+the token `/notexpired`. About two weeks before considered expired, the issue is
+marked with the label `stale`, trying to notify the submitter and everyone else
+that might be interested in it. To remove the label `stale`, write a comment that
+includes the token `/notstale`. Also, any comment postpone the `expire` timeline,
+being considered that there is interest in pursuing the issue.
+
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
index 2c21427e600..6206cee95c7 100644
--- a/.github/ISSUE_TEMPLATE/feature_request.md
+++ b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -21,6 +21,15 @@ If you submit a feature request (or enhancement) add the description of what you
If there is no content to be filled in a section, the entire section can be removed.
+Note that a feature request may be closed automatically after about 2 months
+if there is no interest from developers or community users to implement it, being
+considered expired. In such case can be reopened by writing a comment that includes
+the token `/notexpired`. About two weeks before considered expired, the item is
+marked with the label `stale`, trying to notify the submitter and everyone else
+that might be interested in it. To remove the label `stale`, write a comment that
+includes the token `/notstale`. Also, any comment postpone the `expire` timeline,
+being considered that there is interest in the proposed feature request.
+
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
Module: kamailio
Branch: master
Commit: 5a65791e3959439a699d746ce8e63d438e8db0a5
URL: https://github.com/kamailio/kamailio/commit/5a65791e3959439a699d746ce8e63d4…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2023-11-27T14:17:09+01:00
modules: readme files regenerated - topoh ... [skip ci]
---
Modified: src/modules/topoh/README
---
Diff: https://github.com/kamailio/kamailio/commit/5a65791e3959439a699d746ce8e63d4…
Patch: https://github.com/kamailio/kamailio/commit/5a65791e3959439a699d746ce8e63d4…
---
diff --git a/src/modules/topoh/README b/src/modules/topoh/README
index f1a761bf8f9..0217b90d30f 100644
--- a/src/modules/topoh/README
+++ b/src/modules/topoh/README
@@ -162,12 +162,12 @@ modparam("topoh", "mask_key", "some secret here")
IP address to be used in masked headers to build valid SIP URIs. Can be
any IP address, even a private-space or non-existing IP address (e.g.,
192.168.1.1, 127.0.0.2), including the SIP server address, but must not
- be an address potentially used by clients. If not set, the advertised
- IP of the incoming or outgoing socket is used. If there is no
- advertised IP, the IP of the socket is used. It is not used at all for
- SIP routing.
+ be an address potentially used by clients. If set to empty string, the
+ advertised IP of the incoming or outgoing socket is used when
+ specified, otherwise the IP of the socket is used. Note that the value
+ is actually not used at all for SIP routing.
- Default value is empty.
+ Default value is "127.0.0.8".
Example 1.2. Set mask_ip parameter
...
Module: kamailio
Branch: master
Commit: 52cee630d367287daa4b15c042b25bec76192e80
URL: https://github.com/kamailio/kamailio/commit/52cee630d367287daa4b15c042b25be…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2023-11-27T14:02:31+01:00
modules: readme files regenerated - topoh ... [skip ci]
---
Modified: src/modules/topoh/README
---
Diff: https://github.com/kamailio/kamailio/commit/52cee630d367287daa4b15c042b25be…
Patch: https://github.com/kamailio/kamailio/commit/52cee630d367287daa4b15c042b25be…
---
diff --git a/src/modules/topoh/README b/src/modules/topoh/README
index 2fa0f4fd398..f1a761bf8f9 100644
--- a/src/modules/topoh/README
+++ b/src/modules/topoh/README
@@ -162,10 +162,12 @@ modparam("topoh", "mask_key", "some secret here")
IP address to be used in masked headers to build valid SIP URIs. Can be
any IP address, even a private-space or non-existing IP address (e.g.,
192.168.1.1, 127.0.0.2), including the SIP server address, but must not
- be an address potentially used by clients. It is not used at all for
+ be an address potentially used by clients. If not set, the advertised
+ IP of the incoming or outgoing socket is used. If there is no
+ advertised IP, the IP of the socket is used. It is not used at all for
SIP routing.
- Default value is "127.0.0.8".
+ Default value is empty.
Example 1.2. Set mask_ip parameter
...
<!-- 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)
- [ ] 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 -->
topoh: uses socket IP when no mask_ip is defined
If the parameter mask_ip is not defined the module finds the socket IP
and uses that as mask IP for the message.
If the socket has an advertised IP it is used, otherwise the socket IP is used.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3341
-- Commit Summary --
* topoh: uses socket IP when no mask_ip is defined
* Merge remote-tracking branch 'upstream/master'
-- File Changes --
M src/modules/topoh/doc/topoh_admin.xml (4)
M src/modules/topoh/th_msg.c (55)
M src/modules/topoh/th_msg.h (16)
M src/modules/topoh/topoh_mod.c (309)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3341.patchhttps://github.com/kamailio/kamailio/pull/3341.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3341
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3341(a)github.com>
Module: kamailio
Branch: master
Commit: 8bfe55c68a06492c93a327eff6813fa0da8399dd
URL: https://github.com/kamailio/kamailio/commit/8bfe55c68a06492c93a327eff6813fa…
Author: TorPetterson <32388321+TorPetterson(a)users.noreply.github.com>
Committer: GitHub <noreply(a)github.com>
Date: 2023-11-27T13:50:09+01:00
topoh: uses socket IP when no mask_ip is defined (#3341)
* topoh: uses socket IP when no mask_ip is defined
If the parameter mask_ip is not defined the module finds the socket IP
and uses that as mask IP for the message.
If the socket has an advertised IP it is used, otherwise the socket IP is used.
---
Modified: src/modules/topoh/doc/topoh_admin.xml
Modified: src/modules/topoh/th_msg.c
Modified: src/modules/topoh/th_msg.h
Modified: src/modules/topoh/topoh_mod.c
---
Diff: https://github.com/kamailio/kamailio/commit/8bfe55c68a06492c93a327eff6813fa…
Patch: https://github.com/kamailio/kamailio/commit/8bfe55c68a06492c93a327eff6813fa…
Module: kamailio
Branch: master
Commit: f7caef5d4ba3fde04425b6480badcacc14f4f6e6
URL: https://github.com/kamailio/kamailio/commit/f7caef5d4ba3fde04425b6480badcac…
Author: Wolfgang Kampichler <dev(a)kampichler.info>
Committer: Wolfgang Kampichler <dev(a)kampichler.info>
Date: 2023-11-25T11:06:21+01:00
lost: support of shape representations (as in RFC5491) and new 3d parameter
- A Presence Information Data Format Location Object (PIDF-LO) may
contain one of the shape types as listed in RFC5491. A LoST
findService request currently contains only a profile for
two-dimensional geodetic location information, which
is the default setting for this 3d parameter. The parameter
can be set to 1 if a LoST server supports 3d, otherwise a
3d location is reduced to 2d by the module.
---
Modified: src/modules/lost/doc/lost_admin.xml
Modified: src/modules/lost/functions.c
Modified: src/modules/lost/lost.c
Modified: src/modules/lost/response.c
Modified: src/modules/lost/utilities.c
Modified: src/modules/lost/utilities.h
---
Diff: https://github.com/kamailio/kamailio/commit/f7caef5d4ba3fde04425b6480badcac…
Patch: https://github.com/kamailio/kamailio/commit/f7caef5d4ba3fde04425b6480badcac…
- URL: https://github.com/kamailio/kamailio/commit/8779039f655e6cdc27c35a0145985de…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T12:58:52+01:00
core: resolve - cast after pointer operations for RES_AR
(cherry picked from commit 30c42aab767d777e3beb1493165458489957e92d)
- URL: https://github.com/kamailio/kamailio/commit/55584b4de5ac60a1385edf245fc7f5b…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T12:59:09+01:00
core/mem: tlsf - cast to char* for pointer operations
(cherry picked from commit d0a353342b559191aafc732174773e132554694a)
- URL: https://github.com/kamailio/kamailio/commit/d2f5603aff1bad106340b024d4a33f2…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T12:59:23+01:00
core: resolve - variables initialisation
(cherry picked from commit 1623f9ed1728455b72abf0a74f06bfd24365cefb)
- URL: https://github.com/kamailio/kamailio/commit/4d04bafdba440b82a7da8424682b06d…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T12:59:38+01:00
app_python3: reformat exports structures
(cherry picked from commit 042bb9d10e12a256f9e4461031347e09b89fbe98)
- URL: https://github.com/kamailio/kamailio/commit/986cadb088805f5126c61d55fc0b72c…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T12:59:45+01:00
app_python3: use module name prefix for exports structure
(cherry picked from commit 114d6fe510d7c1876782054ed89e4017d39d5f69)
- URL: https://github.com/kamailio/kamailio/commit/340efb9e3951fb4d15ae32e834ac584…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T12:59:53+01:00
app_python3s: reformat exports structures
(cherry picked from commit 9fb9cbddee8974a1733b999807cc1943248753f7)
- URL: https://github.com/kamailio/kamailio/commit/d38cc3c15698b554c177e77e05f7393…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:00:00+01:00
app_python3s: use module name prefix for exports structure
(cherry picked from commit ebe77a2068c5073b436a1f8fefdfd689c9010816)
- URL: https://github.com/kamailio/kamailio/commit/ef9c5e79b6923401a686c31a15af390…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:00:07+01:00
app_lua: reformat exports structures
(cherry picked from commit c6feb52c97bbd3fc33dc837d2b23e56c75f09583)
- URL: https://github.com/kamailio/kamailio/commit/2442079e05b410cc9393fd15daf1f94…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:00:14+01:00
app_lua: use module name prefix for exports structure
(cherry picked from commit 35e191e1bea5463e766cb6f8f2ffb4862bd812a8)
- URL: https://github.com/kamailio/kamailio/commit/8c5a7a8db1309515a1d2f167754a4ee…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:00:50+01:00
app_jsdt: use module name prefix for exports structure
(cherry picked from commit a81e3c45dad338378fc8cf417bb0e9da1172a854)
- URL: https://github.com/kamailio/kamailio/commit/069876708076154387a599bf039edd8…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:01:00+01:00
app_ruby: use module name prefix for exports structure
(cherry picked from commit 65322a8ea66ed18fb2d089ade54702341e064944)
- URL: https://github.com/kamailio/kamailio/commit/3ab5e87f2e162704a261c3a45eeb5c0…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:01:12+01:00
textops: do not print module name in log messages
- it is added automatically
(cherry picked from commit ba1c0424732f1f2ab01bfd078ee272221a6b3e10)
- URL: https://github.com/kamailio/kamailio/commit/c97e6b96821f0ffaf449643ed222908…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:01:19+01:00
avpops: do not print module name in log messages
- it is added automatically
(cherry picked from commit 89a95ce1abefd772c0f09054473b07bbfc5426bc)
- URL: https://github.com/kamailio/kamailio/commit/48fd5246c186524413d452032320378…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:01:26+01:00
avp: do not print module name in log messages
- it is added automatically
(cherry picked from commit 463d5b34390e330a2b733deb673c1c77e5be9fcb)
- URL: https://github.com/kamailio/kamailio/commit/84b1543cf7b77bfffba0c3e6369b4cb…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:01:33+01:00
dialog: do not print module name in log messages
- it is added automatically
(cherry picked from commit e45c97d112c7c396ae0a11b7a431582a71361e5b)
- URL: https://github.com/kamailio/kamailio/commit/d343b6d99cdb9a23ec5bfa332a34245…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:01:44+01:00
dialog: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit d434270933f06b4de43cdf6d4b464bd264a3cb92)
- URL: https://github.com/kamailio/kamailio/commit/583a403d58c3e0e0b64a354d2e5fe4a…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:01:51+01:00
http_async_client: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 40dd9f4e0fbe54046b7786e3572b491103af03d1)
- URL: https://github.com/kamailio/kamailio/commit/c8a09510204e7d0ed9e486f4dc87135…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:01:59+01:00
imc: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 407168804cc1806b857c2ce78399e02a81692d1e)
- URL: https://github.com/kamailio/kamailio/commit/6f3f297ea64a8fed4c77fdaf2abc90e…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:02:08+01:00
ims_auth: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 524eeca084e0a0e61ad80f349ea79f8b1c3031f6)
- URL: https://github.com/kamailio/kamailio/commit/b5a2b0c782a18cd807d6d4851baa9be…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:02:18+01:00
ims_icscf: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 39514660001b37eabfe3af6818949586fae9a4bf)
- URL: https://github.com/kamailio/kamailio/commit/e96ecec877f2f9bc13000c7bd752ed8…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:02:29+01:00
ims_registrar_scscf: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 641d29820f8536247c49d5fb4caa882764dbd9af)
- URL: https://github.com/kamailio/kamailio/commit/876fa1d0667acb2c46e5b8643cdb994…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:02:48+01:00
ims_usrloc_pcscf: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit d29b3d6515f74d4cd7417dc9030d8ca53d57054e)
- URL: https://github.com/kamailio/kamailio/commit/51937a32b205288ebeddfac7c4310b1…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:02:57+01:00
msilo: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 609960812c572d2d19ba774b064fdf7e2ac45765)
- URL: https://github.com/kamailio/kamailio/commit/21f4e3c9ce4a6d7ae87ad746742b283…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:03:03+01:00
nat_traversal: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit f35f327a528670dcca0d7a767643a222f1aebd89)
- URL: https://github.com/kamailio/kamailio/commit/59c32aef1e40edcfb081a18728b4e60…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:03:10+01:00
p_usrloc: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit a951cb44ecbcd0f9cba937176ea5117c6a1d15b6)
- URL: https://github.com/kamailio/kamailio/commit/1467f7517b6256a712eeb9328856193…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:03:17+01:00
registrar: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 0516fb802628ddb659a130aa2959df5b0b8e0c96)
- URL: https://github.com/kamailio/kamailio/commit/9a658e0533e592641f86db037eb398a…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:03:26+01:00
sipcapture: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 01abed3ef17f6a5f0f215675a2980f0b9a4267fd)
- URL: https://github.com/kamailio/kamailio/commit/9a768e006eb0b6ab508ebc5385690eb…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:03:33+01:00
siptrace: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 92cdcb4bd280850743b3a952f1b6003be69daaf2)
- URL: https://github.com/kamailio/kamailio/commit/21abe7ab16d450f1b085a97a4c0f416…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:03:39+01:00
sst: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 96bdd69945af9f08e6c89fb725248b8b268ee71a)
- URL: https://github.com/kamailio/kamailio/commit/d5829f56bfc36133ba6db124bf738a6…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:03:56+01:00
tmx: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit d4c0e1bbcb0e423a545650aad4fbb4b2da8bb488)
- URL: https://github.com/kamailio/kamailio/commit/bf665fc6d398009a0643cb60f9dad95…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:04:03+01:00
tsilo: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit a9d29645ab417c9b0f7afc6745e6dd54bdac07b4)
- URL: https://github.com/kamailio/kamailio/commit/292c8764b22d3cdb78a85f101b03594…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:04:10+01:00
usrloc: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 186ae3eef7f3e1b5ad6222c98a2f35a487deb316)
- URL: https://github.com/kamailio/kamailio/commit/1de0032363ffb0fb6e257497a173f70…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:04:20+01:00
websocket: use literal module name for stats group
- prevent conflicts with global exports
(cherry picked from commit 93609b53d70df84788741800fc2b80c5502a3358)
- URL: https://github.com/kamailio/kamailio/commit/7f07a6ef9ae90baee4281394d0dcf50…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-24T13:04:28+01:00
Makefile.groups: tlsa in packaging group ktls if KTLS_INCLUDE_TLSA=yes
- if not, then it is in separate group module_group_ktlsa
(cherry picked from commit a49c8d8d968e31a539e47db6c06a0756e4be55e3)
Hello,
we should consider an online devel meeting sometime soon to summarize
what was done at (and still needs to be done after) devel meeting in
Dusseldorf and plan a bit the targets for next major release (5.8 or 6.0)?
If considered useful, I propose Dec 5 at 14:30UTC (15:30
Berlin/Paris/Madrid/Rome), but we can also look for other dates as well.
Topics to be discussed can be added at:
-
https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings…
Pull requests can be made by users without git access.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### 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
<!--
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).
-->
```
(paste your log messages here)
```
#### 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
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **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`)
-->
```
(paste your output here)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3655
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3655(a)github.com>
Hello,
Kamailio SIP Server v5.6.5 stable release is out.
This is a maintenance release of the latest stable branch, 5.6, that
includes fixes since the release of v5.6.4. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.6.x. Deployments running previous v5.6.x
versions are strongly recommended to be upgraded to v5.6.5.
Note that 5.6 is the second last stable branch, still officially
maintained by Kamailio development team. The latest stable branch is
5.7, with v5.7.3 being release out of it.
For more details about version 5.6.5 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2023/11/kamailio-v5-6-5-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training -- asipto.com
Hello,
I am considering to release Kamailio v5.6.5 (out of branch 5.6) later
this week (likely on Thursday or Friday, Nov 23/24, 2023). 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 and Development Services
Kamailio Advanced Training -- asipto.com
### Description
We've got a Kamailio setup on Ubuntu 20.04 with multiple TLS sockets: 5061 for SIPS, 8088 for WSS. When checking the received socket or port in the `onreply_route` for a packet received on the SIPS port, `$Rn`, `$Rn`, and `$Rut` contain information taken from the socket defined first in the configuration file. Swapping the `listen` statements in the attached minimal configuration leads to the respective other set of information being contained in the variables. The issue is reproducable with at least 5.7.0 and 5.7.1.
#### Reproduction
I've attached a (very) stripped down version of our configuration. The outline is as follows:
* Two TLS listen ports: 5061, 8088
* No websockets module – our actual configuration uses it, but it's not necessary to reproduce the issue
* A `request_route` relaying everything to another hardcoded SIP server – I've attached a SIPp scenario for the UAS role
* A `reply_route` printing `$Rp`, `$Rn`, and `$Rut` – at this point the issue has already occured, no further processing is necessary
With the listen directive for the `wss` socket above the directive for the `tls` socket, all inbound packets on port 5061 are logged as being received on the `wss` socket.
In the setup to reproduce the issue, 192.168.100.2 is the kamailio server and 192.168.100.123 is the machine running the UAS on port 5061 and the UAC starting the call.
To reproduce, start Kamailio with the provided configuration file [minimal.cfg](https://github.com/kamailio/kamailio/files/12465577/minimal.tx…. I've used the following command line:
```
/usr/sbin/kamailio -P /tmp/kamailio.pid -f minimal.cfg -E -e -m 512 -M 128 --atexit=no -DD
```
Then, run the SIPp UAS scenario
[uas_tls.xml](https://github.com/kamailio/kamailio/files/12465587/uas_tls.tx… with
```
sipp -sf ~/ucware/sipp/scenarios/uas_tls.xml -trace_msg -trace_err -trace_logs -t l1 -i 192.168.100.123 -p 5061 -m 1
```
Lastly, start a call using the SIPp scenario
[wrong_port_call.xml](https://github.com/kamailio/kamailio/files/12465607/wr… with
```
sipp -sf wrong_port_call.xml -m 1 -trace_msg -trace_err 192.168.100.2:5060
```
### Additional Information
* **Kamailio version**:
```
version: kamailio 5.7.1 (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 9.4.0
```
* **Operating System**:
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
$ uname -a
Linux kamailiotest 5.4.0-159-generic #176-Ubuntu SMP Mon Aug 14 12:04:20 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3553
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3553(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
I am currenlty trying to configure Kamailio to send via HTTP a JSON message to a webserver about an incoming call.
Unfortunatly Kamailio crashes in the process shortly after the build of the JSON message. This is happening every second and third call. I am getting the following error message, when Kamailio is about to crash:
```
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: ERROR: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}jansson [jansson_funcs.c:228]: janssonmod_set(): unrecognized input type
```
I tested this on three VMs with the same behaviour:
- VM with Debian 11 and Kamailio 5.6.
- VM with Debian 11 and Kamailio 5.7.
- VM with Debian 12 and Kamailio 5.7.
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
When I set something like this in the kamailio.cfg, every second or third incoming calls are causing a crash and Kamailio restarts.
```
/* Build the JSON formatted HTTP Requests */
jansson_set("object", "Call", '{"CallType":"$var(CallType)"}', "$var(http_routing_query)");
jansson_set("string", "Call.DeviceId", $var(CallDeviceId), "$var(http_routing_query)");
```
Without the `jansson_set()` I can generate more than 100 concurrent calls without a problem.
#### 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.
-->
```gdb /usr/sbin/kamailio /home/ladmin/core
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/kamailio...
Reading symbols from /usr/lib/debug/.build-id/d7/49ff00b62a1c787a944d88d8b8292aca08ca1d.debug...
warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing
[New LWP 5716]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.cfg'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt full
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
tid = <optimized out>
ret = 0
pd = <optimized out>
old_mask = {__val = {5641075408187236401}}
ret = <optimized out>
#1 0x00007f819c00ad2f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
No locals.
#2 0x00007f819bfbbef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#3 0x00007f819bfa6472 in __GI_abort () at ./stdlib/abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {58, 0, 0, 140194624712704, 140194624715856, 140194624715856, 0, 93892812469232, 140721354859776, 1, 140194638635552, 140721354859776,
93892811155638, 93892812454032, 93892812120108, 140194638259824}}, sa_flags = 532412408, sa_restorer = 0x55651fbc7538 <__func__.1>}
#4 0x000055651f821c80 in qm_free (qmp=<optimized out>, p=<optimized out>, file=<optimized out>, func=<optimized out>, line=<optimized out>, mname=<optimized out>) at core/mem/q_malloc.c:499
qm = <optimized out>
f = <optimized out>
size = <optimized out>
next = <optimized out>
prev = <optimized out>
__func__ = "qm_free"
#5 0x000055651faa72d3 in free_to_params (tb=0x7f819b99fea0) at core/parser/parse_addr_spec.c:918
tp = <optimized out>
foo = 0x7f819b9ed9f0
tp = <optimized out>
foo = <optimized out>
__func__ = "free_to_params"
#6 free_to (tb=0x7f819b99fea0) at core/parser/parse_addr_spec.c:927
__func__ = "free_to"
#7 0x000055651fa901b7 in free_hdr_field_lst (hf=0x7f819b80d8f0) at core/parser/hf.c:216
foo = 0x7f819b80df18
__func__ = "free_hdr_field_lst"
#8 0x000055651fa975c6 in free_sip_msg (msg=msg@entry=0x7f819ba2a220) at core/parser/msg_parser.c:776
No locals.
#9 0x000055651f950d3d in receive_msg (buf=<optimized out>, len=<optimized out>, len@entry=1164, rcv_info=rcv_info@entry=0x7f81964f36a0) at core/receive.c:629
msg = 0x7f819ba2a220
ctx = {rec_lev = 2, run_flags = 0, last_retcode = 532062212, jmp_env = {{__jmpbuf = {140194549282440, 93892810816032, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0, 0, 0, 0, 0, 0, 140194644852349, 0,
5895253961443638784, 4095, 140194549283376, 140194549282440, 140721354861248, 2, 93892812120068, 4294967295}}}}}
bctx = <optimized out>
ret = <optimized out>
tvb = {tv_sec = 0, tv_usec = 0}
tve = {tv_sec = 0, tv_usec = 0}
diff = <optimized out>
inb = {
s = 0x5565204be320 "INVITE sip:+987654321@test-sbc-01.example.com:5060 SIP/2.0\r\nVia: SIP/2.0/TCP 192.168.80.6:5060;branch=z9hG4bK63d05bc5;rport\r\nMax-Forwards: 69\r\nFrom: \"+123456789\" <sip:+123456789@192.168.80.6>;tag=as4929383"..., len = 1164}
netinfo = {data = {s = 0x0, len = 0}, bufsize = 0, rcv = 0x0, dst = 0x0}
keng = <optimized out>
evp = {data = 0x7ffc3e5e6640, obuf = {s = 0x0, len = 0}, rcv = 0x7f81964f36a0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0}
cidlockidx = <optimized out>
cidlockset = <optimized out>
errsipmsg = <optimized out>
exectime = <optimized out>
__func__ = "receive_msg"
--Type <RET> for more, q to quit, c to continue without paging--
#10 0x000055651fa30681 in receive_tcp_msg (
tcpbuf=0x7f81964f3a30 "INVITE sip:+987654321@test-sbc-01.example.com:5060 SIP/2.0\r\nVia: SIP/2.0/TCP 192.168.80.6:5060;branch=z9hG4bK63d05bc5;rport\r\nMax-Forwards: 70\r\nFrom: \"+123456789\" <sip:+123456789@192.168.80.6>;tag=as4929383"..., len=1164, rcv_info=0x7f81964f36a0, con=con@entry=0x7f81964f3688) at core/tcp_read.c:1413
ret = 0
buf = 0x5565204be320 "INVITE sip:+987654321@test-sbc-01.example.com:5060 SIP/2.0\r\nVia: SIP/2.0/TCP 192.168.80.6:5060;branch=z9hG4bK63d05bc5;rport\r\nMax-Forwards: 69\r\nFrom: \"+123456789\" <sip:+123456789@192.168.80.6>;tag=as4929383"...
bsize = 65535
blen = 65535
__func__ = "receive_tcp_msg"
#11 0x000055651fa30b31 in tcp_read_req (con=0x7f81964f3688, bytes_read=bytes_read@entry=0x7ffc3e5e6ab8, read_flags=read_flags@entry=0x7ffc3e5e6ac0) at core/tcp_read.c:1604
bytes = <optimized out>
total_bytes = 1164
resp = 1
size = <optimized out>
req = 0x7f81964f37b0
dst = {send_sock = 0x55651fb6a004, to = {s = {sa_family = 8728, sa_data = "\273\037eU\000\000\340i^>\374\177\000"}, sin = {sin_family = 8728, sin_port = 8123, sin_addr = {s_addr = 21861}, sin_zero = "\340i^>\374\177\000"},
sin6 = {sin6_family = 8728, sin6_port = 8123, sin6_flowinfo = 21861, sin6_addr = {__in6_u = {__u6_addr8 = "\340i^>\374\177\000\000\030\000\000\000\000\000\000", __u6_addr16 = {27104, 15966, 32764, 0, 24, 0, 0, 0},
__u6_addr32 = {1046374880, 32764, 24, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 8728,
__ss_padding = "\273\037eU\000\000\340i^>\374\177\000\000\030", '\000' <repeats 43 times>, "\001 \000\000@\n\243\233\201\177", '\000' <repeats 34 times>, "\310j^>\374\177\000\000\b\000\000\000\000\000\000",
__ss_align = 20}}, id = 1, send_flags = {f = 1, blst_imask = 0}, proto = 10 '\n', proto_pad0 = 0 '\000', proto_pad1 = 0}
c = 0 '\000'
ret = <optimized out>
__func__ = "tcp_read_req"
#12 0x000055651fa346a7 in handle_io (fm=fm@entry=0x7f819ba30a40, events=events@entry=1, idx=idx@entry=-1) at core/tcp_read.c:1855
ret = 458
n = 1164
read_flags = RD_CONN_SHORT_READ
con = 0x7f81964f3688
s = 10
resp = <optimized out>
t = <optimized out>
ee = 0x0
__func__ = "handle_io"
error = <optimized out>
#13 0x000055651fa3a75d in io_wait_loop_epoll (repeat=repeat@entry=0, t=<optimized out>, h=<optimized out>) at core/io_wait.h:1070
n = 1
r = 0
fm = 0x7f819ba30a40
revents = 1
__func__ = "io_wait_loop_epoll"
#14 0x000055651fa3af67 in tcp_receive_loop (unix_sock=<optimized out>) at core/tcp_read.c:1976
__func__ = "tcp_receive_loop"
#15 0x000055651fa245b7 in tcp_init_children (woneinit=woneinit@entry=0x7ffc3e5e6ffc) at core/tcp_main.c:5239
r = 0
i = <optimized out>
reader_fd_1 = 28
pid = <optimized out>
si_desc = "tcp receiver (generic)\000\000\001\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\006\a\235\037eU\000\000\004\240\266\037eU\000\000\2004\273\037eU\000\000\250\022\201\233\201\177\000\000\024", '\000' <repeats 15 times>, "\t\240\266\037eU\000\000\210\342\266\037eU\000\0008\005\000\000\000\000\000\000\004\240\266\037eU\000\000\277.\250\037eU\000"
si = <optimized out>
__func__ = "tcp_init_children"
error = <optimized out>
#16 0x000055651f833d13 in main_loop () at ./src/main.c:1851
i = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--c
pid = <optimized out>
si = <optimized out>
si_desc = "udp receiver child=1 sock=192.168.71.123:5060\000\000\000g\270\267\037eU\000\000\037M\272\037eU\000\000\235d\235d\000\000\000\000,\024\000\234\201\177\000\000\003\000\000\000\000\000\000\000\t\000\000\000\000\000\000\000Thu Jun \000\376\217X>&\320Q:48 2023\002\000\000\000\000\000\000"
nrprocs = <optimized out>
woneinit = 1
__func__ = "main_loop"
error = <optimized out>
#17 0x000055651f8254dc in main (argc=<optimized out>, argv=<optimized out>) at ./src/main.c:3086
cfg_stream = <optimized out>
c = <optimized out>
r = <optimized out>
tmp = 0x7ffc3e5e8e7a ""
tmp_len = 0
port = 0
proto = -1675315600
ahost = 0x0
aport = 0
options = 0x55651fb6ccf0 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:"
ret = -1
seed = 2872567957
rfd = <optimized out>
debug_save = <optimized out>
debug_flag = <optimized out>
dont_fork_cnt = 0
n_lst = <optimized out>
p = <optimized out>
st = {st_dev = 23, st_ino = 1597, st_nlink = 2, st_mode = 16888, st_uid = 111, st_gid = 120, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1688030808, tv_nsec = 298133358},
st_mtim = {tv_sec = 1688030808, tv_nsec = 298133358}, st_ctim = {tv_sec = 1688030808, tv_nsec = 298133358}, __glibc_reserved = {0, 0, 0}}
tbuf = "\000\000\000\000\000\000\000\000p\266$\234\201\177\000\000\r\000\000\000\000\000\000\000\230!\025\234\201\177\000\0000v^>\374\177\000\000\370b\306\037eU\000\000 \360'\234\201\177\000\000\256\317%\234\201\177\000\000\001", '\000' <repeats 15 times>, "x\330$\234\201\177\000\000\3008&\234\201\177\000\000\000\000\000\000\000\000\000\000Pu^>\374\177\000\000\n", '\000' <repeats 15 times>, "0v^>\374\177\000\000\023\361%\234\201\177\000\000\000\000\000\000\000\000\000\000\370b\306\037eU\000\0000v^>\374\177\000\000\000\000\000\000\000\000\000\000\340\002(\234\201\177\000\000\000\000\000\000\000\000\000\000\240\026%\234\201\177\000\000"...
option_index = 12
long_options = {{name = 0x55651fb6b2d3 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x55651fb749ae "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x55651fb841b2 "alias", has_arg = 1, flag = 0x0, val = 1024}, {
name = 0x55651fb6b2d8 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x55651fb6b2de "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x55651fb6b2e7 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {
name = 0x55651fb6b2f1 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x55651fb6b2fb "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x55651fb6b306 "modparam", has_arg = 1, flag = 0x0, val = 1030}, {
name = 0x55651fb6b30f "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x55651fb74acb "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x55651fb6b31a "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {
name = 0x55651fb6b324 "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x55651fb6b32b "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
__func__ = "main"
(gdb) info locals
tid = <optimized out>
ret = 0
pd = <optimized out>
old_mask = {__val = {5641075408187236401}}
ret = <optimized out>
(gdb) list
39 in ./nptl/pthread_kill.c
```
#### 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).
-->
```
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: ######################## INVITE #######################
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: incoming INVITE from +123456789 to +987654321
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route AUTH
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route REQINIT
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route NATDETECT
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route CANCEL
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route RETRANSMISSIONS
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route WITHINDLG
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route RECORD_ROUTE
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route DESTINATION
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route TWILIO_INCOMING
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route AVAYA_OUTGOING
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route HTTP_NOTIFICATION
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: ERROR: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}jansson [jansson_funcs.c:228]: janssonmod_set(): unrecognized input type
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Sending HTTP Request with ID 1234 to http://127.0.0.1:8080/action: {"Version":1,"MessageType":"Incomi
ngCall","Call":{"CallType":"TestCall","DeviceId":"XXXX","Device":{"Id":"2","Name":"XXX"},"Caller":"sip:+123456789@sip.twilio.com","XXXId":"sip:+123456789@sip.twilio.com","Destination":"sip:+987654321@avaya
.example.com;transport=tcp","ForwardedTo":"sip:+987654321@avaya.example.com","UCID":"0123456789","AvGlobalSessionId":"1234-5678-9123-4567"},"Sender":{"Hostname":"test-sbc-01","Location
":"Test"},"Timestamp":"2023-06-28T16:25:22Z"}
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route RELAY
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Branch Route MANAGE_BRANCH
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: new branch [0] to sip:+987654321@avaya.example.com;transport=tcp
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route NATMANAGE
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Entering Sub Route RTPENGINE
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2927]: INFO: {1 1 INVITE bd067878791fbae2f1490dc7a48915c8(a)0.0.0.0}<script>: Managing RTPEngine due to INVITE
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2928]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 8
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2915]: ALERT: <core> [main.c:776]: handle_sigs(): child process 2927 exited by a signal 11
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2915]: ALERT: <core> [main.c:779]: handle_sigs(): core was not generated
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2915]: INFO: <core> [main.c:801]: handle_sigs(): terminating due to SIGCHLD
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2926]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2922]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2925]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2920]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2921]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2918]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2917]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2919]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2916]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2923]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2928]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2924]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received
Jun 28 16:29:48 test-sbc-01 /usr/sbin/kamailio[2915]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized
```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.7.1 (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 12.2.0
```
* **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`)
-->
```
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm
Linux test-sbc-01 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3499
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3499(a)github.com>
warning on alpine dist
```
In file included from kz_amqp.c:32:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
In file included from kz_amqp.c:33:
/usr/include/amqp_framing.h:8:2: warning: #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead. [-Wcpp]
8 | #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead.
| ^~~~~~~
In file included from kz_amqp.c:34:
/usr/include/amqp_tcp_socket.h:7:2: warning: #warning "amqp_tcp_socket.h is deprecated, use rabbitmq-c/tcp_socket.h instead." [-Wcpp]
7 | #warning "amqp_tcp_socket.h is deprecated, use rabbitmq-c/tcp_socket.h instead."
| ^~~~~~~
In file included from kz_amqp.c:35:
/usr/include/amqp_ssl_socket.h:9:2: warning: #warning "amqp_ssl_socket.h is deprecated, use rabbitmq-c/ssl_socket.h instead. [-Wcpp]
9 | #warning "amqp_ssl_socket.h is deprecated, use rabbitmq-c/ssl_socket.h instead.
| ^~~~~~~
In file included from kz_amqp.h:35,
from kazoo.c:36:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
kz_amqp.c: In function 'kz_amqp_connection_open_ssl':
kz_amqp.c:815:13: warning: 'amqp_set_initialize_ssl_library' is deprecated [-Wdeprecated-declarations]
815 | amqp_set_initialize_ssl_library(1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/amqp_ssl_socket.h:11:
/usr/include/rabbitmq-c/ssl_socket.h:233:16: note: declared here
233 | void AMQP_CALL amqp_set_initialize_ssl_library(amqp_boolean_t do_initialize);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC (gcc) [M kazoo.so] kz_fixup.o
CC (gcc) [M kazoo.so] kz_hash.o
In file included from kz_amqp.h:35,
from kz_hash.h:33,
from kz_hash.c:29:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
CC (gcc) [M kazoo.so] kz_json.o
CC (gcc) [M kazoo.so] kz_pua.o
kz_amqp.c: In function 'kz_amqp_send_ex':
kz_amqp.c:2327:12: warning: 'num_headers' may be used uninitialized [-Wmaybe-uninitialized]
2327 | if (num_headers > 0) {
| ^
kz_amqp.c:2281:9: note: 'num_headers' was declared here
2281 | int num_headers = 0;
| ^~~~~~~~~~~
CC (gcc) [M kazoo.so] kz_trans.o
In file included from kz_amqp.h:35,
from kz_trans.c:54:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
make[3]: Entering directory '/usr/src/kamailio/pkg/kamailio/alpine/src/kamailio-95d33167cff13190b51c04b5347df6d419cf2630/src/lib/srdb1'
make[3]: 'libsrdb1.so.1.0' is up to date.
make[3]: Leaving directory '/usr/src/kamailio/pkg/kamailio/alpine/src/kamailio-95d33167cff13190b51c04b5347df6d419cf2630/src/lib/srdb1'
LD (gcc) [M kazoo.so] kazoo.so
make[2]: --libs: No such file or directory
make[2]: --libs: No such file or directory
CC (gcc) [M rabbitmq.so] rabbitmq.o
CC (gcc) [M rabbitmq.so] utils.o
In file included from utils.c:47:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
In file included from utils.c:48:
/usr/include/amqp_framing.h:8:2: warning: #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead. [-Wcpp]
8 | #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead.
| ^~~~~~~
In file included from rabbitmq.c:55:
/usr/include/amqp_tcp_socket.h:7:2: warning: #warning "amqp_tcp_socket.h is deprecated, use rabbitmq-c/tcp_socket.h instead." [-Wcpp]
7 | #warning "amqp_tcp_socket.h is deprecated, use rabbitmq-c/tcp_socket.h instead."
| ^~~~~~~
In file included from rabbitmq.c:56:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
In file included from rabbitmq.c:57:
/usr/include/amqp_framing.h:8:2: warning: #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead. [-Wcpp]
8 | #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead.
| ^~~~~~~
LD (gcc) [M rabbitmq.so] rabbitmq.so
CC (gcc) [M sctp.so] sctp_mod.o
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3464
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3464(a)github.com>
hello ,
I 'm trying to change value "xhttp_prom_timeout" to specific value , for instance 1 minute , to do i set command : modparam("xhttp_prom", "xhttp_prom_timeout", 1) , but it seems metrics is not deleted after 1 minute of not using this metric , only metric is deleted after 10 hours , even i set xhttp_prom_timeoutto 1
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3439
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3439(a)github.com>
### Description
_**Sipwise** hat on_
We noticed that pkg memory was getting exhausted and we found out that pv_cache_add() was the origin of the allocations.
We are using ``$xavp(user_<UUID>)`` variables that, for sure, are kind of dynamic.
There is a pv_cache_drop() that tries to remove ``$sht()`` occurrences when the cache is about to be filled but in our case that's not helping.
#### Log Messages
```
WARNING: ROUTE_SET_CALLEE_DIALOG_TOTAL <core> [core/pvapi.c:340]: pv_cache_add(): pv cache limit is going to be exceeded - pkg memory may get filled with pv declarations
WARNING: dialog:failed <core> [core/pvapi.c:340]: pv_cache_add(): pv cache limit is going to be exceeded - pkg memory may get filled with pv declarations
```
### Possible Solutions
Possible solutions that came on the top of my head:
- add a datetime member to struct _pv_cache so we can keep the last time it was accessed and search for the oldest and remove them in pv_cache_drop()
- add pv module parameter to define a magic prefix, for instance '__' that will mark those vars as "temporal" should remove it from cache when needed.
- add pv module parameter to control what types of variables will be added to cache
Any thoughts about this?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3440
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3440(a)github.com>
### Description
We've been experiencing random Kamailio crashes related to invalid memory access attempts at `0xffff` in `w_save` call, `ims_registrar_scscf_mod.c`:
```
Core was generated by `kamailio -w /home -DD -E -e -f /etc/kamailio/kamailio_scscf.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f5be796c452 in w_save (_m=0x7f5beafa5188, _route=0x7f5beaeab988 " \b\361\352[\177", _d=0x7f5be3bf8200 "", mode=0x7f5beafa5188 "4", _cflags=0xffff <error: Cannot access memory at address 0xffff>)
at ims_registrar_scscf_mod.c:628
```
We are running the latest Kamailio 5.6.4 using the official Docker image.
### Analysis
We were able to analyze corresponding core dump using `gdb` and determine the cause of those random crashes. It turns out that it is related to calling the `save` function of IMS Registrar SCSCF module with 2 arguments.
Example configuration:
```
save("REG_SAR_REPLY", "location");
```
According to documentation, this call is valid, as `mode` and `flags` parameters are optional:
https://kamailio.org/docs/modules/5.6.x/modules/ims_registrar_scscf.html#id…
The `save` function is exported in `ims_registrar_scscf_mod.c` as follows:
```
/*! \brief
* Exported functions
*/
static cmd_export_t cmds[] = {
{"save", (cmd_function) w_save, 2, assign_save_fixup3_async, 0, REQUEST_ROUTE | ONREPLY_ROUTE},
{"save", (cmd_function) w_save, 3, assign_save_fixup3_async, 0, REQUEST_ROUTE | ONREPLY_ROUTE},
{"save", (cmd_function) w_save, 4, save_fixup3, free_uint_fixup, REQUEST_ROUTE | ONREPLY_ROUTE},
...
}
```
And implemented as:
```
/*! \brief
* Wrapper to save(location)
*/
static int w_save(struct sip_msg* _m, char* _route, char* _d, char* mode, char* _cflags) {
if(_cflags){
return save(_m, _d, _route, ((int)(*_cflags)));
}
return save(_m, _d, _route, 0);
}
```
Using the 2-argument `save` variant in configuration effectively causes the `w_save` to be called from `src/core/action.c :: do_action` via a 3-argument function-pointer cast:
```
case MODULE2_T:
MODF_CALL(cmd_function, h, msg, a->val,
(char*)a->val[2].u.data,
(char*)a->val[3].u.data
);
break;
```
Unfortunately, this cast is inherently unsafe - it leaves the `mode` and `_cflags` undetermined. They are probably effectively bound to some memory area beyond the parameter values of the stack frame corresponding to the function call.
Our guess is that incidentally `_cflags == 0x0000` for most of those calls, due to how the stack is structured. But sometimes `_cflags == 0xFFFF` which satisfies the condition in `w_save`, causes `(int)(*_cflags)` dereference attempt and leads to the segmentation fault we've encountered.
### Workaround
Based on source code analysis, we have determined that always using `save` with a full set of arguments (including optional ones) will result in `w_save` being called via a 5-argument function pointer, which matches its signature and avoids the issue.
Example configuration with workaround applied:
```
save("REG_SAR_REPLY", "location", "0", "0");
```
After introducing this workaround on target environment we are no longer experiencing the problem.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3412
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3412(a)github.com>
We had a Kamailio 5.5.4 server crash. There were lots of the following errors repeated over and over in the Kamailio log:
Mar 10 14:59:14 px1 /usr/sbin/kamailio[1375]: WARNING: <core> [core/tcp_read.c:1840]: handle_io(): F_TCPCONN connection marked as bad: 0x7f48e97ecdc8 id 0 fd -1 refcnt 0 ([]:0 -> []:0)
Mar 10 14:59:14 px1 /usr/sbin/kamailio[1375]: CRITICAL: <core> [core/io_wait.h:596]: io_watch_del(): invalid fd -1, not in [0, 2)
And in the syslog it said:
Mar 10 14:59:14 px1 kernel: [731786.728781] kamailio[1363]: segfault at 10 ip 00007f48e6dde42d sp 00007ffc2d23ef00 error 4 in tls.so[7f48e6d9c000+47000]
Mar 10 14:59:14 px1 kernel: [731786.728814] Code: 98 01 5c 24 28 41 29 dd 49 01 84 24 40 01 00 00 c7 44 24 6c 00 00 00 00 85 c9 0f 85 be 08 00 00 49 8b 94 24 90 01 00 00 31
f6 <48> 8b 7a 10 31 d2 e8 38 10 fc ff 85 c0 0f 8e 90 0d 00 00 45 31 db
Is anyone able to advise whether this is a known issue, and if it's fixed in a more recent version? The only related bug report I found was issue #748 which was closed without resolution. Our Kamailio is installed from the Ubuntu 22.04 repository.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3392
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3392(a)github.com>
On Fedora Core when installed Kamailio and then installed additional packages then receive error
```
[root@caloes-1 ~]# journalctl -flu ostree-boot-complete.service -o cat
Starting ostree-boot-complete.service - OSTree Complete Boot...
error: ostree-finalize-staged.service failed on previous boot: During /etc merge: Modified config file newly defaults to directory 'kamailio', cannot merge
ostree-boot-complete.service: Main process exited, code=exited, status=1/FAILURE
ostree-boot-complete.service: Failed with result 'exit-code'.
Failed to start ostree-boot-complete.service - OSTree Complete Boot.
ostree-boot-complete.service - OSTree Complete Boot was skipped because all trigger condition checks failed.
ostree-boot-complete.service - OSTree Complete Boot was skipped because all trigger condition checks failed.
ostree-boot-complete.service - OSTree Complete Boot was skipped because all trigger condition checks failed.
```
Suggestion place default Kamailio config into dedicated package "kamailio-config-default".
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3252
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3252(a)github.com>
### Description
I established a call between two extensions using TLS, and the presence state was replicated between two Kamailio servers using presence_dmq (no database backing). This all worked correctly except when it comes to sending a PUBLISH with a state terminated in the body, the presence_dmq sent the serialized data correctly, but the Kamailio server sends the wrong state and the caller is marked as busy on all subscribed phones until Kamailio is restarted. This occurs on version 5.6.1. In order generate this data, we use a separate script which responds to Asterisk events and sends the right PUBLISH at the right time to Kamailio, eg. if it sees a Hangup event, it sends a PUBLISH with the state in the body set to 'terminated' and the Expires: header set to 0. This appears to prompt Kamailio to send a NOTIFY with a state of early or confirmed to all subscribers.
### Troubleshooting
#### Reproduction
Install two Kamailio servers running Kamailio 5.6.1. I am using this installation command:
`sudo apt install kamailio=5.6.1+bpo9 kamailio-dbg=5.6.1+bpo9 kamailio-lua-modules=5.6.1+bpo9 kamailio-memcached-modules=5.6.1+bpo9 kamailio-mysql-modules=5.6.1+bpo9 kamailio-presence-modules=5.6.1+bpo9 kamailio-redis-modules=5.6.1+bpo9 kamailio-tls-modules=5.6.1+bpo9 kamailio-utils-modules=5.6.1+bpo9`
Some configuration detail for /etc/kamailio/kamailio.cfg:
listen=tls:172.22.0.155:5061
# This ensures we have a UDP socket for sending HEP datagrams (we also send the plaintext UDP PUBLISH here)
listen=udp:172.22.0.155:9060
port=5061
enable_tls=yes
tcp_connection_lifetime=3605
#modules (this is not an exhaustive list)
loadmodule "dmq.so"
loadmodule "dialog.so"
loadmodule "presence.so"
loadmodule "presence_xml.so"
loadmodule "presence_dialoginfo.so"
loadmodule "pua.so"
loadmodule "pua_dialoginfo.so"
loadmodule "tls.so"
modparam("dmq", "server_address", "sip:172.22.0.155:9060")
modparam("dmq", "notification_address", "sip:172.22.1.124:9060")
modparam("dialog", "db_url", DBURL)
modparam("dialog", "enable_stats", 1)
modparam("dialog", "db_mode", 0) # 0 - NO_DB - the memory content is not flushed into DB
modparam("dialog", "dlg_flag", 9)
modparam("dialog", "enable_dmq", 1)
modparam("pua", "db_url", DBURL)
modparam("pua", "db_mode", 0) # high speed memory based storage
modparam("pua", "outbound_proxy", "sips:172.22.0.155:5061;transport=tls")
modparam("pua_dialoginfo", "include_localremote", 0)
modparam("presence", "db_url", DBURL)
modparam("presence", "server_address", "sips:this.host.example.org:5061;transport=tls")
modparam("presence", "db_table_lock_type", 0)
modparam("presence", "subs_db_mode", 0) # 0 - This disables database completely.
modparam("presence", "enable_dmq", 1)
modparam("presence", "publ_cache", 2)
modparam("presence", "subs_remove_match", 1)
modparam("presence", "timeout_rm_subs", 0)
modparam("presence_dialoginfo", "force_dummy_dialog", 1)
modparam("presence_dialoginfo", "force_single_dialog", 1)
modparam("presence_xml", "force_active", 1)
modparam("presence_xml", "force_presence_single_body", 1)
#### Log Messages
These log aren't directly linked but Kamailio reports a 200 OK in response to the PUBLISH, but the NOTIFY to the handset is _not_ terminated. Difficult to capture this because of TLS.
```
Aug 26 13:32:26 this.host.example.org /usr/sbin/kamailio[4187]: DEBUG: presence [presence_dmq.c:467]: pres_dmq_replicate_presentity(): sending serialized data {"action":1,"presentity":{"domain":"sip.prod.example.org","user":"XXXX469","etag":"a.1661495738.4187.2612.0","expires":3600,"recv":1661520746,"event":"dialog"},"t_new":1,"cur_etag":"","ruid":"pres-630869ce-105b-43a","body":"<?xml version=\"1.0\"?>\n<dialog-info xmlns=\"urn:ietf:params:xml:ns:dialog-info\" version=\"0\" state=\"full\" entity=\"sip:XXXX469@sip.prod.example.org\">\n<dialog id=\"c95340dd-5266-450a-8c53-a5cd75c4bb67\" call-id=\"c95340dd-5266-450a-8c53-a5cd75c4bb67\" direction=\"recipient\">\n<state>confirmed</state>\n</dialog>\n</dialog-info>\n"}
Aug 26 13:33:00 this.host.example.org /usr/sbin/kamailio[4187]: DEBUG: presence [presence_dmq.c:467]: pres_dmq_replicate_presentity(): sending serialized data {"action":1,"presentity":{"domain":"sip.prod.example.org","user":"XXXX469","etag":"a.1661495738.4187.2622.0","expires":0,"recv":1661520780,"event":"dialog"},"t_new":1,"cur_etag":"","ruid":"pres-630869ce-105b-e3a","body":"<?xml version=\"1.0\"?>\n<dialog-info xmlns=\"urn:ietf:params:xml:ns:dialog-info\" version=\"0\" state=\"full\" entity=\"sip:XXXX469@sip.prod.example.org\">\n<dialog id=\"c95340dd-5266-450a-8c53-a5cd75c4bb67\" call-id=\"c95340dd-5266-450a-8c53-a5cd75c4bb67\" direction=\"recipient\">\n<state>terminated</state>\n</dialog>\n</dialog-info>\n"}
```
This is a similar example:
```
Sep 1 12:37:14 this.host.example.org /usr/sbin/kamailio[5176]: INFO: presence [notify.c:1738]: send_notify_request(): NOTIFY sip:XXXX475@sip.prod.example.org via ÿÿÿÿÿÿÿÿ on behalf of sip:XXXX472@sip.prod.example.org for event dialog : 2_2191795053(a)172.31.29.18
Sep 1 12:37:14 this.host.example.org /usr/sbin/kamailio[5176]: DEBUG: presence [presence_dmq.c:400]: pres_dmq_replicate_presentity(): replicating presentity record - old etag a.1662035772.5176.17.0, new etag , ruid pres-6310a741-1438-11
Sep 1 12:37:14 this.host.example.org /usr/sbin/kamailio[5176]: DEBUG: presence [presence_dmq.c:467]: pres_dmq_replicate_presentity(): sending serialized data {"action":1,"presentity":{"domain":"sip.prod.example.org","user":"XXXX472","etag":"a.1662035772.5176.17.0","expires":0,"recv":1662035834,"event":"dialog"},"t_new":1,"cur_etag":"","ruid":"pres-6310a741-1438-11","body":"<?xml version=\"1.0\"?>\n<dialog-info xmlns=\"urn:ietf:params:xml:ns:dialog-info\" version=\"0\" state=\"full\" entity=\"sip:XXXX472@sip.prod.example.org\">\n<dialog id=\"76024a0e-2d35-47d8-afd1-a1363acbf859\" call-id=\"76024a0e-2d35-47d8-afd1-a1363acbf859\" direction=\"recipient\">\n<state>terminated</state>\n</dialog>\n</dialog-info>\n"}
Sep 1 12:37:14 this.host.example.org /usr/sbin/kamailio[5176]: DEBUG: presence [presence_dmq.c:149]: pres_dmq_send(): sending dmq broadcast...
```
#### SIP Traffic
```
PUBLISH sip:XXXX469@sip.prod.example.org SIP/2.0
Via: SIP/2.0/UDP this.host.example.org;branch=656ebca4-5e71-4082-984a-7efa54bdd2cc
To: sip:XXXX469@sip.prod.example.org
From: sip:XXXX469@sip.prod.example.org;tag=a06f8d92-609b-4210-a1f0-f7042b871f07
CSeq: 12 PUBLISH
Call-ID: d67c8bb5-f507-4ada-8f98-d7caa6d86721(a)this.host.example.org
Content-Length: 323
User-Agent: Astertisk-Event-Bridge
Max-Forwards: 70
Event: dialog
Expires: 0
Content-Type: application/dialog-info+xml
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:XXXX469@sip.prod.example.org">
<dialog id="9fa5bf3c-63f3-4d3f-82c5-cdff374c4e13" call-id="9fa5bf3c-63f3-4d3f-82c5-cdff374c4e13" direction="recipient">
<state>terminated</state>
</dialog>
</dialog-info>
```
### Possible Solutions
Downgrading to Kamailio version 5.5.4 resolves this problem.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
$ kamailio -v
version: kamailio 5.6.1 (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 6.3.0
$ dpkg -l | egrep '^ii' | grep kamailio | awk '{ print $2, $3 }'
kamailio 5.6.1+bpo9
kamailio-dbg:amd64 5.6.1+bpo9
kamailio-lua-modules:amd64 5.6.1+bpo9
kamailio-memcached-modules:amd64 5.6.1+bpo9
kamailio-mysql-modules:amd64 5.6.1+bpo9
kamailio-presence-modules:amd64 5.6.1+bpo9
kamailio-redis-modules:amd64 5.6.1+bpo9
kamailio-tls-modules:amd64 5.6.1+bpo9
kamailio-utils-modules:amd64 5.6.1+bpo9
```
* **Operating System**:
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.2 (stretch)
Release: 9.2
Codename: stretch
$ uname -a
Linux this.host.example.org 4.9.0-16-amd64 #1 SMP Debian 4.9.272-2 (2021-07-19) x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3229
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3229(a)github.com>
### Description
According to [RFC3261](https://datatracker.ietf.org/doc/html/rfc3261#section-20.14)
> The Content-Length header field indicates the size of the message-
> body, in decimal number of octets, sent to the recipient.
> Applications SHOULD use this field to indicate the size of the
> message-body to be transferred, regardless of the media type of the
> entity. If a stream-based protocol (such as TCP) is used as
> transport, the header field MUST be used.
When UDP protocol is used then this header is optional.
When Kamailio receives an OPTIONS request like in the example, then it floods Kamailio logs with messages like
```
sanity [sanity.c:612]: check_cl(): content length header missing in request
```
OPTIONS message example
```
OPTIONS sip:sbc-0.example.com:5060 SIP/2.0
Via: SIP/2.0/UDP 64.58.61.151:5060;branch=z9hG4bKl7oo3f30a0som61aeu00
Call-ID: 49bc1fcac14b779958dad4b9c43954b400149n2(a)64.58.61.151
To: sip:ping@sbc-0.example.com
From: <sip:ping@64.58.61.151>;tag=8fbe5af9178677655bc3a5388c2a8b8c00149n2
Max-Forwards: 70
CSeq: 299694 OPTIONS
Route: <sip:3.236.25.4:5060;lr>
```
### Expected behavior
Do not generate warnings about SIP messages that are allowed according to RFC.
#### Actual observed behavior
Generated warning when "Content-Length" header missing and used UDP protocol.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3210
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3210(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for feature requests.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If you submit a feature request (or enhancement) add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
I am using STIR/SHAKEN as a third party service and wanted to know if there is a function to copy the Identity header from the 302 response into the original INVITE and then forward it. The Contact header from the 302 will make Kamailio server forward the INVITE to the SBC.
Ideally having one function which does everything in one place would be a nice feature to have.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3214
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3214(a)github.com>
### Description
If the INVITE contains `;ob` but no `;+sip.instance=xxxx;reg-id=N` then a flow-token is not added to the
record-route header. This is contrary to RFC5626.
#### Reproduction
Configure 2 x kamailio according to module outbound; i.e 1 x edge proxy and 1 x internal proxy/registrar.
UA1 and UA2 have already REGISTER'ed with `;+sip.instance=...;reg-id=...`.
```
UA1, UA2 --- edge proxy --- internal proxy
```
Send INVITE from UA1 to UA2 with `;ob` but no other params:
```
Contact: <sip:user1250@192.168.12.45:5063;transport=TLS;ob>
Record-Route: <sip:127.0.0.1;r2=on;lr>
Record-Route: <sip:192.168.13.50:5061;transport=tls;r2=on;lr>
```
Observe that there is no flow-token added.
Send INVITE from UA1 to UA2 with `;ob` with `;+sip.instance=...;reg-id=...`:
```
Contact: <sip:user1200@192.168.122.15;transport=tls;ob>;+sip.instance="<urn:uuid:0000
`0000-0000-0000-0000-0012341234>";reg-id=7
Record-Route: <sip:Jz0HaDIr1ZoqEAPAqA0yE8XAqAwqyAo=@127.0.0.1;r2=on;lr>
Record-Route: <sip:Jz0HaDIr1ZoqEAPAqA0yE8XAqAwqyAo=@192.168.13.50:5061;transport=tls;r2=on;lr>
```
Observe that there is a flow-token added.
#### Debugging Data
#### SIP Traffic
### Possible Solutions
### Additional Information
Version; kamailio 5.6.0
#### RFC5626 Section 9.5
https://datatracker.ietf.org/doc/html/rfc5626#section-9.5
INVITE must contain `ob;` but does not need to contain `;+sip.instance=...;reg-id=...`
```
INVITE sip:alice@a.example SIP/2.0
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp;ob>
```
EP1 adds a Record-Route with a flow-token in message #43.
```
Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3190
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3190(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
dialog module does not update callee tag until it receives a 2xx response to an INVITE.
and so we can not use is_know_dlg() function for in-dialog request like UPDATE when the session is still in early state.
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### 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
<!--
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).
-->
```
(paste your log messages here)
```
#### 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
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
kamailio 5.5.4
```
* **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`)
-->
```
(paste your output here)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3155
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3155(a)github.com>
### Description
If the file loaded with the modparam "load" uses CommonJS modules (Issue #3037-PR #3038), the modules are not reloaded when issuing the command app_jsdt.reload. Only the "main" file is reloaded.
#### Reproduction
1 - Start Kamailio with those files as the initial configuration
```generic
# kamailio.cfg
## Only the part concerning app_jsdt is included.
## The rest of the config file is ommited for the sake of clarity
loadmodule "app_jsdt.so"
modparam("app_jsdt", "load", "/etc/kamailio/js/index.js")
modparam("app_jsdt", "mode", 1)
cfgengine "jsdt"
```
```js
// index.js
var myModule = require('./myModule');
function ksr_request_route() {
myModule.myFunction()
KSR.log("info", "KSR.log called from the index.js file");
}
```
```js
// myModule.js
exports.myFunction = function() {
KSR.log("info", "KSR.log called from the myModule.js file"
}
```
2 - Modify the myModule.js file
```js
// myModule.js
exports.myFunction = function() {
KSR.log("info", "KSR.log called from the MODIFIED myModule.js file"
}
```
3 - Run the reload command
```console
foo@bar:~# kamcmd app_jsdt.reload
{
old: 0
new: 1
}
```
> Log file
>
> INFO: app_jsdt [app_jsdt_api.c:1557]: app_jsdt_rpc_reload(): marking for reload js script file: /etc/kamailio/js/index.js (0 => 0)
> DEBUG: app_jsdt [app_jsdt_api.c:534]: jsdt_kemi_reload_script(): reloading js script file: /etc/kamailio/js/index.js (0 => 1)
4 - The log file still show those lines:
> Log file
>
>INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the myModule.js file
>INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the index.js file
5 - Modify the index.js file
```js
// index.js
var myModule = require('./myModule');
function ksr_request_route() {
myModule.myFunction()
KSR.log("info", "KSR.log called from the MODIFIED index.js file");
}
```
6 - Run the reload command
```console
foo@bar:~# kamcmd app_jsdt.reload
{
old: 1
new: 2
}
```
> Log file
>
> INFO: app_jsdt [app_jsdt_api.c:1557]: app_jsdt_rpc_reload(): marking for reload js script file: /etc/kamailio/js/index.js (0 => 1)
> DEBUG: app_jsdt [app_jsdt_api.c:534]: jsdt_kemi_reload_script(): reloading js script file: /etc/kamailio/js/index.js (1 => 2)
7 - The log file now show those lines:
> Log file
>
> INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the myModule.js file
> INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the MODIFIED index.js file
8 - Restart kamailio completly
9 - The log file now show those lines:
> Log file
>
> INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the MODIFIED myModule.js file
> INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the MODIFIED index.js file
### Possible Solutions
Sorry, I would really like to provide one, but, as I'm a new Kamailio user, I don't know all the internals yet.
### Additional Information
* **Kamailio Version**
```console
foo@bar:~# kamailio -v
version: kamailio 5.6.0 (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 10.2.1
```
* **Operating System**:
```console
foo@bar:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
foo@bar:~# uname -a
Linux localhost 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3145
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3145(a)github.com>
### Description
OPTIONS keepalives sent by usrloc are not being traced with HEP/Homer
### Troubleshooting
#### Reproduction
Module setup:
modparam("siptrace", "duplicate_uri","sip:HOMERIP:9060");
modparam("siptrace", "hep_mode_on",1);
modparam("siptrace", "trace_to_database",0);
modparam("siptrace", "trace_flag",22);
modparam("siptrace", "trace_on", 1);
modparam("siptrace", "hep_version", 3);
modparam("siptrace", "trace_mode", 1)
I believe the above setup should duplicate ALL packets to homer, which is working just fine, except for usrloc-generated OPTIONS.
The 200 OK from endpoints is showing up just fine, just not the initial request.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3136
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3136(a)github.com>
ITNOA
### Description
I think for non-db deployment of Kamailio it is very useful to add support static data (like another configurations) for caller numbers list in user blocklist module. because if we do not have this feature we cannot use this module in non-db deployment of Kamailio.
### Expected behavior
We have a configuration files (like dispatcher file) that contains below information in format of space separated list (like dispatcher file format)
```
+----+----------------+-------------+-----------+-----------+
| id | username | domain | prefix | whitelist |
+----+----------------+-------------+-----------+-----------+
| 23 | 49721123456788 | | 1234 | 0 |
| 22 | 49721123456788 | | 123456788 | 1 |
| 21 | 49721123456789 | | 12345 | 0 |
| 20 | 494675231 | | 499034133 | 1 |
| 19 | 494675231 | test | 499034132 | 0 |
| 18 | 494675453 | test.domain | 49901 | 0 |
| 17 | 494675454 | | 49900 | 0 |
+----+----------------+-------------+-----------+-----------+
```
and user blocklist module read this file and load it, and apply this data for blocking call
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3132
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3132(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
I incremented sess-version w/ value `2147483648` via `$sdp(sess_version) = -1` as well as `$sdp(sess_version) = 2147483648`.
sess-version in SDP should be 2147483649 but is `-1941279658`.
### Troubleshooting
[RFC4566 5.2. Origin ("o=")](https://datatracker.ietf.org/doc/html/rfc4566#section-5.2)
```
<sess-version> is a version number for this session description. Its
usage is up to the creating tool, so long as <sess-version> is
increased when a modification is made to the session data. Again,
it is RECOMMENDED that an NTP format timestamp is used.
```
[Wikipedia NTP Timestamps](https://en.wikipedia.org/wiki/Network_Time_Protocol#Timestamps)
```
The 64-bit binary fixed-point timestamps used by NTP consist of a 32-bit part for seconds and a 32-bit part for fractional second, giving a time scale that rolls over every 232 seconds (136 years) and a theoretical resolution of 2−32 seconds (233 picoseconds). NTP uses an epoch of January 1, 1900. Therefore, the first rollover occurs on February 7, 2036.[28][29]
```
#### Reproduction
Receive SDP w/ sess-version greater equal 2^31 (2147483648) and increase version via `$sdp(sess-version) = -1` or setting a value greater than 2^31.
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### 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).
-->
```
May 02 06:43:20.578496 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} <core> [core/parser/sdp/sdp_helpr_funcs.c:622]: extract_sess_version(): oline(46): >o=user1 53655765 2147483648 IN IP4 127.0.0.1
<
May 02 06:43:20.578501 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} <core> [core/parser/sdp/sdp_helpr_funcs.c:651]: extract_sess_version(): end 10: >2147483648<
May 02 06:43:20.578508 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} <core> [core/parser/sdp/sdp_helpr_funcs.c:506]: extract_mediaip(): located IP address [127.0.0.1] in `o=' field
May 02 06:43:20.578512 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} <core> [core/parser/sdp/sdp_helpr_funcs.c:506]: extract_mediaip(): located IP address [127.0.0.1] in `c=' field
May 02 06:43:20.578532 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:1918]: sdp_get_sess_version(): sdp_session_num 0 sess-version: 2147483648
May 02 06:43:20.578536 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:1923]: sdp_get_sess_version(): sdp_session_num 1
May 02 06:43:20.578576 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:1918]: sdp_get_sess_version(): sdp_session_num 0 sess-version: 2147483648
May 02 06:43:20.578581 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:1923]: sdp_get_sess_version(): sdp_session_num 1
May 02 06:43:20.578695 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:2111]: pv_set_sdp(): res->flags: 24
May 02 06:43:20.578702 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:2112]: pv_set_sdp(): PV_TYPE_INT: 16
May 02 06:43:20.578705 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:2113]: pv_set_sdp(): PV_VAL_INT: 8
May 02 06:43:20.578708 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:2116]: pv_set_sdp(): param.pvn.u.isname.name.n = 1
May 02 06:43:20.578710 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:2125]: pv_set_sdp(): do $sdp(sess_version) = -1941279658
May 02 06:43:20.578713 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:1918]: sdp_get_sess_version(): sdp_session_num 0 sess-version: 2147483648
May 02 06:43:20.578716 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:1923]: sdp_get_sess_version(): sdp_session_num 1
May 02 06:43:20.578750 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:1971]: sdp_set_sess_version(): old_sess_version_num: -2147483648 autoincrement: 0
May 02 06:43:20.578756 debian11 /usr/sbin/kamailio[121163]: DEBUG: {1 2 INVITE 1-121317(a)127.0.0.1} sdpops [sdpops_mod.c:1972]: sdp_set_sess_version(): *new_sess_version_num: -1941279658 autoincrement: 0
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.5.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, 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
```
* **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`)
-->
```
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
Linux debian11 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3099
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3099(a)github.com>
### Description
Hello,
Loading http_async_client module causes kamailio to crash on startup with the following errors:
0(60541) INFO: http_async_client [async_http.c:85]: async_http_init_worker(): started worker process: 1
[warn] kevent: Bad file descriptor
16(60557) CRITICAL: <core> [core/pt.c:405]: fork_tcp_process(): called from a non "main" process
16(60557) ERROR: <core> [core/tcp_main.c:5121]: tcp_init_children(): fork failed: Bad file descriptor
0(60541) ALERT: <core> [main.c:786]: handle_sigs(): child process 60557 exited normally, status=255
0(60541) INFO: <core> [main.c:813]: handle_sigs(): terminating due to SIGCHLD
1(60542) INFO: <core> [main.c:868]: sig_usr(): signal 15 received
5(60546) INFO: <core> [main.c:868]: sig_usr(): signal 15 received
Issue reproduced with kamailio sample configuration + loadmodule "http_async_client.so"
### Additional Information
* **Kamailio Version** *
```
kamailio -v
version: kamailio 5.5.3 (x86_64/darwin) b42dfd
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, 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, select, kqueue.
id: b42dfd
compiled on 22:25:21 Jan 6 2022 with gcc Apple clang version 13.0.0 (clang-1300.0.29.30)
```
* **Operating System**:
```
MacOS
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2999
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/2999(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Similar to [issue #1886](https://github.com/kamailio/kamailio/issues/1886), we have Kamailio receiving WebRTC connections from clients and we see many errors related to connections being forcibly closed.
We see two cases where this occurs, the former of which occurs much more often.
```
Dec 29 01:12:43.909934 tlx-dal-ecv2-staging kamailio_edge[14813]: WARNING: websocket [ws_frame.c:810]: ws_keepalive(): forcibly closing connection
Dec 29 01:12:43.910179 tlx-dal-ecv2-staging kamailio_edge[14813]: ERROR: websocket [ws_conn.c:375]: wsconn_close_now(): getting TCP/TLS connection while trying to close. src_ip:src_port=x.x.x.x:49319, dst_port=443
```
```
Dec 29 00:53:28.110949 tlx-dal-ecv2-staging kamailio_edge[14817]: WARNING: websocket [ws_frame.c:227]: encode_and_send_ws_frame(): TCP/TLS connection get failed
Dec 29 00:53:28.111187 tlx-dal-ecv2-staging kamailio_edge[14817]: ERROR: websocket [ws_frame.c:761]: ping_pong(): sending keepalive. src_ip:src_port=x.x.x.x:46712, dst_port=443
```
### Troubleshooting
There seems to be a common occurrence where the WebSocket keepalive will not receive a pong and close the websocket connection. While closing, we see that the underlying TCP connection has already been closed. While that may be harmless, I am concerned there is a race condition that could lead to other problems.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.3.1 (x86_64/linux) d68f5c
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: d68f5c
compiled on 07:32:16 Dec 29 2021 with gcc 8.3.0
```
* **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`)
-->
```
> lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
> uname -a
Linux tlx-dal-ecv2-staging 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2990
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/2990(a)github.com>
The kafka module use printf-like message to print statistics in rpc_kafka_stats() which doesn't follow the style for other RPC commands that produce data structures parsable as data, like when using jsonrpc.
```
if (rpc->rpl_printf(ctx, "Total messages: %" PRIu64 " Errors: %" PRIu64,
msg_total, msg_error) < 0) {
rpc->fault(ctx, 500, "Internal error showing total statistics");
return;
}
```
I think this is a bug, but easy to fix.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2991
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/2991(a)github.com>
### Description
We are trying to use CNXCC in order to monitor credit usage but it doesn't appear to be working.
The cnxcc_set_max_credit call appears to be working partially as we can see that a new key is created in the Redis DB but with all the values set to 0.
The values that we set in the cnxcc_set_max_credit are hardcoded but it doesn't seem to work.
This is an example of what we find in the Redis DB:
```
1637599472.872820 [1 127.0.0.1:53578] "HEXISTS" "cnxcc:money:pippo@dom.domain.it" "concurrent_calls"
1637599472.872942 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70"
1637599472.873043 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "concurrent_calls" "0"
1637599472.873159 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70"
1637599472.873292 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "consumed_amount" "0.000000"
1637599472.873404 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70"
1637599472.873515 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "ended_calls_consumed_amount" "0.000000"
1637599472.873634 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70"
1637599472.873752 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "max_amount" "0.000000"
1637599472.873875 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70"
1637599472.874000 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "number_of_calls" "0"
1637599472.874115 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70"
1637599472.874269 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "type" "1"
1637599472.874381 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70"
1637599472.874481 [1 127.0.0.1:53578] "SREM" "cnxcc:kill_list:money" "\"pippo(a)dom.domain.it\""
1637599472.874585 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70"
1637599472.874747 [1 127.0.0.1:53578] "HINCRBY" "cnxcc:money:pippo@dom.domain.it" "number_of_calls" "1"
1637599472.874845 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70"
```
This issue is identical to the one described in #1387
### Troubleshooting
#### Reproduction
We are running Kamailio 5.5 from the official repos on Debian 10. All the modules are installed through the repo.
This is the config that we are currently using to set the values for the modules.
We also tried setting the values straight into the function bypassing the variables but the result is the same.
```
$dlg_var(credit) = "50.0";
$var(connect_cost) = "5.0";
$var(cost_per_sec) = "1.0";
$var(i_pulse) = 1;
$var(f_pulse) = 1;
xlog("$dlg_var(label) $var(credit) $var(connect_cost) ");
if (cnxcc_set_max_credit("$dlg_var(label)", "$dlg_var(credit)", "$var(connect_cost)", "$var(cost_per_sec)", "$var(i_pulse) ", "$var(f_pulse)") < 0) {
xlog("Failed to setup credit control");
sl_send_reply("503", "Internal Server Error");
exit;
}
```
#### Log Messages
The call to cnxcc_set_max_credit() doesn't throw any errors and returns 1 as if everything worked correctly
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.5.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_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 8.3.0
```
* **Operating System**:
```
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Linux kamailio 5.11.22-5-pve #1 SMP PVE 5.11.22-10 (Tue, 28 Sep 2021 08:15:41 +0200) 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/2948
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Found following issue when trying to solve #2895 :
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
function kazoo_query (as shown in the module's documentation) causes kamailio to crash.
### Troubleshooting
#### Reproduction
Compile kamailio master-branch from scratch (with module "kazoo" enabled).
Modify kamailio-config with minimal settings required to use function "kazoo_query":
```
diff /usr/local/etc/kamailio/kamailio.cfg.sample /usr/local/etc/kamailio/kamailio.cfg
496a497,501
> loadmodule "kazoo.so"
> modparam("kazoo", "amqp_connection", "amqp://guest:guest@rabbitmqhost:5672")
> modparam("kazoo", "node_hostname", "sipproxy.mydomain.com")
> modparam("kazoo", "pua_mode", 0)
>
517a523,533
> xlog("SCRIPT: Snipppet from kazoo_query-documentation:\n");
> $var(amqp_payload_request) = "{'Event-Category' : 'call_event' , 'Event-Name' : 'query_user_channels_req', 'Realm' : '" + $fd + "', 'Username' : '" + $fU + "', 'Active-Only' : false }";
> kazoo_encode("$ci", "$var(callid_encoded)");
> $var(amqp_routing_key) = "call.status_req.$var(callid_encoded)";
> if(kazoo_query("callevt", $var(amqp_routing_key), $var(amqp_payload_request), "$var(amqp_result)")) {
> kazoo_json("$var(amqp_result)", "Channels[0].switch_url", "$du");
> if($du != $null) {
> xlog("L_INFO", "$ci|log|user channels found redirecting call to $du");
> return;
> }
> }
```
Start kamailio and register. Kamailio crashes when reaching kazoo_query:
```
Nov 6 16:19:37 hostname kamailio: INFO: <core> [core/tcp_main.c:4997]: init_tcp(): using epoll_lt as the io watch method (auto detected)
Nov 6 16:19:37 hostname src/kamailio[352171]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded
Nov 6 16:19:37 hostname src/kamailio[352171]: INFO: rr [rr_mod.c:188]: mod_init(): outbound module not available
Nov 6 16:19:37 hostname src/kamailio[352171]: INFO: <core> [main.c:3035]: main(): processes (at least): 52 - shm size: 67108864 - pkg size: 8388608
Nov 6 16:19:37 hostname src/kamailio[352171]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992
Nov 6 16:19:37 hostname src/kamailio[352171]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984
Nov 6 16:19:37 hostname src/kamailio[352171]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992
Nov 6 16:19:37 hostname src/kamailio[352171]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984
Nov 6 16:19:37 hostname src/kamailio[352171]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992
Nov 6 16:19:37 hostname src/kamailio[352171]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984
Nov 6 16:19:37 hostname src/kamailio[352200]: INFO: jsonrpcs [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/352200
Nov 6 16:19:37 hostname src/kamailio[352202]: INFO: ctl [io_listener.c:213]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config)
Nov 6 16:19:37 hostname src/kamailio[352203]: ERROR: kazoo [kz_amqp.c:2387]: kz_amqp_consumer_event_cfg(): kazoo:consumer-event not found
Nov 6 16:19:42 hostname src/kamailio[352203]: ERROR: kazoo [kz_amqp.c:2387]: kz_amqp_consumer_event_cfg(): kazoo:consumer-event not found
Nov 6 16:19:49 hostname src/kamailio[352213]: ERROR: {1 1 REGISTER OUfeIVS08Xrbmw8Nr-udtg..} <script>: SCRIPT: Snipppet from kazoo_query-documentation:
Nov 6 16:19:49 hostname src/kamailio[352221]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 72
Nov 6 16:19:49 hostname src/kamailio[352171]: ALERT: <core> [main.c:774]: handle_sigs(): child process 352213 exited by a signal 6
Nov 6 16:19:49 hostname src/kamailio[352171]: ALERT: <core> [main.c:777]: handle_sigs(): core was generated
Nov 6 16:19:49 hostname src/kamailio[352171]: INFO: <core> [main.c:799]: handle_sigs(): terminating due to SIGCHLD
Nov 6 16:19:49 hostname src/kamailio[352220]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352218]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352209]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352219]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352201]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352187]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352207]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352205]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352202]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352199]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352195]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352210]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352193]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352196]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352183]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352191]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352176]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352203]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352189]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352192]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352175]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352208]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352185]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352182]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352216]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352190]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352206]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352194]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352177]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352215]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352186]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352173]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352204]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352184]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352188]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352217]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352214]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352180]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352198]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352172]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352221]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352174]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352197]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352200]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352211]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352212]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352181]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352179]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352178]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received
Nov 6 16:19:49 hostname src/kamailio[352171]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized
```
#### 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.
-->
backtrace with gdb shows:
```
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fc47407a859 in __GI_abort () at abort.c:79
#2 0x00007fc47407a729 in __assert_fail_base (fmt=0x7fc474210588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=0x7fc46f0fe2d0 "json_object_get_type(jso) == json_type_object", file=0x7fc46f0fe044 "json_object.c", line=476, function=<optimized out>) at assert.c:92
#3 0x00007fc47408bf36 in __GI___assert_fail (assertion=0x7fc46f0fe2d0 "json_object_get_type(jso) == json_type_object", file=0x7fc46f0fe044 "json_object.c", line=476,
function=0x7fc46f0fe280 "json_object_object_add_ex") at assert.c:101
#4 0x00007fc46f0f7d26 in json_object_object_add_ex () from /lib/x86_64-linux-gnu/libjson-c.so.4
#5 0x00007fc46f14ebe4 in kz_amqp_add_payload_common_properties (json_obj=0x559b3c3b30c0, server_id=0x7ffda57606f0 "kamailio(a)sipproxy.mydomain.com-<352213>-script-0",
unique=0x7ffda5760660) at kz_amqp.c:1023
#6 0x00007fc46f1509a0 in kz_amqp_pipe_send_receive (str_exchange=0x7ffda57609c0, str_routing_key=0x7ffda57609d0, str_payload=0x7ffda57609b0, kz_timeout=0x7ffda57609e0,
json_ret=0x7ffda5760a10) at kz_amqp.c:1159
#7 0x00007fc46f158763 in kz_amqp_query_ex (msg=0x7fc47394beb8, exchange=0x7fc4738f03d0 "(q\216s\304\177", routing_key=0x7fc4738f57c8 "0\213\207s\304\177",
payload=0x7fc4738f58d8 "hX\217s\304\177") at kz_amqp.c:1494
#8 0x00007fc46f1588b2 in kz_amqp_query (msg=0x7fc47394beb8, exchange=0x7fc4738f03d0 "(q\216s\304\177", routing_key=0x7fc4738f57c8 "0\213\207s\304\177",
payload=0x7fc4738f58d8 "hX\217s\304\177", dst=0x7fc4738f04f0 "p\004\217s\304\177") at kz_amqp.c:1517
#9 0x0000559b3b1c7355 in do_action (h=0x7ffda5761370, a=0x7fc4738f1d98, msg=0x7fc47394beb8) at core/action.c:1151
#10 0x0000559b3b1d0463 in run_actions (h=0x7ffda5761370, a=0x7fc4738f1d98, msg=0x7fc47394beb8) at core/action.c:1581
#11 0x0000559b3b1d0bd6 in run_actions_safe (h=0x7ffda5761f70, a=0x7fc4738f1d98, msg=0x7fc47394beb8) at core/action.c:1645
#12 0x0000559b3b16a4b0 in rval_get_int (h=0x7ffda5761f70, msg=0x7fc47394beb8, i=0x7ffda5761750, rv=0x7fc4738f4040, cache=0x0) at core/rvalue.c:949
#13 0x0000559b3b16fa9c in rval_expr_eval_int (h=0x7ffda5761f70, msg=0x7fc47394beb8, res=0x7ffda5761750, rve=0x7fc4738f4038) at core/rvalue.c:1947
#14 0x0000559b3b1c0ec8 in do_action (h=0x7ffda5761f70, a=0x7fc4738f7f28, msg=0x7fc47394beb8) at core/action.c:1052
#15 0x0000559b3b1d0463 in run_actions (h=0x7ffda5761f70, a=0x7fc4738e8ca8, msg=0x7fc47394beb8) at core/action.c:1581
#16 0x0000559b3b1d0ce6 in run_top_route (a=0x7fc4738e8ca8, msg=0x7fc47394beb8, c=0x0) at core/action.c:1666
#17 0x0000559b3b37f932 in receive_msg (
buf=0x559b3c3a0960 "REGISTER sip:10.0.0.24:5060;transport=TCP SIP/2.0\r\nVia: SIP/2.0/TCP 10.0.0.33:47335;branch=z9hG4bK-524287-1---83d016a408b857dd;rport\r\nMax-Forwards: 69\r\nContact: <sip:1234@10.0.0.33:47335;rinstance=837"..., len=578, rcv_info=0x7fc46f4c01a8) at core/receive.c:513
#18 0x0000559b3b41dfb3 in receive_tcp_msg (
tcpbuf=0x7fc46f4c0530 "REGISTER sip:10.0.0.24:5060;transport=TCP SIP/2.0\r\nVia: SIP/2.0/TCP 10.0.0.33:47335;branch=z9hG4bK-524287-1---83d016a408b857dd;rport\r\nMax-Forwards: 70\r\nContact: <sip:1234@10.0.0.33:47335;rinstance=837"..., len=578, rcv_info=0x7fc46f4c01a8, con=0x7fc46f4c0190) at core/tcp_read.c:1424
#19 0x0000559b3b4205f8 in tcp_read_req (con=0x7fc46f4c0190, bytes_read=0x7ffda5762618, read_flags=0x7ffda576261c) at core/tcp_read.c:1607
#20 0x0000559b3b423af5 in handle_io (fm=0x7fc473954a08, events=1, idx=-1) at core/tcp_read.c:1782
#21 0x0000559b3b40eccc in io_wait_loop_epoll (h=0x559b3b6f62e0 <io_w>, t=2, repeat=0) at core/io_wait.h:1070
#22 0x0000559b3b426aa8 in tcp_receive_loop (unix_sock=75) at core/tcp_read.c:1978
#23 0x0000559b3b2a161e in tcp_init_children (woneinit=0x7ffda5762a00) at core/tcp_main.c:5153
#24 0x0000559b3b153f0b in main_loop () at main.c:1843
#25 0x0000559b3b15e745 in main (argc=1, argv=0x7ffda57630e8) at main.c:3058
```
#### 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).
-->
#### 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
This somehow pointed me to the payload - so I tried to change the AMQP-payload in the config to a minimalistic custom JSON document. With this config, the crash does no longer occur:
```
diff /usr/local/etc/kamailio/kamailio.cfg /usr/local/etc/kamailio/kamailio.cfg.sample
497,501d496
< loadmodule "kazoo.so"
< modparam("kazoo", "amqp_connection", "amqp://guest:guest@guest@rabbitmqhost:5672")
< modparam("kazoo", "node_hostname", "sipproxy.mydomain.com")
< modparam("kazoo", "pua_mode", 0)
<
523,533d517
< xlog("SCRIPT: Snipppet from kazoo_query-documentation:\n");
< #$var(amqp_payload_request) = "{'Event-Category' : 'call_event' , 'Event-Name' : 'query_user_channels_req', 'Realm' : '" + $fd + "', 'Username' : '" + $fU + "', 'Active-Only' : false }";
< kazoo_encode("$ci", "$var(callid_encoded)");
< $var(amqp_routing_key) = "call.status_req.$var(callid_encoded)";
< if(kazoo_query("callevt", $var(amqp_routing_key), "{\"blop\":\"example\"}", "$var(amqp_result)")) {
< kazoo_json("$var(amqp_result)", "Channels[0].switch_url", "$du");
< if($du != $null) {
< xlog("L_INFO", "$ci|log|user channels found redirecting call to $du");
< return;
< }
< }
```
So, some issue in the exmaple's payload causes the crash. One the one hand, I think an example from the documentation should somehow work, on the other hand I think that an error in a JSON-payload is not indended to crash kamailio anyway.
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
kamailio -v
version: kamailio 5.6.0-dev2 (x86_64/linux) 63a349
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: 63a349
compiled on 16:12:36 Nov 6 2021 with gcc 9.3.0
```
* **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`)
-->
```
uname -a
Linux hostname 5.11.0-38-generic #42~20.04.1-Ubuntu SMP Tue Sep 28 20:41:07 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal
```
--
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/2922
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Kamailio's ims_usrloc_pcscf module fetches all contact informations from location table at startup.
I noticed that it fails to fetch protocol information. I checked the function which reads the contact row:
https://github.com/kamailio/kamailio/blob/c3629f877500373028d2c7cdefd976cdd…
I saw that it is read the value as INT. Then checked database table and saw that protocol field is CHAR(5).
https://github.com/kamailio/kamailio/blob/master/utils/kamctl/mysql/ims_usr…
```
CREATE TABLE `location` (
...
`protocol` char(5) DEFAULT NULL,
...
);
```
The protocol fields needs to be INT in location table as well.
This bug leads to other bugs because protocol information is used in aor_hash calculation.
Best regards
Erhan Sendag
### Troubleshooting
#### Reproduction
Put a record in location table with protocol value as 1.
Set ims_usrloc_pcscf module parameter db_mode as 1.
After kamailio startup, on debug log, protocol information will be seen as a big integer value.
#### 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
<!--
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).
-->
```
(paste your log messages here)
```
#### 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
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
The protocol fields can be defined as INT in location table.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **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`)
-->
```
(paste your output here)
```
--
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/2871
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Hi, I am a junior with Kamailio, if I show you where I am wrong, I will. Often during a call between two sip clients (located on the same subnet with pcscf) Kamailio P-CSCF crashes with a core dump. But sometimes the call goes through normally, I can’t see why this is happening.
<!--
-->
### Troubleshooting
#### Reproduction
It is reproduced often, the error is most likely somewhere with me.
<!--
-->
#### 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.
-->
```
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/kamailio...
(No debugging symbols found in /usr/sbin/kamailio)
warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing
[New LWP 14196]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xb6f1eab9 in ?? () from /usr/lib/i386-linux-gnu/kamailio/modules/ims_ipsec_pcscf.so
(gdb) bt full
#0 0xb6f1eab9 in ?? () from /usr/lib/i386-linux-gnu/kamailio/modules/ims_ipsec_pcscf.so
No symbol table info available.
#1 0xb6f25b1e in ipsec_forward () from /usr/lib/i386-linux-gnu/kamailio/modules/ims_ipsec_pcscf.so
No symbol table info available.
#2 0xb6f2901a in ?? () from /usr/lib/i386-linux-gnu/kamailio/modules/ims_ipsec_pcscf.so
No symbol table info available.
#3 0x004bc49d in do_action ()
No symbol table info available.
#4 0x004bae10 in run_actions ()
No symbol table info available.
#5 0x004ca3a0 in run_top_route ()
No symbol table info available.
#6 0xb73c1695 in reply_received () from /usr/lib/i386-linux-gnu/kamailio/modules/tm.so
No symbol table info available.
#7 0x0052fa14 in ?? ()
No symbol table info available.
#8 0x005b9170 in receive_msg ()
No symbol table info available.
#9 0x006bb830 in udp_rcv_loop ()
No symbol table info available.
#10 0x004b74e8 in main_loop ()
No symbol table info available.
#11 0x004ab0f1 in main ()
No symbol table info available.
```
#### 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).
-->
```
Dec 10 15:33:07 pcscf /usr/sbin/kamailio[14194]: ERROR: rtpengine [rtpengine.c:2957]: select_rtpp_set(): script error-invalid id_set to be selected
Dec 10 15:33:07 pcscf /usr/sbin/kamailio[14194]: ERROR: rtpengine [rtpengine.c:3236]: set_rtpengine_set_from_avp(): could not locate engine set 2
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14204]: ERROR: <script>: INVITE (sip:bob@ims.mnc001.mcc001.3gppnetwork.org (192.168.56.1:55149) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, dca98f98-8bb9-c01d-ff0c-e55794e9bcaa)
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14204]: ERROR: ims_ipsec_pcscf [cmd.c:806]: ipsec_forward(): Contact doesn't exist
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14204]: ERROR: ims_ipsec_pcscf [cmd.c:806]: ipsec_forward(): Contact doesn't exist
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14193]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14195]: ERROR: <script>: INVITE (sip:bob@ims.mnc001.mcc001.3gppnetwork.org (192.168.56.106:6060) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, dca98f98-8bb9-c01d-ff0c-e55794e9bcaa)
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14195]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14195]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14195]: ERROR: rtpengine [rtpengine.c:2957]: select_rtpp_set(): script error-invalid id_set to be selected
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14195]: ERROR: rtpengine [rtpengine.c:3236]: set_rtpengine_set_from_avp(): could not locate engine set 2
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14205]: ERROR: rtpengine [rtpengine.c:2957]: select_rtpp_set(): script error-invalid id_set to be selected
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14205]: ERROR: rtpengine [rtpengine.c:3236]: set_rtpengine_set_from_avp(): could not locate engine set 2
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14210]: ERROR: ims_ipsec_pcscf [cmd.c:252]: fill_contact(): Reply No contact headers
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14210]: ERROR: ims_ipsec_pcscf [cmd.c:799]: ipsec_forward(): Error filling in contact data
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14201]: ERROR: rtpengine [rtpengine.c:2957]: select_rtpp_set(): script error-invalid id_set to be selected
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14201]: ERROR: rtpengine [rtpengine.c:3236]: set_rtpengine_set_from_avp(): could not locate engine set 2
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14274]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 22
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14191]: ALERT: <core> [main.c:782]: handle_sigs(): child process 14196 exited by a signal 11
Dec 10 15:35:14 pcscf /usr/sbin/kamailio[14191]: ALERT: <core> [main.c:785]: handle_sigs(): core was generated
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14324]: WARNING: <core> [core/daemonize.c:596]: mem_lock_pages(): failed to lock the memory pages (disable swap): Cannot allocate memory [12]
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14324]: ERROR: rtpengine [rtpengine.c:2957]: select_rtpp_set(): script error-invalid id_set to be selected
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14324]: WARNING: tm [tm.c:521]: fixup_routes(): t_on_failure("NATMANAGE"): empty/non existing route
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14324]: ERROR: <script>: event_route[htable:mod-init] {
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14324]: ERROR: ims_ipsec_pcscf [cmd.c:950]: ipsec_destroy(): Contact doesn't exist
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14400]: WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14406]: WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14403]: WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14405]: WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14401]: WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14404]: WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14402]: WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14399]: WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14396]: WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14334]: ERROR: <script>: PRACK (sip:bob@ims.mnc001.mcc001.3gppnetwork.org (192.168.56.1:55149) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, dca98f98-8bb9-c01d-ff0c-e55794e9bcaa)
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14334]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14334]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14337]: ERROR: <script>: PRACK (sip:bob@ims.mnc001.mcc001.3gppnetwork.org (192.168.56.106:6060) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, dca98f98-8bb9-c01d-ff0c-e55794e9bcaa)
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14337]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14337]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14329]: ERROR: <script>: PRACK (sip:bob@ims.mnc001.mcc001.3gppnetwork.org (192.168.56.1:55149) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, dca98f98-8bb9-c01d-ff0c-e55794e9bcaa)
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14329]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14329]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14341]: ERROR: <script>: PRACK (sip:bob@ims.mnc001.mcc001.3gppnetwork.org (192.168.56.106:6060) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, dca98f98-8bb9-c01d-ff0c-e55794e9bcaa)
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14341]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:15 pcscf /usr/sbin/kamailio[14341]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:17 pcscf /usr/sbin/kamailio[14328]: ERROR: <script>: ACK (sip:bob@ims.mnc001.mcc001.3gppnetwork.org (192.168.56.1:55149) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, dca98f98-8bb9-c01d-ff0c-e55794e9bcaa)
Dec 10 15:35:17 pcscf /usr/sbin/kamailio[14328]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:17 pcscf /usr/sbin/kamailio[14328]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:17 pcscf /usr/sbin/kamailio[14326]: ERROR: <script>: ACK (sip:bob@ims.mnc001.mcc001.3gppnetwork.org (192.168.56.106:6060) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, dca98f98-8bb9-c01d-ff0c-e55794e9bcaa)
Dec 10 15:35:17 pcscf /usr/sbin/kamailio[14326]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:17 pcscf /usr/sbin/kamailio[14326]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:26 pcscf /usr/sbin/kamailio[14327]: ERROR: <script>: BYE (sip:bob@ims.mnc001.mcc001.3gppnetwork.org (192.168.56.1:55149) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, dca98f98-8bb9-c01d-ff0c-e55794e9bcaa)
Dec 10 15:35:26 pcscf /usr/sbin/kamailio[14327]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:26 pcscf /usr/sbin/kamailio[14327]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:26 pcscf /usr/sbin/kamailio[14325]: ERROR: <script>: BYE (sip:bob@ims.mnc001.mcc001.3gppnetwork.org (192.168.56.106:6060) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, dca98f98-8bb9-c01d-ff0c-e55794e9bcaa)
Dec 10 15:35:26 pcscf /usr/sbin/kamailio[14325]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:26 pcscf /usr/sbin/kamailio[14325]: ERROR: ims_ipsec_pcscf [cmd.c:816]: ipsec_forward(): No security parameters found in contact
Dec 10 15:35:26 pcscf /usr/sbin/kamailio[14325]: ERROR: rtpengine [rtpengine.c:2957]: select_rtpp_set(): script error-invalid id_set to be selected
Dec 10 15:35:26 pcscf /usr/sbin/kamailio[14325]: ERROR: rtpengine [rtpengine.c:3236]: set_rtpengine_set_from_avp(): could not locate engine set 2
Dec 10 15:35:30 pcscf /usr/sbin/kamailio[14396]: ERROR: <script>: Preloading NAT-PING. Rows: 921
Dec 10 15:35:30 pcscf /usr/sbin/kamailio[14396]: ERROR: <script>: OPTIONS to sip:alice@192.168.56.107:57838;transport=udp via sip:192.168.56.107:57838...
```
#### 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)
```
[pcscf_dump.zip](https://github.com/kamailio/kamailio/files/7692913/pcscf_du…
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.4.4 (i386/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 10.2.1
```
* **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 pcscf.ims.mnc001.mcc001.3gppnetwork.org 5.10.0-9-686-pae #1 SMP Debian 5.10.70-1 (2021-09-30) i686 GNU/Linux
```
[kamailio_cfg.zip](https://github.com/kamailio/kamailio/files/7692905/kamail…
[kamailio_log.zip](https://github.com/kamailio/kamailio/files/7692934/kamail…
--
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/2970
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
ims_registrar_pcscf module create a process with rank 1 (PROC_SIPINIT) if reginfo flag is open..
This is wrong because it is written that PROC_SIPINIT rank should be given only to the first worker process.
```
#define PROC_SIPINIT 1 /**< First (special) SIP worker - some modules do
special processing in this child, like loading db data */
```
This leads to a problem. ims_usrloc_pcscf loads registration records from the db twice.
The codes are demonstrated below.
Similar old issue exists here for another module:
https://github.com/kamailio/kamailio/issues/975
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### 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
<!--
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).
-->
Here are fork operations and their ranks:
```
[root@n5gc-ims-dev src]# cat /usr/src/erhan5.log | grep init_mod_child | grep ims_usrloc_pcscf
0(10662) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 0 rank -127: ims_usrloc_pcscf [main]
1(10671) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 1 rank 1: ims_usrloc_pcscf [udp receiver child=0 sock=10.10.12.101:5060 (172.30.65.101:5060)]
3(10673) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 3 rank 3: ims_usrloc_pcscf [udp receiver child=2 sock=10.10.12.101:5060 (172.30.65.101:5060)]
2(10672) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 2 rank 2: ims_usrloc_pcscf [udp receiver child=1 sock=10.10.12.101:5060 (172.30.65.101:5060)]
5(10675) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 5 rank -1: ims_usrloc_pcscf [slow timer]
0(10662) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 0 rank 0: ims_usrloc_pcscf [main]
6(10679) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 6 rank -1: ims_usrloc_pcscf [timer]
4(10674) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 4 rank 4: ims_usrloc_pcscf [udp receiver child=3 sock=10.10.12.101:5060 (172.30.65.101:5060)]
7(10680) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 7 rank -1: ims_usrloc_pcscf [secondary timer]
8(10686) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 8 rank 1: ims_usrloc_pcscf [RegInfo Event Processor]
9(10687) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 9 rank -1: ims_usrloc_pcscf [Dialog Clean Timer]
10(10688) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 10 rank -2: ims_usrloc_pcscf [ctl handler]
11(10689) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 11 rank 5: ims_usrloc_pcscf [tcp receiver (generic) child=0]
12(10694) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 12 rank 6: ims_usrloc_pcscf [tcp receiver (generic) child=1]
13(10695) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 13 rank 7: ims_usrloc_pcscf [tcp receiver (generic) child=2]
14(10697) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 14 rank 8: ims_usrloc_pcscf [tcp receiver (generic) child=3]
15(10699) DEBUG: <core> [core/sr_module.c:845]: init_mod_child(): idx 15 rank -4: ims_usrloc_pcscf [tcp main process]
```
#### 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
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
In following code ims_registrar_pcscf module create a process with rank 1 (PROC_SIPINIT) :
fork_process(PROC_SIPINIT, "RegInfo Event Processor", 1);
```
static int child_init(int rank)
{
LM_DBG("Initialization of module in child [%d] \n", rank);
if ((subscribe_to_reginfo == 1) && (rank == PROC_MAIN)) {
LM_DBG("Creating RegInfo Event Processor process\n");
int pid = fork_process(PROC_SIPINIT, "RegInfo Event Processor", 1);
if (pid < 0)
return -1; //error
if (pid == 0) {
if (cfg_child_init())
return -1; //error
reginfo_event_process();
}
}
if (rank == PROC_MAIN || rank == PROC_TCP_MAIN)
return 0;
if (rank == 1) {
/* init stats */
//TODO if parameters are modified via cfg framework do i change them?
//update_stat( max_expires_stat, default_registrar_cfg.max_expires ); update_stat( max_contacts_stat, default_registrar_cfg.max_contacts ); update_stat( default_expire_stat, default_registrar_cfg.default_expires );
}
/* don't do anything for main process and TCP manager process */
if (rank == PROC_MAIN || rank == PROC_TCP_MAIN)
return 0;
return 0;
}
```
Here is how ims_usrloc_pcscf loads records from db at its child init callback function:
```
if (_rank==PROC_SIPINIT && db_mode!=DB_ONLY) {
// if cache is used, populate domains from DB
for( ptr=root ; ptr ; ptr=ptr->next) {
LM_DBG("Preloading domain %.*s\n", ptr->name.len, ptr->name.s);
if (preload_udomain(ul_dbh, ptr->d) < 0) {
LM_ERR("child(%d): failed to preload domain '%.*s'\n",
_rank, ptr->name.len, ZSW(ptr->name.s));
return -1;
}
}
}
```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
it exists at latest version on master branch.
[here](https://github.com/kamailio/kamailio/blob/master/src/modules/ims_regi…
```
* **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 `uname -a`)
-->
```
CentOS 7.1
```
--
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/2809
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for feature requests.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If you submit a feature request (or enhancement) add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
It would be nice to have RCD (Rich Call Data) support in STIR/SHAKEN module.
--
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/2780
### Description
I am using Kamailio with Mariadb module
And i am get in Kamailio log some error messages:
```
"ERROR: db_mysql [km_dbase.c:122]: db_mysql_submit_query(): driver error on query: Table 'active_watchers' was not locked with LOCK TABLES (1100)"
"ERROR: db_mysql [km_dbase.c:122]: db_mysql_submit_query(): driver error on query: Table 'active_watchers' was not locked with LOCK TABLES (1100)"
"ERROR: db_mysql [km_dbase.c:122]: db_mysql_submit_query(): driver error on query: Table 'active_watchers' was not locked with LOCK TABLES (1100)"
```
After start debug log queries in Mariadb, i see queries in logfile like this:
```
1141 Query SET autocommit=0
1141 Query LOCK TABLES presentity WRITE
1141 Query update `presentity` set `etag`='a.1620236063.17716.2514.101',`expires`=1625215189,`received_time`=1625214589,`priority`=205144189,`body`='<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<presence xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\" xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\" xmlns:pidfonline=\"http://www.linphone.org/xsds/pidfonline.xsd\" entity=\"sip:name_user@office-dev.com\" xmlns=\"urn:ietf:params:xml:ns:pidf\">\n <tuple id=\"bephbl\">\n <status>\n <basic>open</basic>\n <pidfonline:online/>\n </status>\n <contact priority=\"0.8\">sip:name_user@office-dev.com</contact>\n <timestamp>2021-07-01T17:20:41Z</timestamp>\n </tuple>\n</presence>\n' where `domain`='office-dev.com' AND `username`='name_user' AND `event`='presence' AND `etag`='a.1620236063.17716.2513.100'
1141 Query select `to_user`,`to_domain`,`from_user`,`from_domain`,`watcher_username`,`watcher_domain`,`event_id`,`from_tag`,`to_tag`,`callid`,`local_cseq`,`record_route`,`contact`,`expires`,`reason`,`socket_info`,`local_contact`,`version`,`flags`,`user_agent` from `active_watchers` where `presentity_uri`='sip:name_user@office-dev.com' AND `event`='presence' AND `status`=1 AND `contact`<>''
1141 Query COMMIT
1141 Query SET autocommit=1
1141 Query UNLOCK TABLES
```
or this one
```
1141 Query LOCK TABLES presentity WRITE
1141 Query insert into `presentity` (`domain`,`username`,`event`,`etag`,`sender`,`body`,`received_time`,`priority`,`expires` ) values ('dev.com','+121342','presence','a.1620236063.17716.2532.0','','<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<presence xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\" xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\" xmlns:pidfonline=\"http://www.linphone.org/xsds/pidfonline.xsd\" entity=\"sip:+121342@dev.com\" xmlns=\"urn:ietf:params:xml:ns:pidf\">\n <tuple id=\"wumhh7\">\n <status>\n <basic>open</basic>\n <pidfonline:online/>\n </status>\n <contact priority=\"0.8\">sip:+121342@dev.com</contact>\n <timestamp>2021-07-02T10:55:26Z</timestamp>\n </tuple>\n</presence>\n',1625223329,205152929,1625226929)
1141 Query select `to_user`,`to_domain`,`from_user`,`from_domain`,`watcher_username`,`watcher_domain`,`event_id`,`from_tag`,`to_tag`,`callid`,`local_cseq`,`record_route`,`contact`,`expires`,`reason`,`socket_info`,`local_contact`,`version`,`flags`,`user_agent` from `active_watchers` where `presentity_uri`='sip:+121342@dev.com' AND `event`='presence' AND `status`=1 AND `contact`<>''
1141 Query COMMIT
1141 Query SET autocommit=1
1141 Query UNLOCK TABLES
```
This queries matches for time with reproduced errors in above kamailio log.
#### Reproduction
In test lab
```
MariaDB [kamailio]> LOCK TABLES presentity WRITE;
Query OK, 0 rows affected (0.00 sec)
MariaDB [kamailio]> select * from presentity;
Empty set (0.00 sec)
MariaDB [kamailio]> select * from active_watcher;
ERROR 1100 (HY000): Table 'active_watcher' was not locked with LOCK TABLES
MariaDB [kamailio]>
```
I get same error
Also i am found in additional documentation from Mysql next:
```
A session that requires locks must acquire all the locks that it needs in a single LOCK TABLES statement. While the locks thus obtained are held, the session can access only the locked tables.
```
or from Mariadb docs
```
While a connection holds an explicit lock on a table, it cannot access a non-locked table. If you try, the following error will be produced:
ERROR 1100 (HY000): Table 'tab_name' was not locked with LOCK TABLES
```
### Additional Information
* **Kamailio Version** *
```
Kamailio ver 5.4.5 or 5.6.0
```
So, maybe need add additional lock for table active_watchers or need take out query select from space LOCK - UNLOCK for resolve this issue?
--
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/2805
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for feature requests.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If you submit a feature request (or enhancement) add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Right now there is no way that allows users to control sending register packet using rpc command based on l_uuid .
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Expected behavior
#### Actual observed behavior
#### Debugging Data
```
(paste your debugging data here)
```
#### 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).
-->
```
(paste your log messages here)
```
#### 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
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a improvement.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **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 `uname -a`)
-->
```
(paste your output here)
```
--
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/2766
### Description
I put a dispatcher between PCSCF and UE. When I tried to register, Pcscf's save function saved dispatcher's via IP and via port instead of UE's via IP and via port.
When I checked save function of ims_registrar_pcscf module , I saw that cscf_get_ue_via function is used for that. And It gives wrong via value. Instead of giving last via , it gives the first via in the via list.
Here is the function:
https://github.com/kamailio/kamailio/blob/master/src/lib/ims/ims_getters.c
```
/**
* Looks for the UE Via in First Via header if its a request
* or in the last if its a response and returns its body
* @param msg - the SIP message
* @returns the via of the UE
*/
struct via_body* cscf_get_ue_via(struct sip_msg *msg)
{
struct via_body *vb=0;
if (msg->first_line.type==SIP_REQUEST) vb = cscf_get_first_via(msg,0);
else vb = cscf_get_last_via(msg);
if (!vb) return 0;
if (vb->port == 0) vb->port=5060;
return vb;
}
```
### Troubleshooting
I corrected the code as below:
```
/**
* Looks for the UE Via in Last Via header and returns its body
* @param msg - the SIP message
* @returns the via of the UE
*/
struct via_body* cscf_get_ue_via(struct sip_msg *msg)
{
struct via_body *vb=0;
vb = cscf_get_last_via(msg);
if (!vb) return 0;
if (vb->port == 0) vb->port=5060;
return vb;
}
```
#### Reproduction
Try to put a dispatcher between PCSCF and UE. save function of ims_registrar_pcscf module saves dispatcher's IP and port as UE's IP and port.
#### Debugging Data
```
(paste your debugging data here)
```
#### Log Messages
```
(paste your log messages here)
```
#### 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
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **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`)
-->
```
(paste your output here)
```
--
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/2864
### Description
If I set notifier_processes = 0 then BLF (subscribe/notify) works as expected.
if I set notifier_processes to anything other than 0 then the initial subscribe works fine but when the device Re-Subscribes due to expiry of the timer I see errors in the kamailio log, the subsequent susbcribe fails and BLF no longer works.
### Troubleshooting
#### Reproduction
This issue can be easily reproduced just by setting notifier_processes to 1.
#### 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
```
ERROR: db_postgres [km_dbase.c:480]: db_postgres_query_lock(): transaction not in progress
ERROR: presence [subscribe.c:1708]: get_database_info(): querying subscription dialog
INFO: presence [subscribe.c:1129]: handle_subscribe(): getting stored info
```
#### 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).
-->
```
[11:28:02.095] TX to x.x.x.x:5060:
SUBSCRIBE sip:1005@example.com;transport=udp SIP/2.0
Via: SIP/2.0/UDP y.y.y.y:51761;branch=z9hG4bK271d65c640 661e;rport
Contact: <sip:10004@y.y.y.y:51761>
Max-Forwards: 70
Route: <sip:x.x.x.x;lr>
To: <sip:1005@example.com;transport=udp>
From: <sip:10004@example.com>;tag=602c0c864ab45075
Call-ID: 181910a72dc93418
CSeq: 26762 SUBSCRIBE
User-Agent: polycomVVX-VVX_400-UA/5.8.5.1256
Event: dialog
Accept: application/dialog-info+xml
Expires: 600
Supported:
Content-Length: 0
[11:28:02.184] RX from x.x.x.x:5060:
SIP/2.0 202 OK
Via: SIP/2.0/UDP y.y.y.y:51761;branch=z9hG4bK271d65c640 661e;rport=51761;received=y.y.y.y
To: <sip:1005@example.com;transport=udp>;tag=f055057275da74fa400fb8f3e0bfdfcf-718a1cd7
From: <sip:10004@example.com>;tag=602c0c864ab45075
Call-ID: 181910a72dc93418
CSeq: 26762 SUBSCRIBE
Expires: 600
Contact: <sip:x.x.x.x:5060;transport=udp>
Content-Length: 0
[11:28:02.1 ] RX from x.x.x.x:5060:
NOTIFY sip:10004@y.y.y.y:51761 SIP/2.0
Record-Route: <sip:x.x.x.x;lr=on;ftag=f055057275da74fa400fb8f3e0bfdfcf-718a1cd7>
Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK54.4071b642000000000000000000000000.0
To: <sip:10004@example.com>;tag=602c0c864ab45075
From: <sip:1005@example.com>;tag=f055057275da74fa400fb8f3e0bfdfcf-718a1cd7
CSeq: 1 NOTIFY
Call-ID: 181910a72dc93418
Content-Length: 266
Max-Forwards: 70
Event: dialog
Contact: <sip:x.x.x.x:5060;transport=udp>
Subscription-State: active;expires=600
Content-Type: application/dialog-info+xml
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full" entity="sip:1005@example.com">
<dialog id="615293b33c62dec073e05d9421e9f48b" direction="recipient"> <state>terminated</state> </dialog>
</dialog-info>
[11:28:02.1 ] TX to x.x.x.x:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK54.4071b642000000000000000000000000.0
To: <sip:10004@example.com>;tag=602c0c864ab45075
From: <sip:1005@example.com>;tag=f055057275da74fa400fb8f3e0bfdfcf-718a1cd7
CSeq: 1 NOTIFY
Call-ID: 181910a72dc93418
Server: polycomVVX-VVX_400-UA/5.8.5.1256
Content-Length: 0
...time...time...time...
[11:37:02.190] TX to x.x.x.x:5060:
SUBSCRIBE sip:x.x.x.x:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP y.y.y.y:51761;branch=z9hG4bK496e53396451225a;rport
Contact: <sip:10004@y.y.y.y:51761>
Max-Forwards: 70
To: <sip:1005@example.com;transport=udp>;tag=f055057275da74fa400fb8f3e0bfdfcf-718a1cd7
From: <sip:10004@example.com>;tag=602c0c864ab45075
Call-ID: 181910a72dc93418
CSeq: 26763 SUBSCRIBE
User-Agent: polycomVVX-VVX_400-UA/5.8.5.1256
Event: dialog
Accept: application/dialog-info+xml
Expires: 600
Supported:
Content-Length: 0
[11:37:02.276] RX from x.x.x.x:5060:
SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP y.y.y.y:51761;branch=z9hG4bK496e53396451225a;rport=51761;received=y.y.y.y
To: <sip:1005@example.com;transport=udp>;tag=f055057275da74fa400fb8f3e0bfdfcf-718a1cd7
From: <sip:10004@example.com>;tag=602c0c864ab45075
Call-ID: 181910a72dc93418
CSeq: 26763 SUBSCRIBE
Content-Length: 0
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
kamailio version: 5.5.0 (x86_64/linux) d4c1a1
postgres version: 12.7
```
Presence configuration:
```
modparam("presence_dialoginfo", "force_dummy_dialog", 1)
modparam("presence_dialoginfo", "force_single_dialog", 1)
modparam("presence_xml", "force_dummy_presence", 1)
modparam("presence_xml", "force_active", 1)
modparam("presence_xml", "disable_winfo", 1)
modparam("presence_xml", "disable_bla", 1)
modparam("presence", "subs_db_mode", 3)
modparam("presence", "expires_offset", 0)
modparam("presence", "send_fast_notify", 1)
modparam("presence", "clean_period", 0)
modparam("presence", "db_update_period", 0)
modparam("presence", "publ_cache", 0)
modparam("presence", "min_expires_action", 1)
modparam("presence", "min_expires", 300)
modparam("presence", "max_expires", 3600)
modparam("presence", "sip_uri_match", 1)
modparam("presence", "waitn_time", 1)
modparam("presence", "notifier_processes", 1)
modparam("presence", "db_url", "postgres://kamailio:***********@127.0.0.1/kamailio")
modparam("presence", "xavp_cfg", "pres")
modparam("presence", "local_log_level", 6)
modparam("presence", "startup_mode", 0)
modparam("presence", "force_delete", 1)
modparam("presence", "timeout_rm_subs", 0)
modparam("presence", "cseq_offset", 2)
```
db_postgres configuration:
All defaults just loading the module
```
loadmodule "db_postgres.so"
```
* **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 `uname -a`)
-->
```
Linux ********** 3.10.0-1062.4.3.el7.x86_64 #1 SMP Wed Nov 13 23:58:53 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/2739
### Description
<!--
-->
```
As you can see in the picture, via_host and received_host are different when sending registration data from outside of NAT. However, in the pcscf_unregister function, via_host and received_host are the same value.The pcontact structure in memory could not be found
```
#### 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).
-->
```


```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
```
change the pcscf_unregister function, and add Two parameters
```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.4.4 (x86_64/linux) 8d6c2b
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: 8d6c2b
compiled on 14:04:08 Apr 26 2021 with gcc 4.8.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 `uname -a`)
-->
```
Linux iZhp329ygro5y3v090vnwpZ 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 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/2729
### Description
When LIS server failed, then LIS send message like
```
The error response to the request is an error document. The
following response shows an example error response.
HTTP/1.1 200 OK
Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private
Content-Type: application/held+xml;charset=utf-8
Content-Length: 182
<?xml version="1.0"?>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown">
<message xml:lang="en">Unable to determine location
</message>
</error>
```
Here is HTTP code is 200.
lost_held_dereference now simply check HTTP code and do not check XML body.
Expected XML content check for:
1. XML HELD error message
2. check `findServiceResponse` or `presence` element check like it done for `lost_query`.
This check is important because PIDF-LO object may be added to the multipart body. And HELD XML error handling prevents error message addition as PDF-LO object.
--
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/2724
### Description
As far as I know there is currently no support for [RFC-8760](https://tools.ietf.org/html/rfc8760) yet. It modifies the Digest Access Authentication scheme to add support for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to replace the obsolete MD5 algorithm. Are there any plans to implement this?
### Possible Solutions
Extending the auth module to accept these algorithms as a function parameter would be nice to have since older clients may not support them.
--
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/2668
### Description
TLSF mem manager accounting for wrong values
was trying to debug a crash and this popped up.
using a lot of small allocs until pkg_alloc returns NULL (when exhausted)
when NULL is returned the memory **used+overhead** exceeds the heap allocated.
<!--
-->
### Troubleshooting
#### Reproduction
use frequent small memory allocs until pool is exausted (returns NULL) , check tlsf status.
static void do_test_mem()
{
void* chunk;
tlsf_t pool = NULL;
size_t total = 16 * 1024 * 1024;
size_t half = 8 * 1024 * 1024;
size_t sz = 6;
int x;
void* mem = malloc(total);
char* mem2 = tlsf_cast(char*, tlsf_cast(ptrdiff_t, mem) + half);
memset(mem2, 'X', half);
assert(*mem2 == 'X');
pool = tlsf_create_with_pool(mem, half);
do { chunk = tlsf_malloc(pool, sz); } while(chunk != NULL);
tlsf_status(pool);
for(x=0; x < half; x++) {
assert(*mem2 == 'X');
mem2++;
}
free(mem);
}
<!--
If the issue can be reproduced, describe how it can be done.
-->
<!--
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.
-->
```
heap size= **8388592**
used= **6285144**, used+overhead=**12578696**, free=**18446744073705361512**, fragments=0
max used (+overhead)=12578696, max fragments=1
Free blocks matrix ('.': none, 'X': between 2^X and (2^(X+1)-1) free blocks, X=A..Z, A=0, B=1, ...)
> first-level: 32 block list arrays between 2^fl and 2^(fl+1) bytes (fl=8..39)
v second-level: 32 block lists between 2^fl+sl*2^(fl-5) and 2^fl+(sl+1)*2^(fl-5)-1 bytes (sl=0..31)
0|................................|
1|................................|
2|................................|
3|................................|
4|................................|
5|................................|
6|................................|
7|................................|
8|................................|
9|................................|
10|................................|
11|................................|
12|................................|
13|................................|
14|................................|
15|................................|
16|................................|
17|................................|
18|................................|
19|................................|
20|................................|
21|................................|
22|................................|
23|................................|
24|................................|
25|................................|
26|................................|
27|................................|
28|................................|
29|................................|
30|................................|
31|................................|
```
#### 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).
-->
```
identical to reproduce step when calling mem debug on a running instance
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
```
* **Kamailio Version** - built from master
```
* **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 `uname -a`)
-->
```
CentOS7 and alpine
```
## comments
heap size= **8388592** shouldn't it be **8388608** ?
used+overhead=**12578696** misleading
free=**18446744073705361512** misleading, looks like it has a negative value
the map doesn't look ok (or i'm not understanding what it should show), its the same output before the alloc and after.
--
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/2628
Hello
I configure my kamailio.cfg to handle SLA using (SCA module) and shared presence is working but still facing some issue in case of hold invite and BYE and the reason behind of that issue is following error
Nov 26 07:38:40 SBC-4-1 /usr/local/sbin/kamailio[104107]: ERROR: sca [sca_call_info.c:1008]: sca_call_info_invite_request_handler(): Failed to update sip:4569@test.sip.abcd.com appearance-index 0 to active
actually, in Kamailio appearances, I can see the entry for this call but the index is 1 instead of 0, and Kamailio going to update with a 0 index
[root@SBC-4-1 ntcarfte-kamailio]# kamcmd sca.all_appearances
sip:4569@test.sip.abcd.com 1 active 1606376289 sip:4569@10.xx.xx.xx:5070;transport=udp sip:2003@test.sip.abcd.com 186161_mobile-rel120MTQ5OTcyZjFhMjMyNmI1ZGE1MWY4ODc2M2RkN2VmZmQ 45dc18d8 H6cS9vecZ248B
if I manually update appearances using RPC command with index 1 then the phone started blinking as I change state to held
# kamcmd sca.update_appearance sip:4569@sc4test.sip.teledge.com 1 held
# kamcmd sca.all_appearances
sip:4569@test.sip.abcd.com 1 held 1606376516 sip:4569@10.xx.xx.xx:5070;transport=udp sip:2003@test.sip.abcd.com 186161_mobile-rel120NzE5MDgyZDc1NjJiYjcwMWFlYmI3NzM3NjE2OTRhZjU 08f005cb eK9ratm83g92e
kamailio.cfg
route[SCA] {
if(is_method("SUBSCRIBE")) {
if ($hdr(Event) == "call-info" || $hdr(Event) == "line-seize") {
xlog("L_INFO","(MAIN) :HELLO ($avp(uuid)) : $avp(rsi) $sp $hdr(Event)");
xdbg("SCA: $hdr(Event) SUBSCRIBE $ru from $si:$sp");
sca_handle_subscribe();
exit;
}
return;
}
if (!is_method("BYE|CANCEL|INVITE|PRACK|REFER")) {
return;
}
sca_call_info_update();
}
route[RELAY_OUTBOUND_FS] {
xlog("L_INFO","(RELAY_OUTBOUND_FS) : ($avp(uuid)) : INSIDE ROUTE ");
if (!has_totag()){
$avp(set_h) = 1;
}
t_on_reply("REPLY_OUTBOUND_FS");
route(SCA);
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[RELAY_INBOUND_FS] {
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
$avp(s:puburis_caller) = $fu;
setflag(8);
dlg_manage();
}
if(is_method("REGISTER")) {
t_on_reply("REPLY_REGISTER");
} else {
t_on_reply("REPLY_INBOUND_FS");
}
route(SCA);
if (!t_relay()) {
sl_reply_error();
}
exit;
}
onreply_route[REPLY_INBOUND_FS] {
xdbg("incoming reply\n");
if (status =~ "[456][0-9][0-9]") {
# don't update SCA state here, since there may be
# failure route processing (e.g., call forwarding).
# update state in failure route instead.
return;
}
route(SCA);
}
onreply_route[REPLY_OUTBOUND_FS] {
xdbg("incoming reply\n");
if (status =~ "[456][0-9][0-9]") {
# don't update SCA state here, since there may be
# failure route processing (e.g., call forwarding).
# update state in failure route instead.
return;
}
route(SCA);
}
--
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/2583
With the dialog and acc modules configured to generate CDRs to syslog, sometimes a CDR is not generated when a call ends. It appears that this is because some callers are closing the websocket just after sending the BYE. That means that when the 200 response to the BYE arrives it can't be relayed as the websocket has closed. It does seem to be timing related.
We use the websocket close event to shorten the dialog timeout to 1 second.
We also don't get a CDR if we close the websocket while a call is active. The dialog times out and sends a BYE to the callee (it fails to send to the caller, not because the websocket is closed but because the *.invalid contact address can't be resolved!) and then destroys the dialog.
[kamailio.log](https://github.com/kamailio/kamailio/files/5702715/kamailio.l…
[kamailio-sipdump-2020-12-16--11-13-52.data.log](https://github.com/kamailio…
* **Kamailio Version** - output of `kamailio -v`
version: kamailio 5.3.6 (x86_64/linux) fb26c8
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: fb26c8
compiled on 11:51:56 Nov 17 2020 with gcc 4.8.5
* **Operating System**:
Linux ip-172-30-0-66 4.14.114-83.126.amzn1.x86_64 #1 SMP Tue May 7 02:26:58 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/2587
### Description
When I try to load kamailio schema into MySQL database I get an error "Duplicate entry 'dialog_vars' for key 'PRIMARY'".
I have checked the duplicated `dialog_vars` table definition at
1. [dialog-create.sql#L32-L38](https://github.com/kamailio/kamailio/blob/master…
2. [ims_dialog-create.sql#L41-L49](https://github.com/kamailio/kamailio/blob/ma…
#### Reproduction
Load schemas from dialog-create.sql and from ims_dialog-create.sql.
### Possible Solutions
Remove `dialog_vars` table definition from `ims_dialog-create.sql` shema file.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
@safarov-dell:/usr/share/kamailio$ kamailio -v
version: kamailio 5.5.0-dev3 (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 on 12:51:16 Dec 4 2020 with gcc 10.2.1
```
* **Operating System**:
```
@safarov-dell:/usr/share/kamailio$ cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.13.0_alpha20200917
PRETTY_NAME="Alpine Linux edge"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
```
--
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/2575
Hello I have problem with Kamailio presence,i have configure my kamailio.cfg to handle dialog presence and facing issue in case of subs_db_mode = 2 in case of mode 2 facing following presence issue.
1) after hangup presence is still up
2) sometimes stuck in ringing state
3) sometime presence not came..etc
but in case of subs_db_mode = 3 (DB ONLY) mode presence working fine not facing any issue with this mode.
I noticed that sometimes Kamailio will throw following message during PUBLISH processesing and it will not generate appropriate NOTIFY i also verify in active watcher subscription is thare for that user and also proper entry in dialog table.
MSG during PUBLISH processesing and it will not generate appropriate NOTIFY
Oct 30 07:42:10 NC-HOSTED-1 /usr/local/sbin/kamailio[2409]: DEBUG: presence [notify.c:1444]: publ_notify(): Could not find subs_dialog
kamailio.cfg param
modparam("pua", "db_url", DBURL_KAMAILIO)
modparam("pua", "db_mode", 2)
modparam("pua", "update_period", 100)
modparam("pua", "dlginfo_increase_version", 1)
modparam("pua", "default_expires", 3600)
modparam("pua", "fetch_rows", 1000)
modparam("pua", "outbound_proxy", SERVER_IP)
modparam("dialog", "db_url", DBURL_KAMAILIO )
modparam("dialog", "db_mode", 1)
modparam("dialog", "db_update_period", 260)
modparam("dialog", "db_fetch_rows", 500)
modparam("pua_dialoginfo", "include_callid", 1)
modparam("pua_dialoginfo", "send_publish_flag", 8)
modparam("pua_dialoginfo", "caller_confirmed", 0)
modparam("pua_dialoginfo", "include_tags", 1)
modparam("pua_dialoginfo", "use_pubruri_avps", 1)
modparam("pua_dialoginfo", "include_localremote", 1)
modparam("pua_dialoginfo", "override_lifetime", 300)
modparam("pua_dialoginfo", "pubruri_caller_avp", "$avp(s:puburis_caller)")
modparam("pua_dialoginfo", "pubruri_caller_dlg_var", "pubruri_caller")
modparam("pua_dialoginfo", "pubruri_callee_dlg_var", "pubruri_callee")
modparam("pua_dialoginfo", "pubruri_callee_avp", "$avp(s:puburis_callee)")
modparam("presence_dialoginfo", "force_single_dialog", 1)
modparam("presence", "db_table_lock_type", 0)
modparam("presence", "db_url", DBURL_KAMAILIO)
modparam("presence", "db_update_period", 5)
modparam("presence", "send_fast_notify", 1)
modparam("presence", "clean_period", 100)
modparam("presence", "subs_db_mode", 2)
//modparam("presence", "subs_db_mode", 3)
modparam("presence", "timeout_rm_subs", 1) //new/
//modparam("presence", "notifier_processes", 2) //new//
modparam("presence", "notifier_poll_rate", 20) //new//
modparam("presence", "waitn_time",1)
modparam("presence", "fetch_rows", 1000)
modparam("presence", "presentity_table", "presentity")
modparam("presence", "active_watchers_table", "active_watchers")
modparam("presence", "watchers_table", "watchers")
modparam("presence", "max_expires", 3600)
modparam("presence_xml", "db_url", DBURL_KAMAILIO)
modparam("presence_xml", "force_active", 1)
logic for presence
request_route {
if(is_method("PUBLISH") || is_method("SUBSCRIBE")) {
route(HANDLE_PRESENCE);
}
}
route[HANDLE_PRESENCE] {
if (! t_newtran())
{
sl_reply_error();
exit;
}
if(is_method("PUBLISH"))
{
handle_publish();
t_release();
} else if( is_method("SUBSCRIBE")) {
handle_subscribe();
t_release();
}
exit;
}
route[RELAY] {
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
$avp(t_ext) = $tU ;
$avp(domain) = $fd ;
$avp(et) = $_s(sip:$avp(t_ext)@$avp(domain)) ;
$avp(s:puburis_callee) = $avp(et);
setflag(8);
dlg_manage();
}
}
--
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/2540
### Description
Apparently the remapping of 503 to 500 codes in the tm module does also change the to-tag. This behaviour breaks dialogs with yate and therefore calls hang and the 503 remains unacknowledged.
Removing to-tags seems to contradict RFC3261
"12 Dialogs
A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag **and a remote tag**…"
Due to the bug the UA cannot identify the dialog the 500 belongs to. Therefore the dialog remains open and Kamailio keeps repeating 500 messages.
### Troubleshooting
After disabling the 503 to 500 remapping with modparam("tm", "remap_503_500", 0) dialogs get properly terminated .
#### Reproduction
503 to 500 remapping is enabled by default. Inspect the to tags of the incoming 503 and outgoing 500 messages.
#### Debugging Data
Henning added this comment:
Apparently, this is the way the code works:
t_reply.c:
if (relayed_code==503 && tm_remap_503_500){
/* replace a final 503 with a 500:
* generate a "FAKE" reply and a new to_tag (for easier
* debugging)*/
### Possible Solutions
Dont change the to-tag
### Additional Information
kamailio -v
version: kamailio 5.2.3 (x86_64/linux) c36229
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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: c36229
compiled on 10:34:54 Jun 13 2019 with gcc 4.8.5
* **Operating System**:
CentOS Linux release 7.6.1810 (Core)
3.10.0-957.12.2.el7.x86_64
--
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/2405
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for feature requests.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If you submit a feature request (or enhancement) add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Am using Kamailio 5.1.9 version, In my tls.cfg i have one client and server profile,
along with default client and server profile.
I have crl enabled for the non default client and server profile , the crl file size is 4 MB in my case.
I have 22 child tcp process.
With this what i observe is load_crl is taking close to 90 seconds to finish its execution and return.
### Expected behavior
load_Crl function should not take 90 seconds to complete its execution.
probably it should take in the range of 10-15 seconds to complete its execution or even lesser.
#### Actual observed behavior
load_Crl function is taking 90 seconds to complete its execution.
#### Debugging Data
It is very clear from the code, its because of this for loop.
time taken to complete load_Crl execution is 90 seconds
procs_no=get_max_procs();
for(i = 0; i < procs_no; i++) {
if (SSL_CTX_load_verify_locations(d->ctx[i], d->crl_file.s, 0) != 1) {
ERR("%s: Unable to load certificate revocation list '%s'\n",
tls_domain_str(d), d->crl_file.s);
TLS_ERR("load_crl:");
return -1;
}
store = SSL_CTX_get_cert_store(d->ctx[i]);
X509_STORE_set_flags(store,
X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL);
}
Is there a way this can be enhanced or as per the current kamailio design this is a must to do for each and every profile and its ssl context array list for each process and for every profile.
The same logic is seen in other load functions as well, for example load_cert,
load_ca_list,
load_crl,
set_cipher_list,
set_verification,
set_ssl_options,
set_session_cache,
ksr_tls_fix_domain,
#### 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).
-->
```
(paste your log messages here)
```
#### 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
Reply from Henning Westerholt on posting this problem to Users Mailing list
"But the code could be probably also improved, maybe it is possible to parallelize it. You can open a feature request about it,"
### Additional Information
Kamailio 5.1.9 version
* **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 `uname -a`)
-->
```
Linux Kernel version : 3.10.0-693.el7.x86_64
Centos version : CentOS Linux release 7.4.1708 (Core)
CPU : 2 cores with model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
[root@miv5000 ~]# cat /proc/meminfo
MemTotal: 3882076 kB
MemFree: 811244 kB
MemAvailable: 2320356 kB
Openssl verison : OpenSSL 1.0.2k-fips 26 Jan 2017
```
--
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/2312
### Description
Explain what you did, what you expected to happen, and what actually happened.
I'm looking at using presence module with **subs_db_mode** parameter set to 0-2 where it uses memory to store and query active watchers. I noticed that sometimes Kamailio will throw following message during PUBLISH processesing and it will not generate appropriate NOTIFY for watchers:
`DEBUG: presence [notify.c:1234]: publ_notify(): Could not find subs_dialog `
RPC command to dump current active watchers will be helpful during troubleshooting. Currently with **subs_db_mode** set to 0 you can not tell for sure if subsciption already expired or not. And with **subs_db_mode** set to 1 or 2 you can get information from DB with delay. This command will also allow to clarify subscriber _domain_ value which if I understood correctly must match domain from presentity.
Thanks a lot!
--
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/2188
Some times ims_charging module not sending ccr terminate request to Diameter Server upon receiving the BYE Request .
**ISSUE Description:**
1 ) Consider User A registered with kamailio.
2 ) A called PSTN number ..Initial CCR request went to diameter server successfully.
3 ) PSTN number hangup the call....Here After BYE Transaction is done...Kamailio is generating a new BYE request to itself and it is retransmitting it four times.
4 ) I think this is the reason Ims_cahrging not generating ccr terminate request.
**Please find below sip traces. [Proxy is : 7080 , gateway : 5060]**
BYE sip:+xxxxxxxxxxxx@xxxxxxxxxxxx:35465 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxxx:5060;branch=z9hG4bK05c0a4d6
Route: <sip:xxxxxxxxxxxx:7080;lr;transport=UDP;did=492.d7f1>
Max-Forwards: 70
From: <sip:xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=as4ab1ab4b
To: "+xxxxxxxxxxxx" <sip:+xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=8110a0S32NHgp
Call-ID: 8fa995a0-061c-11ea-8d83-00505697042b
CSeq: 102 BYE
User-Agent: SM SoftSwitch 11-06C13
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP xxxxxxxxxxxx:5060;rport=5060;branch=z9hG4bK05c0a4d6
From: <sip:xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=as4ab1ab4b
To: "+xxxxxxxxxxxx" <sip:+xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=8110a0S32NHgp
Call-ID: 8fa995a0-061c-11ea-8d83-00505697042b
CSeq: 102 BYE
User-Agent: Janus WebRTC Gateway SIP Plugin 0.0.6
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, UPDATE
Content-Length: 0
BYE sip:xxxxxxxxxxxx:7080;lr;transport=UDP;did=492.d7f1 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxxx:7080;branch=z9hG4bK461c.5003522650d9dbb33e47c6d83d7465b8.1
Via: SIP/2.0/UDP xxxxxxxxxxxx:5060;rport=5060;branch=z9hG4bK05c0a4d6
Max-Forwards: 69
From: <sip:xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=as4ab1ab4b
To: "+xxxxxxxxxxxx" <sip:+xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=8110a0S32NHgp
Call-ID: 8fa995a0-061c-11ea-8d83-00505697042b
CSeq: 102 BYE
User-Agent: SM SoftSwitch 11-06C13
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0
BYE sip:xxxxxxxxxxxx:7080;lr;transport=UDP;did=492.d7f1 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxxx:7080;branch=z9hG4bK461c.5003522650d9dbb33e47c6d83d7465b8.1
Via: SIP/2.0/UDP xxxxxxxxxxxx:5060;rport=5060;branch=z9hG4bK05c0a4d6
Max-Forwards: 69
From: <sip:xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=as4ab1ab4b
To: "+xxxxxxxxxxxx" <sip:+xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=8110a0S32NHgp
Call-ID: 8fa995a0-061c-11ea-8d83-00505697042b
CSeq: 102 BYE
User-Agent: SM SoftSwitch 11-06C13
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0
BYE sip:xxxxxxxxxxxx:7080;lr;transport=UDP;did=492.d7f1 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxxx:7080;branch=z9hG4bK461c.5003522650d9dbb33e47c6d83d7465b8.1
Via: SIP/2.0/UDP xxxxxxxxxxxx:5060;rport=5060;branch=z9hG4bK05c0a4d6
Max-Forwards: 69
From: <sip:xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=as4ab1ab4b
To: "+xxxxxxxxxxxx" <sip:+xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=8110a0S32NHgp
Call-ID: 8fa995a0-061c-11ea-8d83-00505697042b
CSeq: 102 BYE
User-Agent: SM SoftSwitch 11-06C13
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0
BYE sip:xxxxxxxxxxxx:7080;lr;transport=UDP;did=492.d7f1 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxxx:7080;branch=z9hG4bK461c.5003522650d9dbb33e47c6d83d7465b8.1
Via: SIP/2.0/UDP xxxxxxxxxxxx:5060;rport=5060;branch=z9hG4bK05c0a4d6
Max-Forwards: 69
From: <sip:xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=as4ab1ab4b
To: "+xxxxxxxxxxxx" <sip:+xxxxxxxxxxxx@xxxxxxxxxxxx>;tag=8110a0S32NHgp
Call-ID: 8fa995a0-061c-11ea-8d83-00505697042b
CSeq: 102 BYE
User-Agent: SM SoftSwitch 11-06C13
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0
--
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/2129
Dialog and DMQ in db_mode 2 - dialog_vars entries created and not deleted.
Szenario: two proxies in DMQ synchronization with additional database. Configuration identical on both machines:
```
root@proxy-1:/etc/kamailio# grep dialog kamailio.cfg
loadmodule "dialog.so"
modparam("dialog", "db_mode", 2)
modparam("dialog", "db_update_period", 10)
modparam("dialog", "enable_dmq", 1)
modparam("dialog", "default_timeout", 60);
modparam("dialog", "send_bye", 1)
```
Call is placed on proxy1. Proxy1 handles the call, and synchronize the dialog data to proxy2. Proxy2 is able to list the dialog with kamcmd dlg.list etc..
Proxy2 will not write the dialog into dialog table, but will write the dialog variables to the dialog_var table:
```
root@proxy-2:/etc/kamailio# mysql kamailio
MariaDB [kamailio]> select * from dialog; select * from dialog_vars;
Empty set (0.00 sec)
+----+------------+---------+-------------+---------------------------------+
| id | hash_entry | hash_id | dialog_key | dialog_value |
+----+------------+---------+-------------+---------------------------------+
| 9 | 3479 | 1648 | _uac_fu | sip:customer-1@sip.XXXX.net |
| 10 | 3479 | 1648 | _uac_funew | sip:batman@XXX.org |
| 11 | 3479 | 1648 | _uac_fdp | |
| 12 | 3479 | 1648 | _uac_fdpnew | |
| 13 | 3479 | 1648 | _uac_to | sip:customer-2@sip.skalatan.net |
| 14 | 3479 | 1648 | _uac_tonew | sip:robin@XXX.org |
| 15 | 3479 | 1648 | _uac_tdp | |
| 16 | 3479 | 1648 | _uac_tdpnew | |
+----+------------+---------+-------------+---------------------------------+
8 rows in set (0.00 sec)
```
Because of this the dialog_vars will grow for every call.
In db_mode 1 this dialog_vars entries (and also dialog entries) are not written.
I suggest to adapt db_mode 2 with DMQ to the same behaviour.
--
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/2093
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Kemi API xlog doesn't support log_facility configuration for xlog kemi api function
-->
### Troubleshooting
kamailio native config: -
xlog("LOG_LOCAL2", "L_INFO", "REQUEST: transaction_id=$avp(tid);timestamp=$Ts;method=$rm;source_ip=$si;source_port=$sp;from_user=$fU;from_domain=$fd;to_user=$tU;to_domain=$td;request_user=$oU;request_domain=$od;");
python kemi config
KSR.xlog.xlog( "LOG_LOCAL2", "L_INFO", "REQUEST: timestamp=$Ts;method=$rm;source_ip=$si;source_port=$sp;from_user=$fU;from_domain=$fd;to_user=$tU;to_domain=$td;request_user=$oU;request_domain=$od;")
produced following errors: -
ERROR: app_python [python_support.c:150]: python_handle_exception(): python_exec2: Unhandled exception in the Python code:#012TypeError: kemi-param-ss() takes exactly 2 arguments (3 given)
#### 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.
-->
```
N-A
```
#### 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).
-->
```
N-A
```
#### 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).
-->
```
N-A
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.1.8 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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: unknown
compiled with gcc 6.3.0
```
Debian 9.5
<!--
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 `uname -a`)
-->
```
Linux routing-proxy-01 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) 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/2064
Hi Kamailio team,
I'm attempting to use Kamailio as a Diameter Routing Agent, but I can't seem to get the diameter_request() function to actually _send_ the diameter request, instead I get a warning about no JSON Response:
> WARNING: ims_diameter_server [avp_helper.c:341]: addAVPsfromJSON(): No JSON Response
Even when relaying received data without modifying it.
I posted this issue on the mailing list but have had no responses. Since then I've run a bunch more tests on a few different versions of Kamailio with a few different Diameter peers with the same result.
### Description
The IMS Diameter Server Module's[ diameter_request() function](https://www.kamailio.org/docs/modules/devel/modules/ims_diameter_… fails to send, reporting "No JSON Response" even when fed unmodified received data into it.
### Troubleshooting
Initially I was trying to use CDP & IMS Diameter Server Module to create & send Diameter messages, I thought my formatting in the message (the Diameter Message (as JSON)) was incorrect. as I was getting:
> WARNING: ims_diameter_server [avp_helper.c:341]: addAVPsfromJSON(): No JSON Response
When trying to send the request.
To rule out my JSON formatting being the issue I configured two Diameter Peers in Kamailio:
>From one Diameter peer, I sent a Diameter request to Kamailio.
Kamailio is configured to receive the Diameter request, and without modifying the message body ($diameter_request), put that message into the message of the the diameter_request() so as to rule out formatting errors in the message, just a relay of the message, but this also fails to send.
I also included a series of checks to confirm the peer to receive the relayed message was online and capable of handling the specified Diameter application, all of which passed.
I've defined the peers in the diametercfg.xml config file, and they're all showing as online when I do a "kamcmd cdp.list_peers":
FQDN: ims-hss.localdomain
Details: {
State: I_Open
Disabled: False
Last used: 0
Applications: {
appid:vendorid: 16777216:10415
appid:vendorid: 16777216:4491
appid:vendorid: 16777216:13019
appid:vendorid: 16777216:0
appid:vendorid: 16777217:10415
appid:vendorid: 16777221:10415
}
}
Here's a simplified version of my event_route[diameter:request], showing I simply receive the diameter request and then try to send it straight back out using the diameter_request() function:
```
event_route[diameter:request]{
xlog("Got diameter message");
diameter_request("ims-hss.localdomain", $diameter_application, $diameter_command, $diameter_request);
xlog("Forwarded Diameter Request");
}
```
When tailing syslog I see the "Got diameter message" entry but not the "Forwarded Diameter Request", which suggests it's not getting past the diameter_request(), instead I just see the:
> WARNING: ims_diameter_server [avp_helper.c:341]: addAVPsfromJSON(): No JSON Response
Packet captures show Kamailio receives the request but never relays it.
The source of avp_helper.c shows the warning is called if the length of the JSON is <= 0, but as I'm feeding back out what I've received it shouldn't be 0, an no recent major changes to the source, so I'm stumped as to why it's catching this.
I've attached a full copy of the config files below.
#### Reproduction
I've tried this with a few different Diameter servers, but I can reproduce it with two FreeDIAMETER peers configured in Diameter CDP Config XML, I've also tried with one Kamailio CDP based peer and using xhttp to call the diameter_request() function with the same results.
#### Log Messages
Copy of relevant SysLog:
https://pastebin.com/ZY8z2kd4
### Additional Information
Full Kamailio Config: https://pastebin.com/afgqUfWr
Diameter CDP Config XML: https://pastebin.com/bVrBG8mG
Relevant Syslog: https://pastebin.com/ZY8z2kd4
Kamcmd cdp.list_peers: https://pastebin.com/cKi4JAHC
Kamailio 5.1.2 on Ubuntu 18.04 installed from Repos.
--
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/2035
I'm observing the following scenario:
* mod_dialog callbacks trigger 2 or more times (nearly) simultaneously for the same dialog
* pua_dialoginfo sends PUBLISH 1, referencing etag A
* pua_dialoginfo sends PUBLISH 2, referencing etag A
* presence_dialoginfo processes PUBLISH 1, replies with new etag B
* presence_dialoginfo processes PUBLISH 2, replies with a 412 (because etag A no longer exists)
* pua_dialoginfo receives the 412 and re-tries it as PUBLISH 3 ("sent a PUBLISH within a dialog that no longer exists, send again an intial PUBLISH")
* presence_dialoginfo processes PUBLISH 3, and may or may not accept it
The situation as described is not ideal since it'll fill up your logs with errors, but isn't critical per se. Much more problematic is when there are more than 2 PUBLISHes generated for the same dialog simultaneously, as this can cause a (near) infinite race between the various PUBLISH requests all fighting to update the same etag. For example, 10 PUBLISH are sent out for etag A; all but one are rejected with a 412; then the other 9 keep on bouncing back and forth between pua_dialoginfo and presence_dialoginfo because they do not share the same view on the dialog's latest etag.
Even worse is when presence_dialoginfo is rejecting *all* incoming PUBLISHes with a 412, for example because of a database/memory/replication problem or a malformed request. A `t_reply("412", "Not today")` in the presence_dialoginfo server, combined with a single PUBLISH from pua_dialoginfo is enough to reproducibly brick the pua_dialoginfo server because it runs into critical memory fragmentation levels.
I think there are multiple ways to fix or alleviate this problem.
## pua generic
* pua (publ_cback_func) should not retry 412-failed PUBLISHes indefinitely, but e.g. at most once
* pua should not generate simultaneous PUBLISHes for the same presentity. It should delay PUBLISH 2 until PUBLISH 1 is either (permanently) accepted or rejected; or it should discard PUBLISH 2 immediately when it is generated.
* Perhaps make handling of 412 replies more fine-grained. Currently every 412 reply is handled like this ("sent a PUBLISH within a dialog that no longer exists"), while that statement doesn't apply to all possible 412 replies.
## pua_dialoginfo specific
* pua_dialoginfo currently subscribes to a lot of mod_dialog callbacks. For example subscribing to both DLGCB_CONFIRMED and DLGCB_CONFIRMED_NA will always get you two (rapidly succeeding) PUBLISHes with exactly the same contents. Subscribing to DLGCB_REQ_WITHIN means you'll get a new PUBLISH for every re-INVITE such as hold/unhold or codec negotiation, which is useless in many usecases. It would be helpful to allow configuring pua_dialoginfo with a list of callbacks to subscribe to.
* With or without a smaller set of mod_dialog callbacks, pua_dialoginfo can generate multiple PUBLISH requests with exactly the same contents. Since pua is aware of the (last) state that it published for the presentity, it could compare if the newly generated PUBLISH is any different from the last known state, and discard it if it's not.
--
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/2048
**Description**
Recently we have upgraded to **kamailio 5.3** version and we are performing load tests on it for scalability but Unfortunately it is **crashed** while performing in **ims_dialog** module.
we are using **ims_dialog** module instead of **dialog** module for **diameter** protocol purpose.
**Troubleshooting**
We found out that **dlg_out** is **NULL** but we are accessing the **dlg_out->to_tag.len** this leads to the crash..But unfortunately we don't know how this gets **NULL** as **dlg_out** is assigned to **d_entry_out->first** which is **NOT NULL**
**GDB messages:**
(gdb)
#0 0x00007fbe5a646ea6 in next_state_dlg (dlg=0x7fbe57dcf268, event=3, old_state=0x7ffc8b03f0a0, new_state=0x7ffc8b03f0a4,
unref=0x7ffc8b03f09c, to_tag=0x7ffc8b03f080) at dlg_hash.c:1180
#1 0x00007fbe5a622170 in dlg_onreply (t=0x7fbe57f7a3f0, type=1048576, param=0x7ffc8b03f2f0) at dlg_handlers.c:1276
#2 0x00007fbe5e2b5517 in run_trans_callbacks_internal (cb_lst=0x7fbe57f7a468, type=1048576, trans=0x7fbe57f7a3f0,
params=0x7ffc8b03f2f0) at t_hooks.c:254
#3 0x00007fbe5e2b5733 in run_trans_callbacks_with_buf (type=1048576, rbuf=0x7fbe57f7a4c0, req=0x7fbe57f7bab0,
repl=0x7fbe5fa1d218, flags=0) at t_hooks.c:297
#4 0x00007fbe5e2fc05f in relay_reply (t=0x7fbe57f7a3f0, p_msg=0x7fbe5fa1d218, branch=1, msg_status=183,
cancel_data=0x7ffc8b03f760, do_put_on_wait=1) at t_reply.c:1986
#5 0x00007fbe5e300ec3 in reply_received (p_msg=0x7fbe5fa1d218) at t_reply.c:2540
#6 0x00000000004b6f43 in do_forward_reply (msg=0x7fbe5fa1d218, mode=0) at core/forward.c:745
#7 0x00000000004b8a8f in forward_reply (msg=0x7fbe5fa1d218) at core/forward.c:846
#8 0x00000000005527c7 in receive_msg (
buf=0xb3b740 "SIP/2.0 183 Session Progress\r\nVia: SIP/2.0/UDP 182.72.244.91:5060;branch=z9hG4bK7fea.85af5c92096548bdd857481789b3e50f.1, SIP/2.0/UDP 182.72.244.91:5080;received=182.72.244.91;rport=5080;branch=z9hG4bK"..., len=613, rcv_info=0x7ffc8b040000)
at core/receive.c:510
#9 0x0000000000675077 in udp_rcv_loop () at core/udp_server.c:548
#10 0x0000000000425f4b in main_loop () at main.c:1673
#11 0x000000000042e52a in main (argc=13, argv=0x7ffc8b040808) at main.c:2802
*******************************************************************************
(gdb) f 0
#0 0x00007fbe5a646ea6 in next_state_dlg (dlg=0x7fbe57dcf268, event=3, old_state=0x7ffc8b03f0a0, new_state=0x7ffc8b03f0a4,
unref=0x7ffc8b03f09c, to_tag=0x7ffc8b03f080) at dlg_hash.c:1180
1180 if (dlg_out->to_tag.len == to_tag->len && memcmp(dlg_out->to_tag.s, to_tag->s, dlg_out->to_tag.len) == 0) {
(gdb) info locals
d_entry = 0x7fbe57d5ab70
d_entry_out = 0x7fbe57dcf378
dlg_out = 0x0
found = -1
delete = 1
__FUNCTION__ = "next_state_dlg"
(gdb) p d_entry_out->first
$10 = (struct dlg_cell_out *) 0x7fbe57fcf6b8
**Additional Information**
**version**: kamailio 5.3.2 (x86_64/linux)
Thanks in Advance...I am beginning to work with kamailio ....can you guys please give me some hints how to move forward with this..
--
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/2221
### Description
The `kamctl` tool seems to require `bash`, while trying to use `/bin/sh`, which can point to `dash` or other shell interpreters.
For example, the output of `kamdbctl create`:
```
MySQL password for root:
-e \E[37;33mINFO: creating database kamailio_simple_db ...
-e \E[37;33mINFO: granting privileges to database kamailio_simple_db ...
-e \E[37;33mINFO: creating standard tables into kamailio_simple_db ...
-e \E[37;33mINFO: Core Kamailio tables succesfully created.
Install presence related tables? (y/n): n
/usr/sbin/kamdbctl: 216: /usr/sbin/kamdbctl: Bad substitution
```
It seems that the issue is expanding the variable when getting the answer for y/n question:
* https://github.com/kamailio/kamailio/blob/master/utils/kamctl/kamdbctl.base…
Such expression seems to be specific for bash:
* https://mywiki.wooledge.org/Bashism
### Troubleshooting
#### Reproduction
Run `kamctl` with `/bin/sh` pointing to `bash`.
### Possible Solutions
Decide what to do to have an acceptable solution: enforce `bash`, remove bashisms`...
Or maybe focus to make `kamcli` a (full) replacement for `kamctl/kamdbctl` and get rid of those old-style shell/bash scripts:
* https://github.com/kamailio/kamcli
--
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/2019
### Description
If an EVAPI client drops dead and silently closes its TCP connection, EVAPI is not notified in an acceptable time frame. The default OS TCP keep-alive parameters are generally far too long to be effective, and there is no way to override these using module or runtime configuration. Moreover, any attempts to put in a workaround is thwarted by the inability to close an arbitrary EVAPI connection from say, a timer event (since there is no way to specify a connection to close outside the EVAPI context).
### Expected behavior
When an EVAPI client goes dead, the connection should be closed in the order of seconds (ideally configurable). The EVAPI should allow connections to be closed via scripting from any context.
#### Actual observed behavior
When an EVAPI client goes dead, the connection stays open (counting towards the maximum number of allowed clients). When the evapi_close is invoked from other contexts, nothing happens.
#### Debugging Data
#### Log Messages
#### SIP Traffic
### Possible Solutions
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.2.1 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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: unknown
compiled with gcc 6.3.0
```
* **Operating System**:
Debian GNU/Linux 9 (stretch)
```
Linux 3b83b180f7c9 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 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/1880
>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902944
> Hi!
>
> We've got several local kamailio modules, and it would be nice to be
> able to build them separately and not have to hook them into the
> kamailio source and build systems. I suppose others might find this
> useful too.
>
> I started pondering what adding support for this would imply, and I
> think the first step is whether this is something you think upstream
> and you'd be happy supporting? It could be that the internal interfaces
> are completely unstable and providing this might be a support nightmare,
> for example, or other similar concerns.
>
> I think what would be needed is:
>
> - Support installing the library .so symlinks into the -dev package.
> (The module .so I think would need to stay in the main and module
> packages, because some stuff loads them as module.so directly?)
> - Support installing the kamailio core, library and module .h files
> into the -dev package. AFAIUI modules can have inter-module
> dependencies and they might use interfaces from both kamailio core
> itself, the shared libraries or other modules.
> - Provide a pkg-config file with the necessary compile and link runes
> (-I, -L, -rpath and similar) to be able to build 3rd party modules
> easily.
>
> While checking this, I noticed there's a src/lib/Makefile.defs, which
> has a TYPE variable to install headers and similar, but it does not
> appear to be currently used?
>
> Thanks,
> Guillem
--
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/1752
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for feature requests.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If you submit a feature request (or enhancement) add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Expected behavior
#### Actual observed behavior
#### Debugging Data
```
(paste your debugging data here)
```
#### 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).
-->
```
(paste your log messages here)
```
#### 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
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a improvement.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **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 `uname -a`)
-->
```
(paste your output here)
```
--
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/1878
### Description
During kamailio packaging on OpenSUSE in log exist this warnings
```
[ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/acc_diameter.so
[ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/auth_diameter.so
[ 860s] kamailio-json.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/jsonrpcc.so
[ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/pdb.so
[ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/siputils.so
[ 860s] kamailio-xmpp.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/xmpp.so
[ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/sbin/kamailio
[ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/sbin/kamcmd
[ 860s] The binary calls gethostbyname(). Please port the code to use getaddrinfo().
```
Could you `port the code to use getaddrinfo()`.
--
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/1714
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests.
If you have questions about using Kamailio or related to its configuration file,
ask on sr-users mailing list:
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing
C code, ask on sr-dev mailing list
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the
developers to troubleshoot the issue.
If you submit a feature request (or enhancement), you can delete the text of
the template and only add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Kamailio frequently terminates tls connections to sip clients, if db_mongodb database driver is used and one mongodb cluster member becomes unavailable.
If one mongodb secondary is shutdown (or the primary and a promotion takes place) kamailio will terminate the tls connection to a sip-client (sends a FIN/ACK) after a short period of time (differs 20s to 180s). If a sip client reconnects, registration will succeed (so mongodb access is fine) but kamailio will terminate the tls connection shortly after.
This situation happens as well if only the connection between kamailio and a secondary is blocked (the cluster members can still communicate with each other).
I assume that the mongo-c's server discovery might be the culprit. Mongoc iteratively tries to connect to all servers in the mongoc-uri to update their status (`mongodb://mongodb-cluster2:27017,mongodb-cluster1:27017,mongodb-cluster0:27017/kamailio?authMechanism=MONGODB-X509&replicaSet=rs1&ssl=true&sslcertificateauthorityfile=mongo.ca&sslclientcertificatekeyfile=mongo.certkey`).
Nonethless, mongoc's server discovery should be transparent to the kamailio client as long as a primary exists (and this is the case). No reason to terminate tls client connections.
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
1. Setup a mongodb cluster with 3 members.
2. Setup kamailio with tls using db-mongodb via tls.
Note: The mongodb-uri must contain all three members, e.g. `mongodb://mongodb-cluster2:27017,mongodb-cluster1:27017,mongodb-cluster0:27017/kamailio?ssl=true`)
3. Connect/register a sip client via tls.
4. Stop one member.
5. Clients will receive a ready error on its tls connection.
#### 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).
-->
The db_mongodb kamailio logs don't reveal any errors. Operations are normal. The only thing which is shown in the logs is TLS read:error. As seen below.
```
Jul 23 14:22:09 bda3e8fce481 /usr/local/sbin/kamailio[318]: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS read:error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
Jul 23 14:22:09 bda3e8fce481 /usr/local/sbin/kamailio[318]: ERROR: <core> [core/tcp_read.c:1485]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7fa9b6343210 r: 0x7fa9b6343290
```
A wireshark trace reveals that kamailio closes the tcp connection (FIN/ACK). The client receives a "stream truncated".
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 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 on 13:39:15 Jul 23 2018 with gcc 6.3.0
```
* **mongoc-version**
```
mongoc-1.11.0 (built with cmake ../ -DENABLE_AUTOMATIC_INIT_AND_CLEANUP=OFF)
```
* **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 `uname -a`)
-->
```
Debian 9.5 docker image running on CentOS 7 (kernel 3.10.0-514.6.1.el7.x86_64)
```
--
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/1599
>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886111
```
Source: kamailio
Version: 5.1.0-1
Severity: wishlist
Hi,
I noticed from the build log on mips64el a lot of warnings like this:
> In file included from ../../core/parser/../mem/../atomic/atomic_native.h:50:0,
> from ../../core/parser/../mem/../futexlock.h:42,
> from ../../core/parser/../mem/../lock_ops.h:75,
> from ../../core/parser/../mem/shm.h:39,
> from ../../core/parser/../mem/shm_mem.h:34,
> from ../../core/parser/../ut.h:45,
> from ../../core/parser/../ip_addr.h:39,
> from ../../core/parser/msg_parser.h:37,
> from app_sqlang_api.h:28,
> from app_sqlang_kemi_export.c:32:
> ../../core/parser/../mem/../atomic/atomic_mips2.h:41:2: warning: #warning mips64 atomic code was not tested, please report problems to serdev(a)iptel.org or andrei(a)iptel.org [-Wcpp]
> #warning mips64 atomic code was not tested, please report problems to \
> ^~~~~~~
If possible, kamailio should use the standard c atomic code from
stdatomic.h instead of providing assembly routines. This will improve
maintainability and architecture support.
Thanks,
James
```
--
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/1430
### Description
When using the t_reuse_branch() function after a branch failure, Kamailio doesn't send out the call again if $du was filled and differed from $ru. Instead, Kamailio tries to send the call directly to $ru.
I would expect that the call gets sent out the same way as the original call.
### Troubleshooting
#### Reproduction
You need a setup like this:
UAC1 K(LB) <=> K(Proxy/Registrar) <=> K(LB) => UAC2
When a UAC registers, the Path module is used to save the LB (Loadbalancer) for outbound calls. When UAC1 calls UAC2, the original call gets sent through K(LB) to UAC2. However, if the first call gets rejected and the call gets retried through branch failure route, K(Proxy/Registrar) tries to send the call directly to the request URI.
In your branch_route add a reference to a branch failure route:
```t_on_branch_failure("samplename");```
Then add a branch failure route like this:
```event_route[tm:branch-failure:handle_tls_branch] {
if(t_check_status("488")) {
if (isbflagset(0) && !isbflagset(1)) {
t_reuse_branch();
setbflag(1);
t_relay();
}
}
}```
When filling $du manually before sending out the call again, everything works.
### Possible Solutions
The original destination URI should be copied to the reused branch.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 4.4.5 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 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 4.7.2
```
But from what I see in source code, the devel version still copies the same value.
* **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 `uname -a`)
-->
```
Debian Wheezy
```
--
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/1264
Regarding the issue 1274 (https://github.com/kamailio/kamailio/issues/1274) there's a problem in highly scalable environments to avoid conflicts in storing dialogs in the same DB.
As @miconda pointed out:
> The internal id is made from two integers, hash entry and hash id (h_entry, h_id). h_entry is the index of the slot in the hash table used to store the dialog structure, computed by hashing over call id. h_id is an incremented integer specific for each hash table slot.
>
> So, when loading a new record from database, if its h_id is not conflicting with an existing dialog on the same hash table slot, all is ok, otherwise the module is not going to work properly with two dialogs having same h_id.
>
> So, when loading a new record from database, if its h_id is not conflicting with an existing dialog on the same hash table slot, all is ok, otherwise the module is not going to work properly with two dialogs having same h_id.
>
> Among solutions I thought of:
>
> 1. have the servers generating non conflicting h_id, by having a start value different per server and an increment step larger than the number of servers. Iirc, here was at some point a similar attempt, but somehow didn't make it. Let's say one has two servers, first server starts allocating h_id from 1 and increments by 2 (e.g: 1, 3, 5, ...) and the seconds start from 2 and increments with 2 (2, 4, 6, ...). Those values can be set via mod params, eventually with an option to rely on server_id.
> This should be the least intrusive in the other modules built on top of dialog. But it is rather rigid, with the example above, if one adds an extra server, it needs to reconfigure the old ones, so each server starts from either 1, 2 or 3 and increment by 3. Of course, one can set increment step to a larger value, like 100, and then has flexibility to deploy up to 1 hundred servers before having to reconfigure in case there is need for more server.
>
> 2. add server_id as the third field in the dialog id. It will require review of other modules using dialog and eventual code updates in those modules. One column to store the server_id needs to be added to dialog db tables.
>
> 3. switch from this conflicting id system to something like string unique ids, similar to what we have in usrloc records. This will require coding in other modules, changes to database schema, etc., so more work comparing with the above two, but could be the best in long term.
It would be great to have the option 3 developed if possible but we would also be satisfied with the option 2 to have a third field, server_id, in the dialog id.
Thank You!
--
Alex
--
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/1500
When K connects to another SIP proxy over TCP or TLS, the connection is shared for all requests to that destination. If the receiving SIP proxy is K, it means that only one worker process is handling all those requests. This may become a bottleneck if processing of requests is time consuming, e.g., because of DB operations.
It should therefore be possible one way or another to establish more than one parallel TCP or TLS connections to the same destination. One solution could be based on a function call, such as t_forward_connect(number), to be called before t_relay specifying the desired number of parallel connections shared randomly by outgoing requests.
--
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/1107
There are lots of module parameters that are not documented in the README file:
"amqp_timmer_process_interval"
"amqp_consumer_ack_timeout_micro"
"amqp_consumer_ack_timeout_sec"
"amqp_interprocess_timeout_micro"
"amqp_interprocess_timeout_sec"
"amqp_waitframe_timeout_micro"
"amqp_waitframe_timeout_sec"
"amqp_consumer_workers"
"amqp_query_timeout_micro"
"amqp_query_timeout_sec"
"pua_include_entity"
"json_escape_char"
"app_name"
"use_federated_exchange"
"federated_exchange"
"amqp_heartbeats"
"amqp_primary_zone"
"amqp_command_hashtable_size"
"amqp_result_avp"
"amqps_ca_cert"
"amqps_cert"
"amqps_key"
"amqps_verify_peer"
"amqps_verify_hostname"
Also, the follwing functions are not documented:
"kazoo_json_keys"
"kazoo_async_query"
--
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/976
Hello,
I'm testing kamailio with a SIP client with presence support, when I get a connection drop from a client (i.e when the client lost the access to the Internet connection) I do not receive the change in the status to offline immediately, I just received when the timeout from the presentity database finishes.
I know that I'm able to change the expiry parameter from the presentity table, but that increases my battery consumption and the data exchange, the same happens if I reduce the publish interval on the client side.
The connection with the server are connected with the TLS or TCP.
@miconda Suggested that a solution could be:
"For TCP/TLS, what can work, it's to use tcpops module which can execute an event route when a tcp/tls connection is dropped. If you track the association of connection id with the call-id of the presence publish, then you may be able to do some tricks and lower the expires of the published presence state. I haven't had the time to see what's possible there, but could worth investing.
An alternative would be to enhance presence module to behave as registrar/usrloc (which can delete contact records on connection drop) to expire documents when tcp/tls connection is closed (not sure if anyone already added it)."
--
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/915
From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843477
> From: Ondřej Surý <ondrej(a)debian.org>
> To: Debian Bug Tracking System <submit(a)bugs.debian.org>
> Subject: src:kamailio: stop using libval-dev for DNSSEC validation
>
> Package: src:kamailio
> Version: 4.4.3-2
> Severity: serious
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Dear maintainer,
>
> please stop using libdnsval-dev for DNSSEC validation. src:dnsval
> is very poorly upstream maintained (SVN repository, issue tracker,
> mailing list are non-functional) and I am going to schedule it for
> removal for stretch.
>
> In a long term you should migrated to better and maintained library
> (preferrably getdns or just libunbound), but now please just drop
> it.
>
> Cheers,
> Ondrej
>
> - -- System Information:
> Debian Release: 8.6
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.2.0-41-generic (SMP w/24 CPU cores)
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> -----BEGIN PGP SIGNATURE-----
So I'm going to remove **dnssec** module from the official Debian package
--
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/851
Hi,
When using dialog module and track_cseq_updates when needing to update CSeq for authenticated invites, if early media is present the CSeq in the Rack header is not also incremented.
Kamailio version:
version: kamailio 4.4.2 (x86_64/linux) 892ad6
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 892ad6
compiled on 11:18:36 Sep 28 2016 with gcc 5.4.0
--
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/801
Sipwise hat ON:
We have more than one server and we need to keep things in db in order to share sca subscription/appearance between servers
--
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/781
<!--
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 -->
- [x] PR should be backported to stable branches
- [ ] Tested changes locally
#### Description
From https://github.com/kamailio/kamailio/pull/3569
After initial subscription by the SCA device, if we power off and on again, we won't get an unsubscribe notification and we are getting a new record-route with sca-subscription. In this case kamailio not updating the new record-route for the SCA Device.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3571
-- Commit Summary --
* sca: update rr if necessary for subscriptions
-- File Changes --
M src/modules/sca/sca_subscribe.c (11)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3571.patchhttps://github.com/kamailio/kamailio/pull/3571.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3571
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3571(a)github.com>
Module: kamailio
Branch: master
Commit: 145659f9b81a0d489548fa8a0f75c0bd05660e2e
URL: https://github.com/kamailio/kamailio/commit/145659f9b81a0d489548fa8a0f75c0b…
Author: Victor Seva <linuxmaniac(a)torreviejawireless.org>
Committer: Victor Seva <linuxmaniac(a)torreviejawireless.org>
Date: 2023-11-22T14:50:21+01:00
github: set ``expired`` label when closing PR or issues automatically [skip ci]
---
Modified: .github/workflows/issue_management.yml
---
Diff: https://github.com/kamailio/kamailio/commit/145659f9b81a0d489548fa8a0f75c0b…
Patch: https://github.com/kamailio/kamailio/commit/145659f9b81a0d489548fa8a0f75c0b…
---
diff --git a/.github/workflows/issue_management.yml b/.github/workflows/issue_management.yml
index 063df358c62..0d0b2ef9aa5 100644
--- a/.github/workflows/issue_management.yml
+++ b/.github/workflows/issue_management.yml
@@ -17,6 +17,8 @@ jobs:
stale-pr-message: 'This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.'
days-before-stale: 42
days-before-close: 14
+ close-issue-label: expired
+ close-pr-label: expired
exempt-issue-labels: bug
remove-stale-when-updated: true
operations-per-run: 500
<!-- 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
- [ ] Tested changes locally
- [X] Related to issue #3570
#### Description
<!-- Describe your changes in detail -->
Added optional AoR argument to ipsec_destroy(); to permit insertion of a real AoR from a cfg script. Otherwise, ipsec_destroy() uses the dummy AoR you(a)kamailio.org. The dummy AoR does not identify the IPSec SA of any UE present in the registrar, so no IPSec SA can be torn down.
The real AoR, if present as an argument to ipsec_destroy() replaces the dummy AoR in m->first_line.u.request.uri.s, before calling fill_contact() (see changes to cmd.c / cmd.h).
All other changes address ims_ipsec_pcscf_mod.c only, as required to implement the ipsec_destroy() optional argument.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3645
-- Commit Summary --
* Add AoR argument to ims_ipsec_pcscf ipsec_destroy()
-- File Changes --
M src/modules/ims_ipsec_pcscf/cmd.c (8)
M src/modules/ims_ipsec_pcscf/cmd.h (2)
M src/modules/ims_ipsec_pcscf/ims_ipsec_pcscf_mod.c (52)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3645.patchhttps://github.com/kamailio/kamailio/pull/3645.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3645
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3645(a)github.com>
Module: kamailio
Branch: master
Commit: e59c4415707f0995a0d5315b5601ae518b4f1ed5
URL: https://github.com/kamailio/kamailio/commit/e59c4415707f0995a0d5315b5601ae5…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2023-11-22T10:17:01+01:00
modules: readme files regenerated - ims_ipsec_pcscf ... [skip ci]
---
Modified: src/modules/ims_ipsec_pcscf/README
---
Diff: https://github.com/kamailio/kamailio/commit/e59c4415707f0995a0d5315b5601ae5…
Patch: https://github.com/kamailio/kamailio/commit/e59c4415707f0995a0d5315b5601ae5…
---
diff --git a/src/modules/ims_ipsec_pcscf/README b/src/modules/ims_ipsec_pcscf/README
index 81c0cb4cb99..f94669509f1 100644
--- a/src/modules/ims_ipsec_pcscf/README
+++ b/src/modules/ims_ipsec_pcscf/README
@@ -58,7 +58,7 @@ Tsvetomir Dimitrov
4.1. ipsec_create(domain)
4.2. ipsec_forward(domain, flags)
- 4.3. ipsec_destroy(domain)
+ 4.3. ipsec_destroy(domain [, aor])
List of Examples
@@ -103,7 +103,7 @@ Chapter 1. Admin Guide
4.1. ipsec_create(domain)
4.2. ipsec_forward(domain, flags)
- 4.3. ipsec_destroy(domain)
+ 4.3. ipsec_destroy(domain [, aor])
1. Overview
@@ -270,7 +270,7 @@ modparam("ims_ipsec_pcscf", "ipsec_preferred_ealg", "aes-cbc")
4.1. ipsec_create(domain)
4.2. ipsec_forward(domain, flags)
- 4.3. ipsec_destroy(domain)
+ 4.3. ipsec_destroy(domain [, aor])
4.1. ipsec_create(domain)
@@ -325,13 +325,15 @@ ipsec_forward("location");
ipsec_forward("location", "1");
...
-4.3. ipsec_destroy(domain)
+4.3. ipsec_destroy(domain [, aor])
The function destroys IPSec tunnel, created with ipsec_create.
Meaning of the parameters is as follows:
* domain - Logical domain within the registrar. If a database is used
then this must be name of the table which stores the contacts.
+ aor - SIP URI to match the record. If not provided, then R-URI is
+ used.
Example 1.13. ipsec_destroy
...
Module: kamailio
Branch: master
Commit: ef3f50db619490509f127eba87b75190a98a1b3e
URL: https://github.com/kamailio/kamailio/commit/ef3f50db619490509f127eba87b7519…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-22T10:09:16+01:00
ims_ipsec_pcscf: docs updated for ipsec_destroy()
---
Modified: src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/ef3f50db619490509f127eba87b7519…
Patch: https://github.com/kamailio/kamailio/commit/ef3f50db619490509f127eba87b7519…
---
diff --git a/src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml b/src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml
index 982df9bbb14..d50c66ed45a 100644
--- a/src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml
+++ b/src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml
@@ -345,7 +345,7 @@ ipsec_forward("location", "1");
</section>
<section>
- <title><function moreinfo="none">ipsec_destroy(domain)</function></title>
+ <title><function moreinfo="none">ipsec_destroy(domain [, aor])</function></title>
<para>The function destroys IPSec tunnel, created with ipsec_create.</para>
<para>Meaning of the parameters is as follows:</para>
<itemizedlist>
@@ -355,6 +355,10 @@ ipsec_forward("location", "1");
If a database is used then this must be name of the table which
stores the contacts.
</para>
+ <para>
+ <emphasis>aor</emphasis> - SIP URI to match the record. If not
+ provided, then R-URI is used.
+ </para>
</listitem>
</itemizedlist>
<example>
Callback function might do an operation which creates a new transaction, which will result in a deadlock.
<!-- 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 -->
- [x] PR should be backported to stable branches
- [x] Tested changes locally
- [x] Related to issue #3641
#### Description
Problem in detail described in ticket.
Summary is that the lock used to iterate expired transactions is also needed when creating a new transaction.
If the callback function (directly or indirectly) do something that creates a new transaction, it will result in a deadlock.
In my case, this was the ims_charging module where a start charging request times out. The callback does t_continue() where the routing logic then rejects the call. This will create a stop request to the charging server, and it will block.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3643
-- Commit Summary --
* cdp: Avoid deadlock for callback on diameter timeout
-- File Changes --
M src/modules/cdp/transaction.c (35)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3643.patchhttps://github.com/kamailio/kamailio/pull/3643.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3643
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3643(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
I've been simulating calls while there's (faked) issues against the diameter server using TCP.
Ro_CCR() uses t_suspend() to suspend the SIP transaction while waiting for a response from the charging server.
A cdp transaction is also created with a callback to resume_on_initial_ccr() in the ims charging module.
When a response to a charging request is received, this is handled in cdp/api_process.c where cdp_take_trans() find the given transaction and returns it without a lock held. The callback is then executed, and everything is fine.
The problem occurs when a CCR times out, and the callback is done by the cdp_trans_timer() function. This hold a lock for the entire transaction list while executing callbacks for every timed out entry. In my case, the charging module does t_continue and the execution of that routing block is started again.
Here we reply a cause indicating it was an issue with the charging server. This will trigger a new callback from the ims_dialog module which again will try to start a new cdp transaction (CCR Stop) - still while the cdp_trans_timer function holds a lock.
Since the cdp timers now are blocked, no new connection attempts to the failed diameter server is done either.
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
```
Ro_CCR("RO_CONTINUE_DISPATCHER", "orig", 30, "", "")
this times out, and will do continue in the routing block specified (based on the cdp transaction timeout timer)
route[RO_CONTINUE_DISPATCHER] {
send_reply("500", "Internal error");
exit;
}
```
### 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.
-->
cdp_add_trans() on line 2 is blocked while waiting for lock held by cdp_trans_timer() on line 26 to be freed. The line numbers are a bit off because of some debugging.
```
#0 0x00007f6d9a3e0e29 in syscall () from /lib64/libc.so.6
#1 0x00007f6d979622f6 in futex_get (lock=0x7f6d706622a0) at ../../core/mem/../futexlock.h:121
#2 0x00007f6d979632cd in cdp_add_trans (msg=0x7f6d70921280, cb=0x7f6d9084caf5 <resume_on_termination_ccr>, ptr=0x0, timeout=5, auto_drop=1) at transaction.c:126
#3 0x00007f6d97980740 in AAASendMessage (message=0x7f6d70921280, callback_f=0x7f6d9084caf5 <resume_on_termination_ccr>, callback_param=0x0) at diameter_comm.c:158
#4 0x00007f6d9084c71b in send_ccr_stop_with_param (ro_session=0x7f6d70921dc0, code=0, reason=0x7ffe9b6cd400) at ims_ro.c:1183
#5 0x00007f6d90829f6d in dlg_terminated (dlg=0x7f6d7091f5d0, type=4, termcode=0, reason=0x7f6d9086f998 "call failed", _params=0x7f6d90d20280 <params>) at dialog.c:249
#6 0x00007f6d908216cd in dlg_callback_received (dlg=0x7f6d7091f5d0, type=4, _params=0x7f6d90d20280 <params>) at dialog.c:29
#7 0x00007f6d90aed1b9 in run_dlg_callbacks (type=4, dlg=0x7f6d7091f5d0, req=0x7f6d7091fb68, rpl=0xffffffffffffffff, dir=2, dlg_data=0x0) at dlg_cb.c:271
#8 0x00007f6d90abced4 in dlg_onreply (t=0x7f6d70931e10, type=1048576, param=0x7ffe9b6cda80) at dlg_handlers.c:1363
#9 0x00007f6d94252f2c in run_trans_callbacks_internal (cb_lst=0x7f6d70931eb8, type=1048576, trans=0x7f6d70931e10, params=0x7ffe9b6cda80) at t_hooks.c:236
#10 0x00007f6d942530e4 in run_trans_callbacks_with_buf (type=1048576, rbuf=0x7f6d70931f10, req=0x7f6d7091fb68, repl=0xffffffffffffffff, flags=0) at t_hooks.c:272
#11 0x00007f6d941d2860 in _reply_light (trans=0x7f6d70931e10, buf=0x7f6d97d10768 "SIP/2.0 480 Temporarily Unavailable\r\nVia: SIP/2.0/UDP 192.168.10.15:5060;branch=z9hG4bK427d31b9\r\nFrom: \"sipp\" <sip:+4749484948@192.168.10.15;user=phone>;tag=as22aa85b4\r\nTo: <sip:+4749494848@192.168.10.20"..., len=386, code=480, to_tag=0x7f6d944bb5e0 <tm_tags> "b239b52f382f2203913409401a079c72-9b859c73", to_tag_len=41, lock=0, bm=0x7ffe9b6ce5d0)
at t_reply.c:520
#12 0x00007f6d941d3e8e in _reply (trans=0x7f6d70931e10, p_msg=0x7f6d70946878, code=480, reason=0x7ffe9b6ce750, lock=0) at t_reply.c:689
#13 0x00007f6d941dfdcf in t_reply_str_unsafe (t=0x7f6d70931e10, p_msg=0x7f6d70946878, code=480, reason=0x7ffe9b6ce750) at t_reply.c:1753
#14 0x00007f6d941fd400 in ki_t_reply (msg=0x7f6d70946878, code=480, reason=0x7ffe9b6ce750) at tm.c:1538
#15 0x00007f6d941fdcee in w_t_reply_wrp (msg=0x7f6d70946878, code=480, txt=0x7f6d97d106e8 "Temporarily Unavailable") at tm.c:1598
#16 0x00007f6d93d24c0e in send_reply (msg=0x7f6d70946878, code=480, reason=0x7ffe9b6ce880) at sl.c:287
#17 0x00007f6d93d25728 in w_send_reply (msg=0x7f6d70946878, p1=0x7f6d97cee2e8 "x)\320\227m\177", p2=0x7f6d97cee388 "\350)\320\227m\177") at sl.c:329
#18 0x0000000000466fb3 in do_action (h=0x7ffe9b6cf9b0, a=0x7f6d97d025d8, msg=0x7f6d70946878) at core/action.c:1131
#19 0x0000000000474188 in run_actions (h=0x7ffe9b6cf9b0, a=0x7f6d97d02210, msg=0x7f6d70946878) at core/action.c:1618
#20 0x000000000047028d in do_action (h=0x7ffe9b6cf9b0, a=0x7f6d97d02f00, msg=0x7f6d70946878) at core/action.c:1241
#21 0x0000000000474188 in run_actions (h=0x7ffe9b6cf9b0, a=0x7f6d97cfdb68, msg=0x7f6d70946878) at core/action.c:1618
#22 0x00000000004748cc in run_top_route (a=0x7f6d97cfdb68, msg=0x7f6d70946878, c=0x0) at core/action.c:1701
#23 0x00007f6d9425802a in t_continue_helper (hash_index=39149, label=1245761144, rtact=0x7f6d97cfdb68, cbname=0x0, cbparam=0x0, skip_timer=1) at t_suspend.c:307
#24 0x00007f6d9425c6d8 in t_continue (hash_index=39149, label=1245761144, route=0x7f6d97cfdb68) at t_suspend.c:603
#25 0x00007f6d9085b372 in resume_on_initial_ccr (is_timeout=1, param=0x7f6d70921cc8, cca=0x0, elapsed_msecs=1) at ims_ro.c:1786
#26 0x00007f6d979646d1 in cdp_trans_timer (now=1699966590, ptr=0x0) at transaction.c:223
#27 0x00007f6d9798e3b0 in timer_loop () at timer.c:117
#28 0x00007f6d9798f639 in timer_process (returns=0) at timer.c:217
#29 0x00007f6d97942cf8 in diameter_peer_start (blocking=0) at diameter_peer.c:350
#30 0x00007f6d97932bb2 in cdp_child_init (rank=0) at cdp_mod.c:272
```
#### 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).
-->
```
```
#### 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).
-->
```
```
### Possible Solutions
I'm considering changing cdp_trans_timer() to iterate through the list, remove expired items while keeping them in a new list so all callbacks can be executed without the lock held.
Could also be fixed within the ims_charging module. For example by not sending a CCR-T when there's no answer to the CCR-I, but I feel that's more of a band aid rather than a real fix.
Any feedback or suggestions would be nice.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
master
```
* **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`)
-->
```
centos 7.8
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3641
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3641(a)github.com>
Module: kamailio
Branch: master
Commit: e17b554ba918dc33c60f41c2cee50ad2578fbbd3
URL: https://github.com/kamailio/kamailio/commit/e17b554ba918dc33c60f41c2cee50ad…
Author: Morten Tryfoss <morten(a)tryfoss.no>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-11-22T09:36:44+01:00
ims_charging: Various changes to make module compatible to other charging servers
- Use origin-host of CCR response as destination-host of subsequent CCR requests,
to make sure those requests are routed to the same charging server (when using relay).
- use str_dup and str_free from ims_getters instead of locally defined.
- Honour AVP_Time_Quota_Threshold in CCR response, as an alternative to static configured
modparam "timer_buffer".
- Add new modparam "strip_plus_from_e164" to enable sending subscription id with correct
format according to specified type in the AVP.
- Moved subscription id formatting into a common function.
- Handle CCR response without AVP_Validity_Time set correctly. Was interpreted as
immediate expire.
- Handle IMS_RAR (Re-auth) request from charging server. Triggers an immediate interim
update if the session is alive.
- Handle IMS_ASR (Abort) request from charging server. Triggers an immediate termination
of the session/call.
- Fixed issue with signed/unsigned int related to check for Expires header.
cscf_get_expires_hdr() returns signed (-1 for not found), while that value was added
to the outgoing diameter request unsigned. That again resulted in an Expires AVP with
a really large value, and was rejected by the charging server.
---
Modified: src/modules/ims_charging/Ro_data.c
Modified: src/modules/ims_charging/Ro_data.h
Modified: src/modules/ims_charging/ccr.c
Modified: src/modules/ims_charging/config.h
Modified: src/modules/ims_charging/dialog.c
Modified: src/modules/ims_charging/doc/ims_charging_admin.xml
Modified: src/modules/ims_charging/ims_charging_mod.c
Modified: src/modules/ims_charging/ims_ro.c
Modified: src/modules/ims_charging/ims_ro.h
Modified: src/modules/ims_charging/ro_db_handler.c
Modified: src/modules/ims_charging/ro_db_handler.h
Modified: src/modules/ims_charging/ro_session_hash.c
Modified: src/modules/ims_charging/ro_session_hash.h
Modified: src/modules/ims_charging/ro_timer.c
Modified: utils/kamctl/mysql/ims_charging-create.sql
---
Diff: https://github.com/kamailio/kamailio/commit/e17b554ba918dc33c60f41c2cee50ad…
Patch: https://github.com/kamailio/kamailio/commit/e17b554ba918dc33c60f41c2cee50ad…
<!-- 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
**Use origin-host of CCR response as destination-host of subsequent CCR requests**
When connecting to a diameter node which using relay, it may load balance requests to multiple servers for handling. This change ensures that subsequent requests are sent to the same server.
**Honour AVP_Time_Quota_Threshold in CCR response**
Charging server indicates it want an interim update X number of seconds before all quota has been used.
**Add new modparam «strip_plus_from_e164»**
The existing formatitng routine check if it's a tel: or sip: uri, and sets E.164 or SIP according to that. If it's E.164, it strips "tel:" too. A subscription id with leading "+" is actually of type SIP.
I didn't want to make a breaking change here, so I introduced a new setting which fixes the behaviour.
**Moved subscription id formatting into a common function**
For more clean code, and one place to make further adjustments.
**Handle CCR response without AVP_Validity_Time**
If missing, various places in the module reported immediate expire.
**Handle IMS_RAR (Re-auth) request from charging server**
Typical scenario is that there's a missing interim update, and the server want to check if the session is still alive. At reception we try a lookup and if found, schedule a new request.
**Handle IMS_ASR (Abort) request from charging server**
Similar handling as for re-auth, but for server-initiated termination of the call.
**Fixed issue with signed/unsigned int related to check for Expires header**
cscf_get_expires_hdr() returns signed (-1 for not found), while that value was added
to the outgoing diameter request unsigned. That again resulted in an Expires AVP with
a really large value, and was rejected by the charging server.
Most probably cscf_get_expires_hdr() should be changed to return unsigned since the value theoretical can be that big, but since that is a common function for the ims modules it would require more testing than I'm capable of right now.
**Use str_dup() and str_free() from ims_getters instead of locally defined**
Those were needed more places.
--
I'm a little bit unsure about updating a string allocated in shm, where the length is changed (look in ims_ro.c, credit_control_session_callback()). Is the correct way to do a shm_free() and then reallocate, or is there a more simple way of doing it?
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3640
-- Commit Summary --
* cdp: Add support for re-auth on ro sessions initiated from charging server
* ims_charging: Various changes to make module compatible to other charging servers
-- File Changes --
M src/modules/cdp/acctstatemachine.c (2)
M src/modules/cdp/diameter_code_avp.h (2)
M src/modules/cdp/peerstatemachine.c (8)
M src/modules/cdp/session.c (2)
M src/modules/ims_charging/Ro_data.c (40)
M src/modules/ims_charging/Ro_data.h (5)
M src/modules/ims_charging/ccr.c (8)
M src/modules/ims_charging/config.h (1)
M src/modules/ims_charging/dialog.c (18)
M src/modules/ims_charging/doc/ims_charging_admin.xml (20)
M src/modules/ims_charging/ims_charging_mod.c (59)
M src/modules/ims_charging/ims_ro.c (234)
M src/modules/ims_charging/ims_ro.h (3)
M src/modules/ims_charging/ro_db_handler.c (43)
M src/modules/ims_charging/ro_db_handler.h (5)
M src/modules/ims_charging/ro_session_hash.c (45)
M src/modules/ims_charging/ro_session_hash.h (6)
M src/modules/ims_charging/ro_timer.c (8)
M utils/kamctl/mysql/ims_charging-create.sql (3)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3640.patchhttps://github.com/kamailio/kamailio/pull/3640.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3640
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3640(a)github.com>
### Description
I use debian 11 and Kamailio 5.6.x
modparam("htable", "htable", "callpush=>size=10;autoexpire=86400;dbtable=callpush;dbmode=1")
I can store the values in the table, but if I shutdown kamailio, the current values are not stored in the table.
#### Reproduction
Use a htable and dbtable and dbmode=1 and shutdown kamailio.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3536
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3536(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for feature requests.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If you submit a feature request (or enhancement) add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
The current issue revolves around the absence of username support within the NDB REDIS KAMALIO framework when dealing with Redis, particularly concerning the Redis and Sentinel components. While Redis inherently offers the capability to utilize both usernames and passwords during authentication, this capability is not currently extended to the NDB REDIS KAMALIO setup.
As a result, when attempting to establish connections to Redis instances through NDB REDIS KAMALIO, there is no provision for providing a username as part of the authentication process. Instead, the framework only accommodates the usage of passwords for authentication. This stands in contrast to Redis, which permits the inclusion of both usernames and passwords for enhanced security measures.
Consequently, the limitation within NDB REDIS KAMALIO can hinder organizations seeking to ensure comprehensive security practices, especially when the requirement is to employ both usernames and passwords for authentication. This divergence between the authentication capabilities of Redis and NDB REDIS KAMALIO can potentially compromise security standards and hinder compatibility with certain authentication setups.
To address this issue, it would be essential for the development team behind NDB REDIS KAMALIO to enhance the framework's capabilities by incorporating support for username-based authentication in addition to passwords. This alignment with Redis's authentication model would ensure that organizations can confidently implement secure data interactions while maintaining consistency with established security policies
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Expected behavior
The expected behavior entails an improvement within the NDB REDIS KAMALIO framework to support both usernames and passwords for authentication when interacting with Redis instances, particularly in the Redis and Sentinel components. This enhancement would bring NDB REDIS KAMALIO in line with Redis's native authentication capabilities, where both usernames and passwords are accepted during the authentication process.
Upon implementing this improvement, users of NDB REDIS KAMALIO should be able to configure their connections by providing both a username and a password as part of the authentication details. This allows NDB REDIS KAMALIO to establish connections to Redis instances that require both authentication credentials, thereby enhancing security and ensuring compatibility with various authentication setups.
By incorporating support for usernames in addition to passwords, NDB REDIS KAMALIO can accommodate organizations that require comprehensive security measures, especially in scenarios where username-based authentication is mandated. This alignment with Redis's authentication model would enable organizations to effectively collect, manage, and interact with data while adhering to established security policies.
In summary, the expected behavior is that NDB REDIS KAMALIO should be upgraded to offer support for usernames and passwords during authentication, mirroring Redis's capabilities. This enhancement ensures a consistent and secure approach to data interactions and supports various authentication requirements within Redis environments
#### Actual observed behavior
The current actual behavior is that NDB REDIS KAMALIO does not have the capability to accept usernames as part of the authentication process when connecting to Redis instances, specifically in both the Redis and Sentinel components. While Redis itself allows for the usage of both usernames and passwords for authentication, this feature is not currently integrated into the NDB REDIS KAMALIO framework.
As a result, when configuring connections to Redis instances using NDB REDIS KAMALIO, there is no provision to include a username alongside the authentication details. The framework only accommodates the use of passwords for authentication purposes. This deviation from Redis's authentication model could lead to compatibility issues with certain authentication setups, particularly those that mandate the use of both usernames and passwords.
In essence, the actual behavior is that NDB REDIS KAMALIO falls short of aligning with Redis's authentication capabilities, thereby potentially hindering secure data interactions and limiting compatibility with certain security policies. Users attempting to adhere to comprehensive authentication practices may face challenges when utilizing NDB REDIS KAMALIO due to its inability to support usernames during authentication.
To address this actual behavior, it would be necessary to enhance NDB REDIS KAMALIO's capabilities to include support for both usernames and passwords during the authentication process. This enhancement would ensure that organizations can confidently utilize NDB REDIS KAMALIO while maintaining the security standards and authentication requirements necessary for their Redis environments.
#### Debugging Data
```
(paste your debugging data here)
```
#### 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).
-->
```
(paste your log messages here)
```
#### 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
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a improvement.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **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 `uname -a`)
-->
```
(paste your output here)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3552
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3552(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Currently, kamailio NDB Redis integration with Sentinel does not offer support for password authentication, leading to potential security concerns in our system. As a result, we are unable to ensure the desired level of protection for sensitive data stored in Redis.
*Expected Behavior:*
We expect Kamailio to allow the configuration of password authentication for Sentinel in the NDB Redis integration, enabling a secure and password-protected connection to the Redis instances.
*Proposed Solution:*
To address this issue, we recommend implementing a feature that enables password authentication for the Sentinel-based NDB Redis connections. This improvement will provide an added layer of security, ensuring that only authorized users can access the Redis instances.
*Impact:*
The absence of password authentication support poses a security risk, making our system vulnerable to potential unauthorized access and data breaches. Implementing this enhancement will safeguard sensitive information and strengthen our Redis integration's security framework.
Note: as of now NDB REDIS support redis authentication using password
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
Steps to Reproduce:*
1. Attempt to configure password authentication for Sentinel in kamailio NDB Redis integration.
ex:
modparam("ndb_redis", "server", "name=srvZ;sentinel_group=group_name;sentinel_master=1;sentinel=1.2.3.4:26379;sentinel=1.2.3.5:26379";pass=mypassword")
*It is failed to connect the sentinel *
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### 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
<!--
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).
-->
```
(paste your log messages here)
```
#### 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
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **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`)
-->
```
(paste your output here)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3530
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3530(a)github.com>
### Description
Newer rtpengine versions support manipulating SDP "a=" lines directly. Although kamailio is quite versatile when it comes to editing SIP message body, this functionality is often rather frail, especially when forking and having to use msg_apply_changes several times. I believe it would be beneficial to be able to offload such functionality to rtpengine, especially if one wants to apply different manipulations per outgoing branch.
### Expected behavior
There should be a way to issue rtpengine ng-control protocol commands compatible with the sdp-attr dictionary syntax.
#### Actual observed behavior
Currently sdp-attr tokens are not properly evaluated. For example, **doing**:
> rtpengine_manage("ICE=remove rtcp-mux-demux trust-address replace-origin replace-session-connection replace-SDP-version direction=internal direction=external sdp-attr-audio-substitute=$avp(fmtp_line) sdp-attr-audio-substitute=fmtp:101 0-15");
_[NOTE: $avp(fmtp_line) seems to expand in empty string here, which is a config error, but it doesn't affect the syntax demonstration in this example IMO]_
**results in**:
```
{
"supports": [ "load limit" ],
"sdp": "...",
"ICE": "remove",
"sdp-attr-audio-substitute": "",
"sdp-attr-audio-substitute": "fmtp:101",
"direction": [ "internal", "external" ],
"flags": [ "trust-address", "0-15" ],
"replace": [ "origin", "session-connection", "SDP-version" ],
"rtcp-mux": [ "demux" ],
"call-id": "...",
"received-from": [ "IP4", "..." ],
"from-tag": "...",
"to-tag": "...",
"command": "answer"
}
```
### Possible Solutions
Support the special syntax of sdp-attr as documented here: https://github.com/sipwise/rtpengine/blob/master/docs/ng_control_protocol.md
Here's one way to do it (I guess).
In order to get this:
```
"sdp-attr" :
{
"audio" :
{
"add" : [ "ptime:20", "sendrecv" ],
"substitute": [["fmtp:101 0-15" , "fmtp:126 0-16" ]]
},
"video":
{
"remove" : [ "rtpmap:101 telephone-event/8000" ]
},
"none" :
{
"substitute": [[ "sendrecv" , "sendonly" ], [ "ptime:20" , "ptime:40" ]]
}
}
```
Use a syntax similar to the following:
> rtpengine_manage("... sdp-attr-audio-add=ptime:20 sdp-attr-audio-add=sendrecv sdp-attr-audio-substitute=fmtp:101 0-15 sdp-attr-audio-substitute=fmtp:101 0-16 sdp-attr-video-remove=rtpmap:101 telephone-event/8000 sdp-attr-none-substitute=sendrecv sdp-attr-none-substitute=sendonly sdp-attr-none-substitute=ptime:20 sdp-attr-none-substitute=ptime:40 ...");
It's not very pretty, but it could work. Caveats:
* How to handle whitespace (e.g. there's a space in "fmtp:101 0-15" and in "rtpmap:101 telephone-event/8000" )
* substitute commands must always be in pairs, data type is a list of lists containing exactly two items as value in "substitute" key
Unfortunately my C skills are not up to this task, but if I can provide any other kind of help please let me know. Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3509
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3509(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, ...)
- [ ] 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
This PR adds support for $hfl(Diversion)[] and $hflc(Diversion).
This parse_diversion.c was inspired by [parse_pai_ppi.c](https://github.com/kamailio/kamailio/blob/master/src/core/…. I am not sure if it's breaking the existing implementation and usage. I believe it does not.
During some experimentation with the hfl(name)[-1], I encountered weird behavior with negative indexing for the already supported headers like Via, Route, and Contact. -1 yields null and -2 yields the last one and so on. Separate PR can be introduced if necessary.
Any feedback is welcome.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3650
-- Commit Summary --
* parser: Extend diversion for multiple bodies
* pv: Add hfl and hflc support for Diversion header
-- File Changes --
M src/core/parser/parse_diversion.c (149)
M src/core/parser/parse_diversion.h (10)
M src/modules/pv/pv_core.c (175)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3650.patchhttps://github.com/kamailio/kamailio/pull/3650.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3650
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3650(a)github.com>