<!-- 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
Allow Kamailio modules to register their log function so that all Kamailio log messages (coming from core and other modules) are logged uniformly in the format defined by the custom log function.
To enable the custom log format feature, Kamailio must be compiled with the `CUSTOM_LOG_FMT` flag. Then the module that wishes to modify the log format has to call `km_custom_log_func_set` during the initialization to supply a custom log formatting function (see `km_default_custom_log_func` as an example).
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3902
-- Commit Summary --
* core: add support for custom log function
-- File Changes --
M src/core/dprint.c (19)
M src/core/dprint.h (47)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3902.patchhttps://github.com/kamailio/kamailio/pull/3902.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3902
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3902(a)github.com>
When relaying this `200 OK` repeatedly with calls to `rtpengine_answer()` failing because all RTPEngines in a set are unreachable...
```
Dec 8 06:24:38 gw kamailio[4823]: ERROR: rtpengine [rtpengine.c:2960]: select_rtpp_node(): rtpengine failed to select new for calllen=36 callid=8279a4ea-151e-48de-a23c-5840104126de
```
```
SIP/2.0 200 OK
v:SIP/2.0/UDP 10.150.20.20;branch=z9hG4bK03e.e4da444e627bb575ef4f46151729a1fa.0,SIP/2.0/UDP 10.151.20.108;received=10.151.20.108;rport=5060;branch=z9hG4bKKQyrBKpp04X0K
Record-Route:<sip:10.150.20.20;lr;ftag=emHm2apy95jFe;rtp_relay=1;rtp_group=0>
f:"14045551212"<sip:14045551212@10.151.20.108>;tag=emHm2apy95jFe
t:<sip:16782001111@internal.evaristesys.com>;tag=tHQt0rDcF7UHK
i:8279a4ea-151e-48de-a23c-5840104126de
CSeq:60686471 INVITE
m:<sip:16782001111@10.160.10.55:5060;transport=udp>
User-Agent:VoiceAppServer
Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REFER,NOTIFY
k:path,replaces
u:talk,hold,conference,refer
c:application/sdp
Content-Disposition:session
l:257
v=0
o=DM 1670428117 1670428118 IN IP4 10.160.10.55
s=DM
c=IN IP4 10.160.10.55
t=0 0
m=audio 52418 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp:52419 IN IP4 10.160.10.55
```
Repeat INVITEs eventually result in a crash. This backtrace is taken from a different server but identical scenario:
```
#0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40,
reply=0x7f4afe40df70) at t_reply.c:1285
1285 && !(inv_through && Trans->uac[branch].last_received<300)) {
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.192.el6.x86_64 jansson-2.11-1.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-57.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libev-4.03-3.el6.x86_64 libselinux-2.0.94-7.el6.x86_64 libunistring-0.9.3-5.el6.x86_64 openssl-1.0.1e-48.el6_8.3.x86_64 sqlite-3.6.20-1.el6_7.2.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) where
#0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40,
reply=0x7f4afe40df70) at t_reply.c:1285
#1 0x00007f4afd73ab7d in relay_reply (t=0x7f4aee56ba80, p_msg=0x7f4afe40df70, branch=0, msg_status=200, cancel_data=0x7ffd8b8bbe40, do_put_on_wait=1)
at t_reply.c:1821
#2 0x00007f4afd740c38 in reply_received (p_msg=0x7f4afe40df70) at t_reply.c:2558
#3 0x00000000004b5d6a in do_forward_reply (msg=0x7f4afe40df70, mode=0) at core/forward.c:747
#4 0x00000000004b78c9 in forward_reply (msg=0x7f4afe40df70) at core/forward.c:852
#5 0x000000000054982b in receive_msg (
buf=0xb27700 "SIP/2.0 200 OK\r\nv:SIP/2.0/UDP xxx;branch=z9hG4bK9915.dcfe6d03cb21e6c94a6705adb095c566.0,SIP/2.0/UDP xxx;received=xxx;rport=5060;branch=z9hG4bKZmZp0NZv3FvQB\r\nRecord-Rout"..., len=984, rcv_info=0x7ffd8b8bc6c0) at core/receive.c:434
#6 0x00000000006658ca in udp_rcv_loop () at core/udp_server.c:541
#7 0x000000000042500f in main_loop () at main.c:1655
#8 0x000000000042c5bb in main (argc=11, argv=0x7ffd8b8bcc88) at main.c:2696
```
Looks like in the crash frame, `Trans->uac` is `NULL`:
```
(gdb) frame 0
#0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40,
reply=0x7f4afe40df70) at t_reply.c:1285
1285 && !(inv_through && Trans->uac[branch].last_received<300)) {
(gdb) print Trans->uac
$1 = (struct ua_client *) 0x0
```
I have seen this crash from time to time, though it is infrequent. It always seems to occur when there are problems reaching RTPEngine in a timely fashion.
This is on Kamailio 5.2.4:de9a03, which I know has long fallen off the back of the maintenance train. However, line 1386 of `t_reply.c` in `master:HEAD` shows that the code is no different now:
https://github.com/kamailio/kamailio/blob/master/src/modules/tm/t_reply.c#L…
Of course, it's possible that something upstream has changed so as to prevent this state. Otherwise, I suppose a null pointer safety check for `Trans->uac` is recommended. I'd be happy to submit a patch, just wasn't sure if the feeling was more that this should be resolved higher up the call stack.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3297
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3297(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)
- [x] 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 [reported in lists](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.k…
#### Description
<!-- Describe your changes in detail -->
This PR aims to fix a bug/security issue where data that was supposed to be encrypted and transferred through TLS, were transferred instead with TCP protocol.
More information and how to replicate can be found in the above [issue](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.k… in list.
This PR suggests using also the protocol to match if a TCP connection exists, and when doing connection lookups, otherwise, it might return a wrong connection, ie a TCP one when we are asking for a TLS one (a case when source ip/port and dest IP are same but dest port is set 0 (wildcard) ).
`tcpconn_get` was left unchanged due to being used by some modules and not wanting to break them. Please advise whether it should be beneficial to also change it.
In some cases like, `tcpconn_add_alias` and `tcpconn_get` we used the `PROTO_NONE` which preserves the original behavior. `tcpconn_add_alias` we do have the protocol available, should it be also used?
`tcpconn_get` does not have the protocol available unless we pass it as an argument.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3810
-- Commit Summary --
* tcp_main: Add protocol argument for searching tcp/tls connections
* tcp_main: Add proto argument to tcpconn_exists function
* tcp_main: Update comment docs
* core/forward: Match protocol when forwarding
* tcp_main: Match wss protocol
-- File Changes --
M src/core/forward.h (3)
M src/core/tcp_conn.h (3)
M src/core/tcp_main.c (43)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3810.patchhttps://github.com/kamailio/kamailio/pull/3810.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3810
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3810(a)github.com>
### Description
Feature request/suggestion: Currently, the predicative hashing algorithm for dispatcher gives equal weight to all members of the set. It would be convenient to use the rweight attribute to allow something like [weighted rendezvous hashing](https://en.wikipedia.org/wiki/Rendezvous_hashing#Weighted_rendezvo… to provide weighted load balancing will still keeping correct routing for stateless messages (most specifically CANCELs).
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3916
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3916(a)github.com>
### Description
I am using Kemi with the app_python3 module. I was getting what appeared to be random TypeError exceptions thrown within the Kamailio app_python3 module. I later discovered that this only happened when calling a Kamailio function that exceeded the duration specified in the latency_limit_action core parameter. Also, the line printed in the logs displayed Null values in the 'file:' and 'func:' fields.
#### Reproduction
To reproduce the issue:
1. You must be using Kemi with the app_python3 module, with the cfgengine set to python.
2. Set the following in your kamailio.cfg file:
```
latency_log=2
latency_limit_action=100000
```
3. Run a Kemi function call that takes more time than the latency_limi_action set above. You may have to lower it if your computer is a fast runner. Here is my suggested code:
```
jsreload = dict()
jsreload["jsonrpc"] = "2.0"
jsreload["method"] = "tls.reload"
jsreload["id"] = 1
KSR.jsonrpcs.exec(json.dumps(jsreload))
```
4. Use python version 3.11
#### Log Messages
45(324) INFO: app_python3 [apy_kemi.c:377]: sr_apy_kemi_exec_func(): alert - action KSR.jsonrpcs.exec(...) took too long [752946 ms] (file:(null) func:(null) line:491)
45(324) ERROR: app_python3 [python_support.c:167]: python_handle_exception(): apy_exec: ksr_rtimer_dodebug(rtimer): Unhandled exception in the Python code:
TypeError: expected bytes, str found
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/etc/kamailio/kamailio.py", line 491, in ksr_rtimer_dodebug
KSR.jsonrpcs.exec(json.dumps(jsreload))
SystemError: <built-in function exec> returned a result with an exception set
### Possible Solutions
The solution is to replace PyBytes_AsString(..) calls with calls to PyUnicode_AsUTF8(..) in the PY_VERSION_HEX >= 0x030B0000 block of apy_kemi.c. The PyBytes_AsString expects a Bytes value but reeives a Unicode value instead, thus causing the TypeError exception. Enclosed is a patch file with the fix implemented:
[kamailio-5.8.2.patch.txt](https://github.com/user-attachments/files/1619573…
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
# kamailio -v
version: kamailio 5.8.2 (x86_64/linux) 3fa5f4
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_SEND_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: 3fa5f4
compiled on 09:58:55 Jul 12 2024 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`)
-->
```
# uname -a
Linux xxxxxxxxxxxxxxxxxxx 5.10.0-30-amd64 #1 SMP Debian 5.10.218-1 (2024-06-01) x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3915
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3915(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
- [ ] 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
#### Description
This is the first step to merge the functionality that is already used in Sipwise kamailio flavor
* module parameters [from|to]_uri_avp to store
* sca_handle_subscribe() support [from|to_uri] parameters
Add the possibility of define what is the URI value for To and/or From instead of the values from the SIP message
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3930
-- Commit Summary --
* sca: add support custom [to|from]_uri
-- File Changes --
M src/modules/sca/doc/sca.xml (58)
M src/modules/sca/doc/sca_admin.xml (52)
M src/modules/sca/sca.c (115)
M src/modules/sca/sca.h (5)
M src/modules/sca/sca_call_info.c (190)
M src/modules/sca/sca_subscribe.c (96)
M src/modules/sca/sca_subscribe.h (5)
M src/modules/sca/sca_util.c (184)
M src/modules/sca/sca_util.h (19)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3930.patchhttps://github.com/kamailio/kamailio/pull/3930.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3930
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3930(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.
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.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
If Deregistration contains * in a contact field as described in RFC-3261,
then the Kamailio is not cleaning the in-memory and database record. And the next iteration is not working correctly.
Use of the "*" Contact header field value allows a registering UA
to remove all bindings associated with an address-of-record
without knowing their precise values.
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
Step:1 REGISTER USER UE-A
Step:2: Wait for the certain duration
Step:3: De-REGISTER USER UE-A (Contact header is using *)
Step:4: Repeat from the step-1
After step:3, clean-up is not happening. Record can be seen in SQL.
Note: If de-register contains specific CONTACT header, then cleanup is happening.
### 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).
-->
```
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: DEBUG: <script>: Contact headervalue: *
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=25 a=63 n=assign
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=26 a=26 n=xlog
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: DEBUG: <script>: Full URI from sip:49404965200004@open-ims.test: sip:49404965200004@open-ims.test
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=33 a=63 n=assign
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=34 a=63 n=assign
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=36 a=63 n=assign
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=37 a=26 n=xlog
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=38 a=63 n=assign
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=39 a=26 n=xlog
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=46 a=16 n=if
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=43 a=26 n=xlog
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=54 a=16 n=if
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=46 a=25 n=is_present_hf
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=47 a=26 n=xlog
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=50 a=25 n=append_hf
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=54 a=26 n=xlog
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=55 a=25 n=pcscf_save_pending
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: ims_registrar_pcscf [save.c:318]: save_pending(): No contact headers
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: DEBUG: ims_registrar_pcscf [save.c:492]: save_pending(): Error saving pending contact
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=67 a=16 n=if
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=65 a=63 n=assign
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[] c=[] l=0 a=12 n=seturi
May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=71 a=26 n=xlog
```
#### 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 -v
version: kamailio 5.7.5 (x86_64/linux) 58499a-dirty
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: 58499a -dirty
compiled on 11:23:55 May 8 2024 with gcc 9.4.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: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3848
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3848(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.
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.
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.
-->
Hello, when I was testing the SMSC SMS business, I found that the SMS could not be forwarded by the SMSC when the characters were too long, approximately 117 characters. The issue was traced back to the smsops module, which has a limit on the length of the SMS, but it seems that it does not handle SMS segmentation. The error message returned is as follows. Could you please provide some suggestions and help?
### 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
```
2024-04-24T05:59:01.837950514Z 3(24) ERROR: <script>: SMS for "" (Valid: 0 )
2024-04-24T05:59:14.466167796Z 2(23) ERROR: <script>: 3GPP-SMS: MESSAGE (sip:+8618107550088@ims.mnc011.mcc460.3gppnetwork.org (172.22.0.20:6060) to tel:+8613800138000, bnecb4LQJ(a)10.46.2.1)
2024-04-24T05:59:14.466173859Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length!
2024-04-24T05:59:14.466175929Z 2(23) ERROR: smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request!
2024-04-24T05:59:14.466191554Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length!
2024-04-24T05:59:14.466194545Z 2(23) ERROR: smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request!
2024-04-24T05:59:14.466196517Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length!
2024-04-24T05:59:14.466198406Z 2(23) ERROR: smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request!
2024-04-24T05:59:14.466200311Z 2(23) ERROR: <script>: SMS for "" (Valid: )
2024-04-24T05:59:14.466255812Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length!
2024-04-24T05:59:14.466276249Z 2(23) ERROR: smsops [smsops_impl.c:1903]: isRPDATA(): Error getting/decoding RP-Data from request!
```
#### 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).
-->
```
```
![image](https://github.com/kamailio/kamailio/assets/152272255/808e65ce-9763-4056-9924-77122f6d9c25)
### 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`
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 4fb8ac -dirty
compiled on 03:11:49 Apr 24 2024 with gcc 9.4.0
```
version: kamailio 5.9.0-dev0 (x86_64/linux) 4fb8ac-dirty
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_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
```
* **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 sder 4.15.0-128-generic #131-Ubuntu SMP Wed Dec 9 06:57:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3822
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3822(a)github.com>
r2val(): converting STRING [test]
8(18) DEBUG: permissions [address.c:179]: reload_address_db_table(): Number of rows in address table: 3
8(18) DEBUG: permissions [address.c:191]: reload_address_db_table(): failure during checks of database value 1 (group) in address table
8(18) ERROR: permissions [address.c:233]: reload_address_db_table(): database problem - invalid record
mysql> desc ka_address;
+---------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------+-------------+------+-----+---------+-------+
| id | double | NO | | 0 | |
| grp | bigint | NO | | 0 | |
| ip_addr | varchar(64) | YES | | NULL | |
| mask | bigint | NO | | 0 | |
| port | bigint | NO | | 0 | |
| tag | varchar(4) | NO | | | |
+---------+-------------+------+-----+---------+-------+
when address table use bigint for grp,error happened when load address data
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3922
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3922(a)github.com>