sr-dev April 2025

sr-dev@lists.kamailio.org

14 participants
201 discussions

[kamailio/kamailio] tls: Create one shared context and reuse it. (PR #3972)
by Xenofon Karamanos 28 May '25

28 May '25

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #3823 #### Description  This PR aims to implement what was discussed in [mailing list](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-dev@lists.kama… regarding some `tls.reload` and increasing memory usage. It adds a new parameter `enable_shared_ctx` in `tls` module that if set to 0, preserves the old behavior and if set to 1 (other than 0 tbh), it creates a single SSL context that is being shared. This have the effect of using way less memory when initialized as well, but also minimizes (can't say it fixes the problem) the `tls.reload` memory increase. I have also added a small markdown (comparison.md) file, where some comparisons where made between enabled/disabled shared context and with/without CA file (where the initial problem was occurring by the reporter). Feedback would be necessary to verify whether this patch, acts as expected and kamailio works as intented. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3972 -- Commit Summary -- * tls: Add parameter for shared contexts * tls: Comparison for enable_shared_ctx -- File Changes -- A comparison.md (15) M src/modules/tls/tls_domain.c (172) M src/modules/tls/tls_mod.c (11) M src/modules/tls/tls_mod.h (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3972.patch https://github.com/kamailio/kamailio/pull/3972.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3972 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3972(a)github.com>

4 12

[kamailio/kamailio] tcp_send_timeout does not apply for outbound connections (Issue #4187)
by Oleg Vedeneev 28 May '25

28 May '25

ovedeneev created an issue (kamailio/kamailio#4187) ### Description [tcp_send_timeout](https://www.kamailio.org/wikidocs/cookbooks/5.8.x/core/#t… option does not apply for outbound connections. #### Reproduction 1. Establish TCP OPTIONS between Kamailio and target node. 2. On target node block incoming traffic from Kamailio node using iptables. 3. Notice on Kamailio node that TCP retransmission packets don't follow tcp_send_timeout settings, instead they fall back to kernel's net.ipv4.tcp_retries2 settings. ### Additional Information * **Kamailio Version** ``` # kamailio -V version: kamailio 5.8.2 (aarch64/linux) 446039 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-NOSMP, 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: 446039 compiled on 14:32:09 Nov 14 2024 with gcc 8.5.0 ``` * **Operating System**: ``` Linux xxx 4.18.0-553.6.1.el8.aarch64 #1 SMP Thu May 30 04:10:32 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4187 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4187(a)github.com>

3 2

[kamailio/kamailio] core: local TCP socket is bound on listening address (PR #3925)
by sergey-safarov 28 May '25

28 May '25

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description As a local IP address for TCP sending operation the Kamailio service is taking the same network_interface/IP_address, which is used by the service for TCP listening. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3925 -- Commit Summary -- * core: local TCP socket is bound on listening address -- File Changes -- M src/core/tcp_main.c (24) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3925.patch https://github.com/kamailio/kamailio/pull/3925.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3925 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3925(a)github.com>

5 16

[kamailio/kamailio] Frequent hangs in Kamailio probably related due to lock contention in xhttp_prom module with high concurrency (Issue #4209)
by Henning Westerholt 23 May '25

23 May '25

henningw created an issue (kamailio/kamailio#4209) Frequent hangs in Kamailio probably related due to lock contention in xhttp_prom module. ### Environment: The systems are using 32 Kamailio worker processes for the relevant network interface, Its also using Prometheus counter increment operations more than 30 times in the cfg during INVITE processing. The Kamailio uses otherwise no database or other IO related services. Kamailio version 5.8.3, but no relevant changes in the xhttp_prom module could be found. ### Quick summary of the findings: Multiple systems showed frequent hangs in their Kamailio servers on a customer setup. It happens usually after a few hours that all Kamailio processes gets blocked, and no more traffic can be processed on the respective system. I have analysed three stack traces of the Kamailio on one of the system that showed the behaviour. Two without problems and one that was created from during a period where the server had problems. ### Details: Here some details of the stack traces from a problematic case. The relevant processes are from PID 494551 to 494582. The majority of all of these processes are blocked in paths related to the Prometheus module (PID 494551 to 494576): #### PID 494551: ``` #1 0x00007fc69ea5f053 in futex_get (lock=0x7fc4a147acd0) at ../../core/mem/../futexlock.h:108 v = 2 i = 1024 #2 0x00007fc69ea70f99 in prom_counter_inc (s_name=0x7fffe339ffa0, number=1, l1=0x7fffe339ff90, l2=0x0, l3=0x0) at prom_metric.c:1154 p = 0x6b __func__ = "prom_counter_inc" […] #14 0x00000000005ab179 in receive_msg (buf=0x9f47e0 <buf> "INVITE [sip:+1YYYYYYY737@10.XXX.XXX107](sip:+1YYYYYYYYYY737@10.XXX.XX.107) SIP/2.0\r\nRecord-Route: [sip:10.1XXX.XXX.104;lr=on;ftag=HK507HSy55p9F;dlgcor=62b91.985c3](sip:10.XXX.XXX.104;lr=on;ftag=HK507HSy55p9F;dlgcor=62b91.985c3)\r\nRecord-Route: [sip:10.XXX.XXX.117;r2=on;lr;ftag=HK507HSy55p9F](sip:10.XXX.XXX.117;r2=on;lr;ftag=HK507HSy55p9F)\r\nRecord-R"..., len=2819, rcv_info=0x7fffe33a28d0) at core/receive.c:518 ``` Most of the worker processes are in the same state as shown above. Some of the processes are also working in other Prometheus related operations: #### PID 494554: ``` #0 prom_metric_timeout_delete (p_m=0x7fc49ea102f0) at prom_metric.c:646 current = 0x7fc4a2810fd0 ts = 1744143945433 __func__ = "prom_metric_timeout_delete" l = 0x7fc4abffc808 #1 0x00007fc69ea676ce in prom_metric_list_timeout_delete () at prom_metric.c:668 p = 0x7fc49ea102f0 ``` ### Problem hypothesis: My hypothesis is that the hang is caused from lock contention around the Prometheus module. The relevant code uses only one lock, and this together with the extensive usage of the increment counters probably causes this issues under high load. The majority of the worker processed are occupied in the Prometheus path and are not working on SIP packets. This will cause of course an increase of the UDP queue and the described problems. In order to test this hypothesis we removed temporarily the Prometheus logic in the kamailio cfg and see if the issue still persists. The issue did not showed up again after two days of testing, when before it was observed after a few hours. ### Possible solutions: The Prometheus module probably needs some improvements to support better high-load and concurrency situations. On common approach is to split the locks, e.g. using a per process lock array and then combining the individual values in a second pass when read from outside. Alternatively the xhttp_prom module should be used only carefully in situations with a high concurrency setup. I have the full backtrace available, if helpful just let me know. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4209 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4209(a)github.com>

2 1

[kamailio/kamailio] dmq send dialog message failed (Issue #4189)
by QuincyGao 22 May '25

22 May '25

QuincyGao created an issue (kamailio/kamailio#4189)  ### Description  I used dmq on two machines, registered two softphones on the 111 machine, and then used one phone to call another. After the call was connected, dmq sent a dialog message with an error message 400 bad request. Here is the 111 config, 113 almost same to 111: ``` loadmodule "dmq.so" modparam("dmq", "server_address", "sip:172.16.4.111:5464") modparam("dmq", "server_socket", "udp:172.16.4.111:5464") modparam("dmq", "notification_address", "sip:172.16.4.113:5464") modparam("dmq", "notification_channel", "peers") modparam("dmq", "num_workers", 4) modparam("dmq", "ping_interval", 30) loadmodule "dmq_usrloc.so" modparam("dmq_usrloc", "enable", 1) modparam("dmq_usrloc", "sync", 1) modparam("dmq_usrloc", "batch_msg_contacts", 50) # 50 contacts / message modparam("dmq_usrloc", "batch_size", 10000) # 10000 contacts / batch modparam("dmq_usrloc", "batch_usleep", 500000) loadmodule "dialog.so" modparam("dialog", "enable_stats", 1) modparam("dialog", "enable_dmq", 1) ... if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting dlg_manage(); } ``` Here is the sip: <img width="836" alt="Image" src="https://github.com/user-attachments/assets/df609e21-77bb-43e9-a8aa-112069a3…" /> the 113 log error: ``` dialog [dlg_dmq.c:127]: dlg_dmq_handle_msg(): no content length header found ``` ### Troubleshooting #### Reproduction  The inevitable bug #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` 113 log: 22(4389) DEBUG: <core> [core/udp_server.c:708]: udp_rcv_loop(): received on udp socket: (106/100/767) [[KDMQ sip:dialog@172.16.4.113:5464 SIP/2.0 0D 0A Via: SIP/2.0/UDP 172.16.4.111:5464;branch=z9hG4bK28e.2ec7]] 22(4389) DEBUG: <core> [core/receive.c:190]: ksr_evrt_received(): event route core:msg-received not defined 22(4389) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 22(4389) DEBUG: <core> [core/parser/msg_parser.c:722]: parse_msg(): SIP Request: 22(4389) DEBUG: <core> [core/parser/msg_parser.c:724]: parse_msg(): method: <KDMQ> 22(4389) DEBUG: <core> [core/parser/msg_parser.c:726]: parse_msg(): uri: <sip:dialog@172.16.4.113:5464> 22(4389) DEBUG: <core> [core/parser/msg_parser.c:728]: parse_msg(): version: <SIP/2.0> 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Via] type 1 22(4389) DEBUG: <core> [core/parser/parse_via.c:1312]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK28e.2ec78467000000000000000000000000.0>; state=16 22(4389) DEBUG: <core> [core/parser/parse_via.c:2663]: parse_via(): end of header reached, state=5 22(4389) DEBUG: <core> [core/parser/msg_parser.c:592]: parse_headers(): Via found, flags=2 22(4389) DEBUG: <core> [core/parser/msg_parser.c:594]: parse_headers(): this is the first via 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [To] type 3 22(4389) DEBUG: <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=10 22(4389) DEBUG: <core> [core/parser/msg_parser.c:173]: get_hdr_field(): <To> [32]; uri=[sip:dialog@172.16.4.113:5464] 22(4389) DEBUG: <core> [core/parser/msg_parser.c:176]: get_hdr_field(): to body (32)[<sip:dialog@172.16.4.113:5464> ], to tag (0)[] 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [From] type 4 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [CSeq] type 5 22(4389) DEBUG: <core> [core/parser/msg_parser.c:154]: get_hdr_field(): cseq <CSeq>: <10> <KDMQ> 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Call-ID] type 6 22(4389) DEBUG: <core> [core/receive.c:397]: receive_msg(): --- received sip message - request - call-id: [6ecc0d71033645ea-1972(a)172.16.4.111] - cseq: [10 KDMQ] 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/receive.c:263]: ksr_evrt_pre_routing(): event route core:pre-routing not defined 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/receive.c:474]: receive_msg(): preparing to run routing scripts... 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=584 a=26 n=xlog 22(4389) INFO: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <script>: 172.16.4.111:5464|172.16.4.113:5464|udp|KDMQ 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=592 a=16 n=if 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=589 a=25 n=is_method 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=590 a=24 n=dmq_process_message 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dmq [message.c:154]: ki_dmq_process_message_rc(): dmq_handle_message [KDMQ sip:dialog@172.16.4.113:5464] 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dmq [message.c:168]: ki_dmq_process_message_rc(): dmq_handle_message peer found: dialog 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=6c399121368d030ed41b62758342ea91-0405b528 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=29 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dialog [dlg_dmq.c:124]: dlg_dmq_handle_msg(): dmq message received 22(4389) ERROR: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dialog [dlg_dmq.c:127]: dlg_dmq_handle_msg(): no content length header found ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.5 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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: compiled on 11:27:01 Mar 21 2025 with gcc 4.8.5 ``` * **Operating System**:  ``` centos7.9 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4189 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4189(a)github.com>

1 3

[kamailio/kamailio] If fix_nated_contact is used, then remove_hf("Contact"), the contact header will not be deleted cleanly. (Issue #4190)
by QuincyGao 22 May '25

22 May '25

QuincyGao created an issue (kamailio/kamailio#4190)  ### Description  I want to use opensips as SBC, When the agent registers to kamailio, the contact content is modified to the ip and port of kamailio, and then Register is forwarded to the agent. remove_hf("Contact") can't remove the whole Contact( field, vlue). here is my config: ``` route[REGISTRAR] { if (!is_method("REGISTER")) return; if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); #!ifdef WITH_NATSIPPING # do SIP NAT pinging setbflag(FLB_NATSIPPING); #!endif } fix_nated_contact(); if (!save("location","0x02")) { #if (!save("location")) { sl_reply_error(); } $fs="udp:172.16.4.111:5461"; $du="sip:172.16.4.114:5060"; remove_hf("Contact"); $var(contact) = "Contact: <sip:" +$fU+"@"+"172.16.4.111:5461>;expires=120\r\n" ; append_hf("$var(contact)"); route(RELAY); exit; } ``` here is the sip message: ``` 2025/03/26 16:36:07.706093 172.16.4.111:5461 -> 172.16.4.114:5060 REGISTER sip:172.16.4.111:5460 SIP/2.0 Via: SIP/2.0/UDP 172.16.4.111:5461;branch=z9hG4bKfc7e.d2df36f3b5681afeb71e442e645de38d.0 Via: SIP/2.0/UDP 172.16.80.3:49309;received=172.16.80.3;rport=49309;branch=z9hG4bKPj8ab8bd1d3c3a4c1bb0cd639540fa3183 Max-Forwards: 69 From: <sip:1008@172.16.4.111>;tag=95f7f5601f8b40458a1efe6923ab0a29 To: <sip:1008@172.16.4.111> Call-ID: f84b643f5d284d18a0d8175e1ef4d747 CSeq: 33264 REGISTER User-Agent: MicroSIP/3.21.6 sip:1008@172.16.80.3:49309;obExpires: 120 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 Contact: <sip:1008@172.16.4.111:5461>;expires=120 ``` you can see the problem is that: `sip:1008@172.16.80.3:49309;obExpires: 120` , `sip:1008@172.16.80.3:49309` is the value of the Contact field after fix_nated_contact(). ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.5 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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: compiled on 11:27:01 Mar 21 2025 with gcc 4.8.5 ``` * **Operating System**:  ``` Centos7.9 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4190 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4190(a)github.com>

1 2

[kamailio/kamailio] siptrace: sip_trace_mode("d") not working (Issue #4178)
by c.long 22 May '25

22 May '25

longchun4835 created an issue (kamailio/kamailio#4178)  ### Description Using function sip_trace_mode() with parameter d to enable dialog tracing mode logs: ``` BUG: siptrace [siptrace.c:1671]: add_info_xavp(): URI should be in raw format here ERROR: siptrace [siptrace.c:888]: sip_trace_helper(): failed to serialize siptrace info! Won't trace dialog! ``` ### Troubleshooting #### Reproduction my module parameters: ``` #!ifdef WITH_HOMER loadmodule "siptrace.so" modparam("siptrace", "duplicate_uri", HOMER_URL) 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", "hep_capture_id", HOMER_HEP_ID) #!endif ... request_route { ... if (is_method("INVITE")) { sip_trace_mode("d"); } } ``` ### Possible Solutions I checked the source code and found that the issue occurs when sip_trace_helper() is called inside the ki_sip_trace_mode() function, with the third parameter (duri) set to NULL. I don’t quite understand the logic behind passing NULL does this mean that the 'D' parameter will never working when calling sip_trace_mode()? Additionally, I have another question: in the sip_trace_helper() function, why does it call trace_transaction() instead of trace_dialog() when strace_type == SIPTRACE_DIALOG? ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.6.4 (x86_64/linux) a004cf 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 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: a004cf compiled on 09:14:30 Jan 23 2025 with gcc 8.3.1 ``` * **Operating System**: ``` NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4178 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4178(a)github.com>

3 3

[kamailio/kamailio] MAR callback is not executed after a MAR request is sent (ims _auth module) (Issue #4205)
by Amin Nazari 20 May '25

20 May '25

amnapa created an issue (kamailio/kamailio#4205) ### Description Using sCSCF sample found [here](https://github.com/kamailio/kamailio/blob/master/misc/examples/ims/sc…, after calling ims_www_challenge in REGISTER route block and sending a Diameter MAR request, the control is never passed to REG_MAR_REPLY route block and debug messages within REG_MAR_REPLY are not logged. This is not the case with REG_SAR_REPLY and PRE_REG_SAR_REPLY, those blocks are executed as expected. ``` ###################################################################### # Route for handling Registrations: ###################################################################### route[REGISTER] { xlog("ALGORITHM IS [$aa] and User-Agent is [$ua]\n"); $var(alg) = $aa; if ($aa == $null) { $var(alg) = "MD5"; #force to MD5 for zoiper.... non-ims } #!ifdef WITH_AUTH if (!ims_www_authenticate("$td")) { #!else if (($var(alg) == "MD5") && (!ims_www_authenticate("$td"))) { #!endif if ($? == -2) { send_reply("403", "Authentication Failed"); exit; } else if ($? == -3) { send_reply("400", "Bad Request"); exit; } else if ($? == -9) { xlog("L_DBG", "Authentication re-sync requested\n"); ims_www_resync_auth("REG_RESYNC_REPLY", "$td"); exit; } else { #user has not been authenticated. Lets send a challenge via 401 Unauthorized xlog("L_DBG", "About to challenge! auth_ims\n"); ims_www_challenge("REG_MAR_REPLY", "$td", "$var(alg)"); exit; } } else { xlog("L_DBG", "Auth succeeded\n"); # We need to check if this user is registered or not if (!impu_registered("location")) { xlog("L_ERR", "Not REGISTERED\n"); save("PRE_REG_SAR_REPLY", "location"); exit; } else { isc_match_filter_reg("1", "location"); save("REG_SAR_REPLY", "location"); exit; } } } route[REG_MAR_REPLY] { #this is async so to know status we have to check the reply avp xlog("L_DBG", "maa_return code is $avp(s:maa_return_code)\n"); switch ($avp(s:maa_return_code)){ case 1: #success xlog("L_DBG", "MAR success - 401/407 response sent from module\n"); break; case -1: #failure xlog("L_ERR", "MAR failure - error response sent from module\n"); break; case -2: #error xlog("L_ERR", "MAR error - sending error response now\n"); send_reply("500", "MAR failed"); break; default: xlog("L_ERR", "Unknown return code from MAR, value is [$avp(s:maa_return_code)]\n"); send_reply("500", "Unknown response code from MAR"); break; } exit; } ``` ### Troubleshooting #### Reproduction  #### Debugging Data ``` (paste your debugging data here) ``` #### Log Messages ``` ERROR: *** cfgtrace:request_route=[REGISTER] c=[/usr/local/etc/kamailio/kamailio.cfg] l=712 a=27 n=ims_www_challenge DEBUG: ims_auth [authorize.c:290]: challenge(): Looking for route block [REG_MAR_REPLY] INFO: ims_auth [cxdx_mar.c:76]: create_return_code(): created AVP successfully : [maa_return_code] - [-2] DEBUG: ims_auth [authorize.c:314]: challenge(): Need to challenge for realm [ims.mnc072.mcc432.3gppnetwork.org] DEBUG: ims_auth [authorize.c:321]: challenge(): Checking if REGISTER is authorized for realm [ims.mnc072.mcc432.3gppnetwork.org]... DEBUG: ims_auth [authorize.c:1446]: get_auth_userdata(): Searching auth_userdata for IMPU sip:bob@ims.mnc072.mcc432.3gppnetwork.org (Hash 295) DEBUG: ims_auth [authorize.c:1455]: get_auth_userdata(): Found auth_userdata DEBUG: ims_auth [authorize.c:1061]: get_auth_vector(): looping through AV status is 3 and were looking for 0 DEBUG: tm [t_lookup.c:1343]: t_newtran(): msg (0x7f8d3f410cb0) id=1/11 global id=1/11 T start=(nil) DEBUG: tm [t_lookup.c:498]: t_lookup_request(): start searching: hash=21555, isACK=0 DEBUG: tm [t_lookup.c:456]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK3345.d6f2aff0d9192c2647aca3baea62cf94.1] DEBUG: tm [t_lookup.c:681]: t_lookup_request(): no transaction found DEBUG: tm [t_hooks.c:337]: run_reqin_callbacks_internal(): trans=0x7f8d2bff4520, callback type 1, id 0 entered DEBUG: ims_auth [authorize.c:457]: challenge(): Suspending SIP TM transaction DEBUG: ims_auth [authorize.c:1526]: multimedia_auth_request(): Sending MAR DEBUG: ims_auth [cxdx_mar.c:572]: cxdx_send_mar(): Successfully sent async diameter DEBUG: tm [t_lookup.c:1628]: t_lookup_ident_filter(): transaction found INFO: ims_auth [cxdx_avp.c:134]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed finding avp (avp_code = 297, vendor_id = 0) DEBUG: ims_auth [authorize.c:1557]: pack_challenge(): setting QOP str used is [, qop="auth"] DEBUG: ims_auth [authorize.c:1559]: pack_challenge(): QOP str used is [, qop="auth"] DEBUG: tm [t_reply.c:1660]: cleanup_uac_timers(): RETR/FR timers reset DEBUG: tm [t_reply.c:595]: _reply_light(): reply sent out. buf=0x7f8d3f4120b8: SIP/2.0 401 Unauthor..., shmem=0x7f8d2bff9288: SIP/2.0 401 Unauthor DEBUG: tm [t_reply.c:606]: _reply_light(): finished DEBUG: ims_auth [authorize.c:1446]: get_auth_userdata(): Searching auth_userdata for IMPU sip:bob@ims.mnc072.mcc432.3gppnetwork.org (Hash 295) DEBUG: ims_auth [authorize.c:1455]: get_auth_userdata(): Found auth_userdata DEBUG: ims_auth [authorize.c:1679]: add_auth_vector(): Adding auth_vector (status 1) for IMPU sip:bob@ims.mnc072.mcc432.3gppnetwork.org / IMPI bob(a)ims.mnc072.mcc432.3gppnetwork.org (Hash 295) DEBUG: ims_auth [cxdx_mar.c:483]: async_cdp_callback(): DBG:UAR Async CDP callback: ... Done resuming transaction INFO: ims_auth [cxdx_mar.c:76]: create_return_code(): created AVP successfully : [maa_return_code] - [1] DEBUG: ims_auth [cxdx_mar.c:495]: async_cdp_callback(): Destroying current transaction prevented! DEBUG: tm [t_lookup.c:1620]: t_lookup_ident_filter(): transaction in terminated phase - skipping ERROR: tm [t_suspend.c:196]: t_continue_helper(): active transaction not found DEBUG: ims_auth [cxdx_mar.c:84]: free_saved_transaction_data(): Freeing saved transaction data: async ``` #### SIP Traffic ``` (paste your sip traffic here) ``` ### Possible Solutions The issue is related to ims_auth module, in [cxdx_mar.c ](https://github.com/kamailio/kamailio/blob/master/src/modules/ims_auth/cxdx_mar.c). within async_cdp_callback function, if I replace: ``` tmb.t_continue(data->tindex, data->tlabel, data->act); ```` with the following: ``` tmb.t_continue_skip_timer(data->tindex, data->tlabel, data->act); ``` the issue will be fixed and the control will be passed to REG_MAR_REPLY route block. In fact, in ims_registrar_scscf module, in [cxdx_sar.c ](https://github.com/kamailio/kamailio/blob/master/src/modules/ims_registrar_scscf/cxdx_sar.c) file, the t_continue_skip_timer is called instead of t_continue, if I replace it with t_continue the same issue happens for SAR callbacks. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 6.1.0-dev0 (x86_64/linux) c858ce-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 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: c858ce -dirty compiled on 10:33:37 Apr 5 2025 with gcc 11.4.0 ``` * **Operating System**: ``` Distributor ID: Ubuntu Description: Ubuntu 22.04.5 LTS Release: 22.04 Codename: jammy Linux kuber-worker 5.15.0-133-generic #144-Ubuntu SMP Fri Feb 7 20:47:38 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4205 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4205(a)github.com>

2 3

[kamailio/kamailio] ims_dialog: missing srdb1 schema definition (Issue #4100)
by Victor Seva 20 May '25

20 May '25

there's no ``kamailio-ims_dialog.xml`` at ``src/lib/srdb1/schema`` but there's a manual file created at ``utils/kamctl/mysql/ims_dialog-create.sql`` Same thing for: - ``utils/kamctl/mysql/ims_charging-create.sql`` - ``utils/kamctl/mysql/ims_usrloc_pcscf-create.sql`` - ``utils/kamctl/mysql/ims_usrloc_scscf-create.sql`` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4100 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4100(a)github.com>

3 10

[kamailio/kamailio] rtpengine: fix race condn (same ip:port) in parallel forks due to gencookie (PR #4139)
by Souradeep Bera 18 May '25

18 May '25

- avoid parallel calls to gencookie from generating the same cookie for rtpengine #### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4139 -- Commit Summary -- * rtpengine: fix race condn assigning same ip:port due to gencookie in parallel forks -- File Changes -- M src/modules/rtpengine/rtpengine.c (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4139.patch https://github.com/kamailio/kamailio/pull/4139.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4139 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4139(a)github.com>

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2025