sr-dev November 2025

sr-dev@lists.kamailio.org

13 participants
235 discussions

[kamailio/kamailio] Debian 13 - APT repo signature will be rejected within a year (Issue #4502)
by Sda79 13 Jan '26

13 Jan '26

Sda79 created an issue (kamailio/kamailio#4502) ### Description After I installed Kamailio on Debian 13 following https://deb.kamailio.org/ I get the following warning when running `apt update` command : ``` Warning : https://deb.kamailio.org/kamailio60/dists/trixie/InRelease: Policy will reject signature within a year, see --audit for details ``` and after running `apt update --audit`: ``` Audit : https://deb.kamailio.org/kamailio60/dists/trixie/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on E79ACECB87D8DCD23A20AD2FFB40D3E6508EA4C8 is not bound: No binding signature at time 2025-11-06T11:33:50Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z ``` The problem seems to be **SHA1** here. #### Reproduction Install Kamailio repository from deb.kamailio.org on Debian 13 Trixie. I hope it's the right place to post this issue, and that this is not a duplicate. Thank you -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4502 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4502(a)github.com>

3 2

[kamailio/kamailio] ctl: stringop-overflow build warning (Issue #4439)
by sergey-safarov 13 Jan '26

13 Jan '26

sergey-safarov created an issue (kamailio/kamailio#4439) ``` [ 0%] Building C object src/modules/ctl/CMakeFiles/ctl.dir/ctrl_socks.c.o cd /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/redhat-linux-build/src/modules/ctl && /usr/bin/gcc -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DARCH=\"x86_64\" -DCC_GCC_LIKE_ASM -DCFG_DIR=\"/etc/kamailio/\" -DCOMPILER="\"gcc 14.3.1\"" -DCTL_SYSTEM_MALLOC -DDBG_SR_MEMORY -DDISABLE_NAGLE -DDNS_IP_HACK -DFAST_LOCK -DF_MALLOC -DHAVE_ALLOCA_H -DHAVE_EPOLL -DHAVE_GETHOSTBYNAME2 -DHAVE_IP_MREQN -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_MSG_NOSIGNAL -DHAVE_RESOLV_RES -DHAVE_SCHED_SETSCHEDULER -DHAVE_SCHED_YIELD -DHAVE_SELECT -DHAVE_SIGIO_RT -DHAVE_TIMEGM -DHAVE_UNION_SEMUN -DKSR_PTHREAD_MUTEX_SHARED -DMALLOC_STATS -DMEM_JOIN_FREE -DMOD_NAME=\"ctl\" -DMOD_NAMEID=ctl -DNAME=\"kamailio\" -DOS=Linux -DOS_QUOTED=\"Linux\" -DPKG_MALLOC -DQ_MALLOC -DRUN_DIR=\"/run/kamailio\" -DSHARE_DIR=\"/usr/share/kamailio/\" -DSHM_MMAP -DSIGINFO64_WORKAROUND -DSTATISTICS -DTLSF_MALLOC -DTLS_HOOKS -DUSE_CORE_STATS -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLOCKLIST -DUSE_FIFO -DUSE_FUTEX -DUSE_MCAST -DUSE_NAPTR -DUSE_RAW_SOCKS -DUSE_SCTP -DUSE_TCP -DUSE_TLS -DVERSION=\"6.1.0-dev1\" -DVERSIONVAL=6001000 -D__CPU_x86_64 -D__OS_linux -Dctl_EXPORTS -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v3 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -DNDEBUG -std=gnu11 -fPIC -ffile-prefix-map=/root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/= -fPIC -funroll-loops -Wcast-align -m64 -minline-all-stringops -falign-loops -ftree-vectorize -fno-strict-overflow -mtune=generic -MD -MT src/modules/ctl/CMakeFiles/ctl.dir/ctrl_socks.c.o -MF CMakeFiles/ctl.dir/ctrl_socks.c.o.d -o CMakeFiles/ctl.dir/ctrl_socks.c.o -c /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/ctrl_socks.c In function ‘binrpc_build_hdr’, inlined from ‘rpc_send’ at /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:592:18: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc.h:335:20: warning: writing 16 bytes into a region of size 8 [-Wstringop-overflow=] 335 | *p = (unsigned char)(body_len >> ((len_len - 1) * 8)); | ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c: In function ‘rpc_send’: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [2, 10] into destination object ‘hdr.5’ of size 10 575 | static unsigned char hdr[BINRPC_MAX_HDR_SIZE]; | ^~~ In function ‘binrpc_build_hdr’, inlined from ‘rpc_send’ at /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:592:18: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc.h:335:20: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 335 | *p = (unsigned char)(body_len >> ((len_len - 1) * 8)); | ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c: In function ‘rpc_send’: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [42, 2147483628] into destination object ‘hdr.5’ of size 10 575 | static unsigned char hdr[BINRPC_MAX_HDR_SIZE]; | ^~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset 10 into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [42, 2147483628] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset 10 into destination object ‘hdr.5’ of size 10 In function ‘binrpc_build_hdr’, inlined from ‘rpc_send’ at /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:592:18: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc.h:335:20: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 335 | *p = (unsigned char)(body_len >> ((len_len - 1) * 8)); | ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c: In function ‘rpc_send’: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [43, 2147483629] into destination object ‘hdr.5’ of size 10 575 | static unsigned char hdr[BINRPC_MAX_HDR_SIZE]; | ^~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [11, 13] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [43, 2147483629] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [11, 13] into destination object ‘hdr.5’ of size 10 In function ‘binrpc_build_hdr’, inlined from ‘rpc_send’ at /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:592:18: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc.h:335:20: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 335 | *p = (unsigned char)(body_len >> ((len_len - 1) * 8)); | ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c: In function ‘rpc_send’: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [44, 2147483630] into destination object ‘hdr.5’ of size 10 575 | static unsigned char hdr[BINRPC_MAX_HDR_SIZE]; | ^~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [12, 14] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [44, 2147483630] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [12, 14] into destination object ‘hdr.5’ of size 10 In function ‘binrpc_build_hdr’, inlined from ‘rpc_send’ at /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:592:18: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc.h:335:20: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 335 | *p = (unsigned char)(body_len >> ((len_len - 1) * 8)); | ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c: In function ‘rpc_send’: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [45, 2147483631] into destination object ‘hdr.5’ of size 10 575 | static unsigned char hdr[BINRPC_MAX_HDR_SIZE]; | ^~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [13, 15] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [45, 2147483631] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [13, 15] into destination object ‘hdr.5’ of size 10 In function ‘binrpc_build_hdr’, inlined from ‘rpc_send’ at /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:592:18: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc.h:335:20: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 335 | *p = (unsigned char)(body_len >> ((len_len - 1) * 8)); | ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c: In function ‘rpc_send’: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [46, 2147483632] into destination object ‘hdr.5’ of size 10 575 | static unsigned char hdr[BINRPC_MAX_HDR_SIZE]; | ^~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [14, 16] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [46, 2147483632] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [14, 16] into destination object ‘hdr.5’ of size 10 In function ‘binrpc_build_hdr’, inlined from ‘rpc_send’ at /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:592:18: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc.h:335:20: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 335 | *p = (unsigned char)(body_len >> ((len_len - 1) * 8)); | ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c: In function ‘rpc_send’: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [47, 2147483633] into destination object ‘hdr.5’ of size 10 575 | static unsigned char hdr[BINRPC_MAX_HDR_SIZE]; | ^~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [15, 17] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [47, 2147483633] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [15, 17] into destination object ‘hdr.5’ of size 10 In function ‘binrpc_build_hdr’, inlined from ‘rpc_send’ at /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:592:18: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc.h:335:20: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 335 | *p = (unsigned char)(body_len >> ((len_len - 1) * 8)); | ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c: In function ‘rpc_send’: /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [48, 2147483634] into destination object ‘hdr.5’ of size 10 575 | static unsigned char hdr[BINRPC_MAX_HDR_SIZE]; | ^~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [16, 18] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [48, 2147483634] into destination object ‘hdr.5’ of size 10 /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ctl/binrpc_run.c:575:30: note: at offset [16, 18] into destination object ‘hdr.5’ of size 10 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4439 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4439(a)github.com>

3 3

[kamailio/kamailio] For network initiated ue de-registration, ims_registrar_scscf is populating Subscription-State header of NOTIFY message as active;expires=3581 instead of terminated;reason=deactivated (Issue #4296)
by Rik Biswas 12 Jan '26

12 Jan '26

therikb31 created an issue (kamailio/kamailio#4296) For network-initiated UE de-registration, `ims_registrar_scscf` is populating the `Subscription-State` header of the `NOTIFY` message as `active;expires=3581` instead of `terminated`. ### Description We are simulating a network-initiated UE de-registration by sending a **Registration-Termination Request** from the HSS to the S-CSCF for a registered IMSI. **Call Flow**: 1. UE registers to the IMS core 2. S-CSCF performs third-party registration with the Application Server on behalf of the UE 3. Application Server subscribes to `Event: reg` for the registered IMSI 4. HSS sends a Registration-Termination Request for network-initiated UE de-registration 5. S-CSCF sends a `NOTIFY` to subscribers for the `IMS_REGISTRAR_CONTACT_DEREGISTERED` event (issue with the `NOTIFY` SIP message) **Observation**: 1. `NOTIFY` messages are initiated to subscribers of `Event: reg`, but instead of having the `Subscription-State` header set to **terminated**, we observe the value **active;expires=3581**. (Image for the `NOTIFY` SIP message packet is attached below) ![Image](https://github.com/user-attachments/assets/08abc9a8-43b9-486c-9de5-370e465ea527) ### Troubleshooting #### Reproduction To reproduce this, we are performing the following steps: 1. Performing SIP registration of the UE with the target S-CSCF node 2. Sending `SUBSCRIBE` requests from a third-party Application Server and the UE with `Event: reg` to get notified of registration events 3. HSS sends a `Registration-Termination Request` to the target S-CSCF for the registered IMSI (network-initiated de-registration) #### Debugging Data #### Log Messages While going through the logs, we find that this header is being populated based on the expiry timer and a comparison with the current timestamp: ``` 2025-06-20 12:45:20 | 19(56) DEBUG: ims_registrar_scscf [registrar_notify.c:1716]: create_notifications(): Expires is greater than current time! Subscription state: [active;expires=3581] ``` #### SIP Traffic ### Possible Solutions **Workaround**: In the `create_notifications()` method of `src/modules/ims_registrar_scscf/registrar_notify.c`, when populating the `Subscription-State` header, if the `event_type` is `10` (`IMS_REGISTRAR_CONTACT_DEREGISTERED`), we can populate `Subscription-State` as `terminated`. ### Additional Information --- -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4296 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4296(a)github.com>

2 2

[kamailio/kamailio] abnormal queue full request count in high pressure registering test (Issue #4437)
by JiangHai2011 12 Jan '26

12 Jan '26

JiangHai2011 created an issue (kamailio/kamailio#4437) ### Description during relaying pressure test of tcp REGISTER, we found that sometimes tcp_main will report "queue full" when dispatch the fd to child, but the min_busy(tcp_children[i].busy) value can be extremely high(in the real evironment, it can reach 176182), while actually there are not so many requests. ### Troubleshooting in the real evironment, it can reach 176182 send2child(): tcp child 1, socket 25: queue full, 176181 requests queued (total handled 324699543) send2child(): tcp child 1, socket 25: queue full, 176182 requests queued (total handled 324699544) send2child(): tcp child 1, socket 25: queue full, 176183 requests queued (total handled 324699545) send2child(): tcp child 1, socket 25: queue full, 176184 requests queued (total handled 324699546) send2child(): tcp child 1, socket 25: queue full, 176185 requests queued (total handled 324699547) send2child(): tcp child 1, socket 25: queue full, 176186 requests queued (total handled 324699548) send2child(): tcp child 1, socket 25: queue full, 176187 requests queued (total handled 324699549) send2child(): tcp child 1, socket 25: queue full, 176188 requests queued (total handled 324699550) send2child(): tcp child 1, socket 25: queue full, 176189 requests queued (total handled 324699551) send2child(): tcp child 1, socket 25: queue full, 176190 requests queued (total handled 324699552) send2child(): tcp child 1, socket 25: queue full, 176191 requests queued (total handled 324699553) send2child(): tcp child 1, socket 25: queue full, 176192 requests queued (total handled 324699554) send2child(): tcp child 1, socket 25: queue full, 176193 requests queued (total handled 324699555) send2child(): tcp child 1, socket 25: queue full, 176194 requests queued (total handled 324699556) send2child(): tcp child 1, socket 25: queue full, 176195 requests queued (total handled 324699557) but in my local place, due to sipp performance, the queued request is not that high, but by gdb-attaching tcp_main we can see the abnormal queued request count, we can see tcp_children[2].busy is still 1267 in idle time and it will never be back to 0 again (gdb) p tcp_children[0].busy $1 = 0 (gdb) p tcp_children[1].busy $2 = 0 (gdb) p tcp_children[2].busy $3 = 1267 (gdb) p tcp_children[3].busy $4 = 0 (gdb) #### Reproduction use sipp-1 to send REGISTER and use sipp-2 to receive REGISTER and send 200OK and disconnect do this sipp test with 2000cps rate for a long time minutes request_route is simple: tcp_connection_lifetime=3605 tcp_max_connections=102400 tcp_rd_buf_size=8192 tcp_no_connect=no tcp_async=yes tcp_conn_wq_max=256000 tcp_wq_blk_size=4096 tcp_accept_iplimit=102400 open_files_limit=102400 request_route { add_local_rport(); $du = "sip:192.168.130.118:1000;transport=tcp"; forward(); usleep("100"); // here to simulate the service normal processing } #### Debugging Data None #### Log Messages Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: CRITICAL: <core> [core/tcp_main.c:4416]: send2child(): tcp child 1, socket 15: queue full, 3054 requests queued (total handled 151472) Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 15 , queue entry 0, retries 5017, connection 0xffff2ddd8c00, tcp socket 5169, errno=11 (Resource temporarily unavailable) Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 15 , queue entry 1, retries 4968, connection 0xffff2dd13fb0, tcp socket 5193, errno=11 (Resource temporarily unavailable) Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 15 , queue entry 0, retries 5018, connection 0xffff2c8d6620, tcp socket 5369, errno=11 (Resource temporarily unavailable) Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 15 , queue entry 0, retries 5410, connection 0xffff2bddf970, tcp socket 5785, errno=11 (Resource temporarily unavailable) Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 15 , queue entry 1, retries 5402, connection 0xffff2e32ed40, tcp socket 5793, errno=11 (Resource temporarily unavailable) Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 15 , queue entry 2, retries 5394, connection 0xffff2d5f74c0, tcp socket 5801, errno=11 (Resource temporarily unavailable) Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 15 , queue entry 3, retries 5382, connection 0xffff2d253780, tcp socket 5813, errno=11 (Resource temporarily unavailable) Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 15 , queue entry 4, retries 5374, connection 0xffff2c34c490, tcp socket 5821, errno=11 (Resource temporarily unavailable) Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: CRITICAL: <core> [core/tcp_main.c:4416]: send2child(): tcp child 1, socket 15: queue full, 3055 requests queued (total handled 151473) Oct 18 02:20:07 gds-sip-150 sipproxy[3259]: CRITICAL: <core> [core/tcp_main.c:4416]: send2child(): tcp child 1, socket 15: queue full, 3056 requests queued (total handled 151474) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: CRITICAL: <core> [core/tcp_main.c:4416]: send2child(): tcp child 0, socket 13: queue full, 3907 requests queued (total handled 246153) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: CRITICAL: <core> [core/tcp_main.c:4416]: send2child(): tcp child 0, socket 13: queue full, 3908 requests queued (total handled 246154) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 13 , queue entry 0, retries 4706, connection 0xffff2b2ff9d0, tcp socket 5190, errno=11 (Resource temporarily unavailable) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 13 , queue entry 1, retries 4702, connection 0xffff2b308a90, tcp socket 5194, errno=11 (Resource temporarily unavailable) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 13 , queue entry 2, retries 4698, connection 0xffff2b311b50, tcp socket 5198, errno=11 (Resource temporarily unavailable) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 13 , queue entry 3, retries 4694, connection 0xffff2b31ac10, tcp socket 5202, errno=11 (Resource temporarily unavailable) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: CRITICAL: <core> [core/tcp_main.c:4416]: send2child(): tcp child 0, socket 13: queue full, 3909 requests queued (total handled 246155) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 13 , queue entry 0, retries 5062, connection 0xffff2c14f990, tcp socket 5704, errno=11 (Resource temporarily unavailable) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 13 , queue entry 1, retries 5058, connection 0xffff2c158a50, tcp socket 5708, errno=11 (Resource temporarily unavailable) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: ERROR: <core> [core/tcp_main.c:3643]: send_fd_queue_run(): send_fd failed on socket 13 , queue entry 2, retries 4978, connection 0xffff2d0645a0, tcp socket 5788, errno=11 (Resource temporarily unavailable) Oct 18 02:39:35 gds-sip-150 sipproxy[3259]: CRITICAL: <core> [core/tcp_main.c:4416]: send2child(): tcp child 0, socket 13: queue full, 3910 requests queued (total handled 246156) #### SIP Traffic just normal REGISTER as follows: REGISTER sip:6100@aaaaaaaaaa77.a.myucm.cloud:5060;transport=TCP SIP/2.0 Via: SIP/2.0/TCP 192.168.130.118:5060;branch=z9hG4bK-22346-1-0;rport From: <sip:6100@aaaaaaaaaa77.a.myucm.cloud:5060>;tag=1 To: <sip:6100@aaaaaaaaaa77.a.myucm.cloud:5060;transport=TCP> Call-ID: 1-22346(a)192.168.130.118 CSeq: 1 REGISTER Contact: <sip:6100@192.168.130.118:5060;transport=TCP>;expires=3600 Expires: 3600 User-Agent: sipp register test Max-Forwards: 70 Subject: Performance Test Content-Length: 0 ### Possible Solutions in send2child of tcp_main.c, do tcp_children[idx].busy-- before every "return -1;" (as we know, tcp_children[idx].busy-- will only be done after child has finished the task and returned the conn to tcp_main.) ### Additional Information * **Kamailio Version** - output of `kamailio -v` version: kamailio 6.0.1 (aarch64/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-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: unknown compiled on 02:01:11 Oct 18 2025 with gcc 7.3.1 * **Operating System**: Linux sipserver 4.14.320-243.544.amzn2.aarch64 #1 SMP Tue Aug 1 21:03:02 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4437 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4437(a)github.com>

3 4

[kamailio/kamailio] cmake: build on ppc64le arch (Issue #4333)
by sergey-safarov 09 Jan '26

09 Jan '26

sergey-safarov created an issue (kamailio/kamailio#4333) ### Description I want to compile Kamailio sources on `ppc64le` arch. During compilation, I see an error ```sh [ 0%] Building C object src/CMakeFiles/kamailio.dir/main.c.o In file included from /tmp/kamailio/src/core/parser/../mem/../lock_ops.h:92, from /tmp/kamailio/src/core/parser/../mem/shm.h:44, from /tmp/kamailio/src/core/parser/../mem/shm_mem.h:32, from /tmp/kamailio/src/core/parser/../ut.h:46, from /tmp/kamailio/src/core/parser/../ip_addr.h:41, from /tmp/kamailio/src/core/parser/msg_parser.h:39, from /tmp/kamailio/src/core/select.h:36, from /tmp/kamailio/src/core/route_struct.h:35, from /tmp/kamailio/src/core/route.h:39, from /tmp/kamailio/src/main.c:79: /tmp/kamailio/src/core/parser/../mem/../fastlock.h:130:2: error: #error "unknown architecture" 130 | #error "unknown architecture" | ^~~~~ /tmp/kamailio/src/core/parser/../mem/../fastlock.h: In function ‘tsl’: /tmp/kamailio/src/core/parser/../mem/../fastlock.h:294:2: error: #error "unknown architecture" 294 | #error "unknown architecture" | ^~~~~ /tmp/kamailio/src/core/parser/../mem/../fastlock.h: In function ‘get_lock’: /tmp/kamailio/src/core/parser/../mem/../fastlock.h:317:9: error: implicit declaration of function ‘membar_getlock’ [-Wimplicit-function-declaration] 317 | membar_getlock(); | ^~~~~~~~~~~~~~ /tmp/kamailio/src/core/parser/../mem/../fastlock.h: In function ‘release_lock’: /tmp/kamailio/src/core/parser/../mem/../fastlock.h:436:2: error: #error "unknown architecture" 436 | #error "unknown architecture" | ^~~~~ In file included from /tmp/kamailio/src/core/atomic_ops.h:180, from /tmp/kamailio/src/core/locking.h:74, from /tmp/kamailio/src/core/rpc.h:36, from /tmp/kamailio/src/core/sr_module.h:38, from /tmp/kamailio/src/main.c:85: /tmp/kamailio/src/core/atomic/atomic_unknown.h: At top level: /tmp/kamailio/src/core/atomic/atomic_unknown.h:53:2: warning: #warning no native memory barrier implementations, falling back to slow lock based workaround [-Wcpp] 53 | #warning no native memory barrier implementations, falling back to slow lock \ | ^~~~~~~ gmake[2]: *** [src/CMakeFiles/kamailio.dir/build.make:76: src/CMakeFiles/kamailio.dir/main.c.o] Error 1 gmake[1]: *** [CMakeFiles/Makefile2:3359: src/CMakeFiles/kamailio.dir/all] Error 2 gmake: *** [Makefile:156: all] Error 2 ``` ### Expected behavior Sources compiled without error messages. #### Actual observed behavior Build failed be error described above. ### Reproduction ```sh git clone https://github.com/kamailio/kamailio.git docker run -it \ --platform linux/ppc64le \ -v ./kamailio:/usr/src/kamailio \ ghcr.io/sergey-safarov/kamailio-builder:centos-10 cd /usr/src/kamailio cmake -S . -B build cmake --build build ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4333 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4333(a)github.com>

6 46

[kamailio/kamailio] topos_htable: remove smethod from transaction key (PR #4425)
by Stefan Mititelu 09 Jan '26

09 Jan '26

3 10

[kamailio/kamailio] TLS: sporadic decrypt error (Issue #4445)
by Sebastian Damm 08 Jan '26

08 Jan '26

SipSeb created an issue (kamailio/kamailio#4445) ### Description  After a small outage, where a large number of TLS clients had to reconnect, we see this error on some of our Kamailio proxies. The Kamailio processes were not restarted. See log messages below. These errors did not occur before the outage. And on some hosts we still don't see them. It can also be reproduced with running openssl manually, and our monitoring script registering through each proxy is also affected. A pcap trace shows that Kamailio sends its Server Hello, Change Cipher Spec message and some application data and then the client drops the connection with a "Decrypt Error". The next monitoring check run mostly works. Below is a graph showing the log volume of lines containing "decrypt error" in the time before and after the outage. <img width="1385" height="223" alt="Image" src="https://github.com/user-attachments/assets/f9522986-ef10-4798-bd8c-5dd51abd…" /> #### Log Messages  ``` ERROR: tls [tls_server.c:1312]: tls_h_read_f(): protocol level error ERROR: tls [tls_util.h:49]: tls_err_ret(): TLS accept:error:0A00041B:SSL routines::tlsv1 alert decrypt error (sni: unknown) ERROR: tls [tls_server.c:1316]: tls_h_read_f(): src addr: 2a05:d014:85b:a080:f1e7:affe:affe:cc1e:35604 ERROR: tls [tls_server.c:1319]: tls_h_read_f(): dst addr: 2a05:d014:cda:9301:81e5:affe:affe:251a:5061 ERROR: <core> [core/tcp_read.c:1524]: tcp_read_req(): error reading - c: 0x784904a5bfa0 r: 0x784904a5c0c8 (-1) ERROR: tls [tls_server.c:1312]: tls_h_read_f(): protocol level error ERROR: tls [tls_util.h:49]: tls_err_ret(): TLS accept:error:0A00041B:SSL routines::tlsv1 alert decrypt error (sni: unknown) ERROR: tls [tls_server.c:1316]: tls_h_read_f(): src addr: 192.0.2.42:33278 ERROR: tls [tls_server.c:1319]: tls_h_read_f(): dst addr: 100.68.1.13:5061 ERROR: <core> [core/tcp_read.c:1524]: tcp_read_req(): error reading - c: 0x784904a5bfa0 r: 0x784904a5c0c8 (-1) ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` root@sipproxy:/WORKSPACE/sipproxy-container# kamailio -V version: kamailio 5.8.6 (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: unknown compiled with gcc 13.3.0 ``` * **Operating System**:  Running in a podman container. Underlying system is Ubuntu Noble as well. ``` root@sipproxy:/WORKSPACE/sipproxy-container# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 24.04.3 LTS Release: 24.04 Codename: noble root@sipproxy:/WORKSPACE/sipproxy-container# uname -a Linux sipproxy 6.8.0-83-generic #83-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 5 21:46:54 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/4445 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4445(a)github.com>

4 7

[kamailio/kamailio] IMS_PCSCF: handle_tcpconn_ev failed (Issue #4436)
by Nic the nothing 05 Jan '26

05 Jan '26

nicthenothing created an issue (kamailio/kamailio#4436) Description When using Kamailio IMS (from docker_open5gs setup) as the P-CSCF, SIP calls fail to initiate when the UE’s signaling (“ear” channel) and media (“mouth” channel) are bound to different ports or sockets. In the captured logs, the Request-URI and the Destination-URI differ in both port and alias parameters, resulting in the INVITE not being routed properly through the IPSec tunnel. It seems that Kamailio does not correctly resolve the IPSec tunnel when the UE’s contact and destination information differ (possibly due to alias handling or flag configuration). This issue may relate to improper handling of the alias parameter or flag mismatch between use_dst_uri and use_contact. --- Troubleshooting Reproduction 1. Deploy the default IMS setup from herlesupreeth/docker_open5gs (Kamailio + Open5GS). 2. Attach a UE over IPSec where its signaling and media sockets differ (e.g., TCP vs UDP port mismatch). 3. Initiate a SIP INVITE from UE-A to UE-B. 4. Observe that INVITE fails to reach the destination. Debugging Data N/A (default Docker config used) Log Messages 2025-10-15T13:21:33.638305291Z Destination URI: sip:10.20.7.216:42602;transport=tcp 2025-10-15T13:21:33.638307845Z Request URI: sip:3c7a3414-8cf7-458e-a674-9181ea0ccd15@10.20.7.216:42078 --- SIP Traffic Request-Line: INVITE sip:578da559-1f6e-430f-a953-8e4dfc99918e@10.20.7.228:40404;alias=10.20.7.228~43426~2 SIP/2.0 Request-URI: sip:578da559-1f6e-430f-a953-8e4dfc99918e@10.20.7.228:40404;alias=10.20.7.228~43426~2 Request-URI User Part: 578da559-1f6e-430f-a953-8e4dfc99918e Request-URI Host Part: 10.20.7.228 Request-URI Host Port: 40404 --- Possible Solutions Validate handling of alias parameter in IPSec tunnel search logic. Verify if flag 4 (Use destination URI for IPSec tunnel search) or flag 8 (Use new R-URI for IPSec tunnel search) needs adjustment in modparam("ipsec", "flag", X) for correct behavior. Potential fix may involve extending alias resolution to new R-URI before tunnel lookup. --- Additional Information Kamailio Version: version: kamailio 5.7.x (from docker_open5gs) Operating System: Ubuntu 22.04 (containerized) Linux 5.15.0-122-generic -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4436 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4436(a)github.com>

6 15

[kamailio/kamailio] Feature/auth arnacon (PR #4470)
by Ariana 05 Jan '26

05 Jan '26

#### 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:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Add auth_arnacon module for ENS-based authentication with blockchain verification This PR introduces a new authentication module that provides ENS (Ethereum Name Service) domain-based authentication with cryptographic signature verification. The module enables users to authenticate using their ENS domains (e.g., user.cellact.global) instead of traditional username/password combinations. The module uses blockchain networks (Ethereum/Polygon) to verify ENS domain ownership, then validates cryptographic signatures to authenticate users. **Key Features:** - ENS domain-based authentication via Ethereum/Polygon networks - Blockchain-based ENS ownership verification through ENS Registry and Name Wrapper contracts - ECDSA signature verification using secp256k1 for cryptographic authentication - Support for both traditional and wrapped ENS domains with automatic detection - Timestamp validation and replay attack protection via configurable signature timeout - Multi-network support (Polygon, Ethereum mainnet, testnets, custom networks) - Configurable parameters: ens_registry_address, rpc_url, signature_timeout, debug_mode - Implemented functions: arnacon_authenticate and arnacon_user_exists for SIP authentication - Comprehensive error handling for network failures and blockchain connectivity issues **Files Added:** - auth_arnacon.c, auth_arnacon.h (main module files) - arnacon_core.c, arnacon_core.h (core ENS resolution and signature verification) - keccak256.c, keccak256.h (Keccak-256 hashing implementation) - Comprehensive documentation in doc/ subfolder (auth_arnacon.xml, auth_arnacon_params.xml, auth_arnacon_functions.xml, auth_arnacon_faq.xml) - Makefile and CMakeLists.txt with libcurl and libsecp256k1 dependency handling **Testing Summary:** - **Build Verification:** Module compiles successfully with curl and secp256k1 dependencies - **Load Testing:** Module loads without errors in Kamailio configuration - **Authentication Scenarios:** - Valid credentials: Successful authentication with correct ENS domain and signature - ENS domain authentication: Support for ENS domain-based authentication (e.g., user.cellact.global) - Invalid credentials: Proper rejection of invalid signatures or non-existent ENS domains - Network failures: Graceful handling of blockchain RPC connectivity issues - Parameter validation: All module parameters properly validated - **Security Testing:** - Timestamp validation: Replay attack prevention via signature timeout - Signature verification: ECDSA signature recovery and address matching - ENS ownership verification: Blockchain state verification for domain ownership **Documentation Status:** - Complete XML documentation in doc/ subfolder - Module parameters documented (auth_arnacon_params.xml) - Functions documented (auth_arnacon_functions.xml) - FAQ section with troubleshooting and configuration examples (auth_arnacon_faq.xml) - Configuration examples provided for Polygon and Ethereum networks - Usage patterns and best practices included **Limitations:** - Requires external blockchain RPC endpoints (Polygon/Ethereum for ENS resolution) - Network dependency for authentication (no offline fallback) - Requires libcurl library for HTTP requests to blockchain RPC endpoints - Requires libsecp256k1 library for ECDSA signature operations - Authentication speed depends on blockchain network response time - ENS resolution requires RPC calls to blockchain network **Build System:** - Uses standard Kamailio Makefile with curl and secp256k1 library linking - Includes CMakeLists.txt with proper dependency handling using find_package(CURL) and pkg_check_modules for secp256k1 - Module included in MOD_LIST_UTILS in cmake/groups.cmake This module provides ENS-based authentication that leverages blockchain networks for domain ownership verification and cryptographic signatures for secure SIP authentication. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4470 -- Commit Summary -- * cmake: add auth_arnacon to MOD_LIST_UTILS group * auth_arnacon: initial ENS-based authentication module -- File Changes -- M cmake/groups.cmake (2) A src/modules/auth_arnacon/CMakeLists.txt (29) A src/modules/auth_arnacon/Makefile (15) A src/modules/auth_arnacon/README (510) A src/modules/auth_arnacon/arnacon_core.c (1034) A src/modules/auth_arnacon/arnacon_core.h (156) A src/modules/auth_arnacon/auth_arnacon.c (340) A src/modules/auth_arnacon/auth_arnacon.h (20) A src/modules/auth_arnacon/doc/Makefile (6) A src/modules/auth_arnacon/doc/auth_arnacon.xml (145) A src/modules/auth_arnacon/doc/auth_arnacon_faq.xml (196) A src/modules/auth_arnacon/doc/auth_arnacon_functions.xml (196) A src/modules/auth_arnacon/doc/auth_arnacon_params.xml (126) A src/modules/auth_arnacon/keccak256.c (339) A src/modules/auth_arnacon/keccak256.h (39) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4470.patch https://github.com/kamailio/kamailio/pull/4470.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4470 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4470(a)github.com>

3 13

[kamailio/kamailio] Topos not working Properly for ACK (Issue #4208)
by Pandi1981 03 Jan '26

03 Jan '26

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>

5 10

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2025