<!--
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 seems to fail to properly route in-dialog SUBSCRIBE with the topos module enabled. In this configuration, SUBSCRIBEs are expected to be delivered to a downstream UAS, an asterisk instance in the internal network.
record_route() is executed for all initial requests, including SUBSCRIBEs. Routing is performed correctly with the topos module disabled, no other modifications were needed.
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
I haven't been able to work around this issue in any other way other than disabling the topos module.
#### Reproduction
The configuration used is a heavily modified version of the example configuration file, but the handling of SUBSCRIBEs is generally simple. The initial SUBSCRIBE is subject to some tests, the R-URI is edited and dispatched to a farm of asterisk servers based on some criteria. Record Routing is enforced, so subsequent in-dialog re-SUBSCRIBEs are expected to be routed with loose_route(), which doesn't seem to handle things properly.
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### Debugging Data
I'm attaching kamailio logs with debug=4, cfg_trace
<!--
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
See attachments
<!--
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
Please see: https://www.cloudshark.org/captures/d2643aae7f2a
<!--
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
Using topoh instead for topos, but unfortunately this will break communication for other reasons (messages too large/UDP fragmentation for some peers).
### Additional Information
* **Kamailio Version**
Tried with kamailio 5.1.6 and kamailio 5.3.0-dev0
deb.kamailio.org repositories were used to acquire binaries for both versions
* **Operating System**:
Debian Stretch
<!--
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`)
-->
[resubscribe.log](https://github.com/kamailio/kamailio/files/2586440/resubsc…
--
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/1724
### Description
While debugging an issue with locally generated in-dialog requests I stumbled upon some weirdness with the alias functionality from the nathelper module.
The dialog modules tries to handle an alias parameter when sending an in-dialog request by calling ```uri_restore_rcv_alias()``` in the function ```build_dlg_t()```. A few instructions later, the same is attempted by the tm module in the function ```req_within()```.
It seems to me that the attempt by the dialog module is redundant and can be removed.
And while at it, IMHO it should be removed from the tm module too. This is functionality introduced by the nathelper module. Nowhere in the documentation it is mentioned there is some automatic handling of the alias parameter. If handling is needed for local requests, the script writer can call ```handle_uri_alias()``` from within local_route.
If the functionality has to stay, may I suggest that the code in the nathelper module makes use of the ```uri_restore_rcv_alias()``` function instead of having its own duplicate implementation. Less maintenance, easier debugging.
--
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/2014
<!--
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
rightnow, there is no stats about command sent to rtpengine and getting reply from rtpengine. There should be a stats that will tell that
number of offer request sent:
number of answer request sent:
number of delete request sent:
number of failed request for offer [after retry]:
number of failed request for answer [after retry]:
number of failed request for delete [after retry]:
This will help to identify actual number of failed request.
<!--
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 `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/1699
#### Reproduction
Install newest Kamailio 5.2.
Change date e.g. 2 Years into the future. (Make sure you have no daemon running which prohibits those operations):
```
sudo date -s "2014-12-25 $(date +%H:%M:%S)"
```
```
sudo date -s "2016-12-25 $(date +%H:%M:%S)"
```
Kamailio now uses the whole CPU to do stuff:
```
top - 08:10:35 up 14 days, 1:29, 2 users, load average: 3.77, 1.83, 1.05
Tasks: 212 total, 11 running, 201 sleeping, 0 stopped, 0 zombie
%Cpu(s): 95.9 us, 1.5 sy, 2.2 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st
MiB Mem : 926.1 total, 116.3 free, 382.5 used, 427.3 buff/cache
MiB Swap: 100.0 total, 40.4 free, 59.6 used. 423.4 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13264 root 20 0 89720 3944 2676 R 44.9 0.4 0:05.15 kamailio
13266 root 20 0 89720 4000 2736 R 37.3 0.4 0:04.63 kamailio
13267 root 20 0 89720 4912 3488 R 36.0 0.5 0:04.37 kamailio
13270 root 20 0 89720 4540 3240 R 36.0 0.5 0:05.85 kamailio
13269 root 20 0 89720 4000 2736 R 34.7 0.4 0:04.81 kamailio
13265 root 20 0 89720 3944 2680 R 34.4 0.4 0:04.61 kamailio
13261 root 20 0 89720 3952 2676 R 32.2 0.4 0:04.44 kamailio
13262 root 20 0 89720 3944 2676 R 31.8 0.4 0:04.72 kamailio
13256 root 20 0 89720 4752 3540 R 30.3 0.5 0:07.04 kamailio
13268 root 20 0 89720 4000 2736 R 30.3 0.4 0:04.49 kamailio
18021 root 20 0 40116 11884 5728 D 13.7 1.3 0:01.11 apt-get
```
There are multiple mailing list entries regarding this issue:
https://lists.kamailio.org/pipermail/sr-users/2015-October/090465.htmlhttps://lists.kamailio.org/pipermail/sr-users/2015-November/090487.htmlhttps://lists.kamailio.org/pipermail/sr-users/2019-June/105967.htmlhttps://lists.kamailio.org/pipermail/sr-users/2019-August/106428.html
I was able to get rid of the issue with uncommenting the mentioned part of the code. But I'm quite sure that's not a fix :)
![image](https://user-images.githubusercontent.com/11159719/63680341-b6d67880-c7f3-11e9-825b-529e7ec26b2e.png)
--
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/2046
The commit 0436af5abd8b73e breaks startup for jsonrpcs module.
Logs:
```
Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_sock.c:358]: jsonrpc_dgram_init_server(): failed to change the owner/group for /var/run/kamailio/kamailio_rpc.sock to 33.0;Operation not permitted[1]
Jul 5 10:04:41 kam01 kamailio[4951]: CRITICAL: jsonrpcs [jsonrpcs_sock.c:423]: jsonrpc_dgram_init_socks(): initializing datagram server function returned error
Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_sock.c:246]: jsonrpc_dgram_mod_init(): init datagram sockets function failed
Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_mod.c:1150]: mod_init(): cannot initialize datagram transport
Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: <core> [core/sr_module.c:849]: init_mod(): Error while initializing module jsonrpcs (/usr/lib/x86_64-linux-gnu/kamailio/modules/jsonrpcs.so)
```
Relevant cfg:
```
loadmodule "jsonrpcs.so"
modparam("jsonrpcs", "pretty_format", 1)
modparam("jsonrpcs", "dgram_user", "www-data")
modparam("jsonrpcs", "dgram_group", "root")
modparam("jsonrpcs", "transport", 7)
```
Previously Kamailio was started as root, and then configured with -u $USER and -g $GROUP to drop privileges to the lower user/group. During startup Kamailio could create the socket with the correct permissions.
The mentioned commit changes this to: start Kamailio directly as user Kamailio and group Kamailio, which don't have privileges create the sockets with the correct permissions.
Not sure about the motivation about this change, so I don't want to simple revert it. Maybe @sergey-safarov or other developers can comment.
--
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/2391