sr-dev April 2025

sr-dev@lists.kamailio.org

14 participants
205 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] 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] 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] generate rpm packages using github actions (PR #4194)
by sergey-safarov 17 May '25

17 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 I have refactored the rpm packaging and am now using the GitHub actions. Now `tar.gz` archive with rpm packages, source rpm and deps rpm files attached to the release message like. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4194 -- Commit Summary -- * generate rpm packages using github actions -- File Changes -- A .github/workflows/rpm.yml (57) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4194.patch https://github.com/kamailio/kamailio/pull/4194.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4194 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4194(a)github.com>

2 5

[kamailio/kamailio] ims_auth: replaced t_continue_skip_timer with t_continue in cxdx_mar.c (PR #4206)
by Amin Nazari 17 May '25

17 May '25

- fixed log message in MAR Async CDP callback - fixed executing cfg_action after sending MAR Diameter request - cfg_action is the callback parameter of the ims_www_challenge function   #### 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) - [ ] 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 #4205 (replace XXXX with an open issue number) #### Description Based on the description in issue #4205, this PR will fix a bug in ims_auth module related to MAR Diameter request callbacks, by replacing the call to t_continue function with t_continue_skip_timer, after the MAR request is sent, the control will successfully move to the cfg action in Kamailio scripts. Just like what we already have in ims_registrar_scscf module, using t_continue_skip_timer instead of t_continue cause the transaction to be found and resumed. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4206 -- Commit Summary -- * ims_auth: replaced t_continue_skip_timer with t_continue in cxdx_mar.c -- File Changes -- M src/modules/ims_auth/cxdx_mar.c (6) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4206.patch https://github.com/kamailio/kamailio/pull/4206.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4206 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4206(a)github.com>

2 1

[kamailio/kamailio] Topos not working Properly for ACK (Issue #4208)
by Pandi1981 14 May '25

14 May '25

Pandi1981 created an issue (kamailio/kamailio#4208) We are facing an issue while using TOPOS in Kamailio P-CSCF (running under Docker). Kamailio version: 6.0.0 operating system: "10 (buster)" **Call Flow & Issue Description:** Note: Public IP and Private IP mapping using the below configuration. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ listen=udp:LOCAL_IP:5060 name "internal" listen=udp:LOCAL_IP:6080 advertise PUBLIC_IP:6080 name "external" ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ **Call Flow (INVITE):** A-Party --> Kamailio P-CSCF (Public IP) --> Kamailio P-CSCF (Private IP) --> Kamailio S-CSCF (Private IP) B-Party <-- Kamailio P-CSCF (Public IP) <-- Kamailio P-CSCF (Private IP) <-- Kamailio S-CSCF (Private IP) Everything works correctly up to the point where the 200 OK is received by the A-Party. However, when the A-Party sends the ACK, it is received by the Kamailio P-CSCF but is not forwarded to the B-Party. Upon investigation, we found that when Kamailio receives the ACK from the A-Party, the rr (Record-Route) module fails to recognize its own Route header and thus falls back to strict routing instead of performing loose routing. This results in an incorrect rewrite of the Request-URI of the ACK, causing it to fail to reach the B-Party. Essentially, the Route header is not popped as expected and the ACK routing breaks. TOPOS module is configured as follows: loadmodule "topos_redis.so" loadmodule "ndb_redis.so" loadmodule "topos.so" modparam("ndb_redis", "server", "name=tps;addr=127.0.0.1;port=6379;db=0") modparam("topos", "storage", "redis") modparam("topos_redis", "serverid", "tps") modparam("topos", "rr_update", 1) modparam("topos", "contact_mode", 1) modparam("topos", "xavu_field_a_contact", "a_contact") modparam("topos", "xavu_field_b_contact", "b_contact") modparam("topos", "xavu_cfg", "tps") Please guide us how to achieve and what we are doing wrong. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4208 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4208(a)github.com>

2 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