sr-users June 2025

sr-users@lists.kamailio.org

42 participants
45 discussions

$http_rs shows 401 even when final response is 201 (http_async_query + Basic Auth)
by Joel Serrano 17 Jun '25

17 Jun '25

Hi all, I'm seeing some unexpected behavior from $http_rs when using http_async_query() to send a POST request to an endpoint that requires Basic (username/password) authentication. When I use: ``` $http_req(username) = "someuser"; $http_req(password) = "somepass"; ``` the request goes through and the server responds with a *201 Created*, as expected. The response body ($http_rb) contains the correct result. However, $http_rs still shows *401 Unauthorized*. I believe this happens because curl receives a 401 challenge first, then retries with the provided credentials and gets the correct 201. It seems $http_rs is reflecting the status from the initial challenge rather than the final response. This is on Kamailio v6.0.1. As a workaround, I tried manually setting the *Authorization* header like this: ``` $var(credentials) = "someuser:somepass"; $http_req(hdr) = "Authorization: Basic " + $(var(credentials){s.encode.base64}); ``` In that case, $http_rs correctly shows 201. Is it expected for $http_rs to stay at 401 in the first scenario? Or should it reflect the final status code after curl completes the full request cycle? Thanks, Joel.

2 1

Kamailio server not forwarding acknowledgement of 200-OK response to callee
by smh2017＠zoho.com 16 Jun '25

16 Jun '25

Problem: The Kamailio server sends an ack back to the caller UA [Frame 67 below] that it has received its ACK to callee's SIP-Request but Kamailio does not forward the caller UA response to the callee UA. Callee UA continues to send 200-OKs, waiting for an ACK that never arrives, and eventually hangs up. (Note: Blink UAs substitute number ids for user names during call transactions.) Below is some config info. WOW (192.168.1.13) = Blink caller UA registered with Kamailio server on 5060 AMD (192.168.1.11) = Blink callee UA registered with Kamailio server on 5060 Kamailio server @ (192.168.100.50) Kamailio config snippet listen=tls:192.168.100.50:6050 advertise pub-ip-domain.net:6050 listen=tls:192.168.100.50:5061 advertise pub-ip-domain.net:5061 listen=tcp:192.168.100.50:5060 advertise pub-ip-domain.net:5060 Rtpengine config snippet interface = internal/192.168.100.50;external/pub-ip-domain.net WOW and AMD are in a common LAN, Kamailio is in a separate LAN. Both LANs are behind an edge router internet firewall, with port forwarding for SIP port and designated RTP ports to the Kamailio server. The internal LANs are not firewalled from each other. A domain name is associated with the public ip address. Upon answering a call from WOW, AMD sends a 200-OK, expecting WOW to ACK. Kamailio forwards the 200-OK to WOW. The WOW UA responds to the Kamailio Server, sending its ACK [Frame 62] for forwarding, but that does not happen. [Packet 62: 200-OK ACK sent to Kamailio server for forwarding to AMD, but it is not forwarded] Frame 62: 560 bytes on wire (4480 bits), 560 bytes captured (4480 bits) on interface enp1s0, id 0 Section number: 1 Interface id: 0 (enp1s0) Interface name: enp1s0 Encapsulation type: Ethernet (1) Arrival Time: Jun 8, 2025 14:53:39.351196234 EDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1749408819.351196234 seconds [Time delta from previous captured frame: 0.008882710 seconds] [Time delta from previous displayed frame: 0.008882710 seconds] [Time since reference or first frame: 91.952560276 seconds] Frame Number: 62 Frame Length: 560 bytes (4480 bits) Capture Length: 560 bytes (4480 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:tcp:sip] [Coloring Rule Name: TCP] [Coloring Rule String: tcp] .... .... = IG bit: Individual address (unicast) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.1.13, Dst: 192.168.100.50 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 546 Identification: 0x9af3 (39667) 010. .... = Flags: 0x2, Don't fragment 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 127 Protocol: TCP (6) Header Checksum: 0x1466 [validation disabled] [Header checksum status: Unverified] Source Address: 192.168.1.13 Destination Address: 192.168.100.50 Transmission Control Protocol, Src Port: 49990, Dst Port: 5060, Seq: 5605, Ack: 5124, Len: 506 Source Port: 49990 Destination Port: 5060 [Stream index: 0] [Conversation completeness: Incomplete, DATA (15)] [TCP Segment Len: 506] Sequence Number: 5605 (relative sequence number) Sequence Number (raw): 1801511342 [Next Sequence Number: 6111 (relative sequence number)] Acknowledgment Number: 5124 (relative ack number) Acknowledgment number (raw): 2050979231 0101 .... = Header Length: 20 bytes (5) Flags: 0x018 (PSH, ACK) 000. .... .... = Reserved: Not set ...0 .... .... = Accurate ECN: Not set .... 0... .... = Congestion Window Reduced: Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 1... = Push: Set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set [TCP Flags: Â•Â•Â•Â•Â•Â•Â•APÂ•Â•Â•] Window: 8212 [Calculated window size: 2102272] [Window size scaling factor: 256] Checksum: 0x7522 [unverified] [Checksum Status: Unverified] Urgent Pointer: 0 [Timestamps] [Time since first frame in this TCP stream: 91.952560276 seconds] [Time since previous frame in this TCP stream: 0.051442183 seconds] [SEQ/ACK analysis] [This is an ACK to the segment in frame: 49] [The RTT to ACK the segment was: 0.051442183 seconds] [iRTT: 0.000813889 seconds] [Bytes in flight: 506] [Bytes sent since last PSH flag: 506] TCP payload (506 bytes) Session Initiation Protocol (ACK) Request-Line: ACK sip:19350768@192.168.1.11:64901;transport=tcp SIP/2.0 Method: ACK Request-URI: sip:19350768@192.168.1.11:64901;transport=tcp Request-URI User Part: 19350768 Request-URI Host Part: 192.168.1.11 Request-URI Host Port: 64901 [Resent Packet: False] Message Header Via: SIP/2.0/TCP 192.168.1.13:49990;rport;branch=z9hG4bKPja851a221d11c4c9798e08f721afa637f;alias Transport: TCP Sent-by Address: 192.168.1.13 Sent-by port: 49990 RPort: rport Branch: z9hG4bKPja851a221d11c4c9798e08f721afa637f alias Max-Forwards: 70 From: "WOW" <sip:WOW@pub-ip-domain.net>;tag=7c6e2bc0567345288372495eb190f198 SIP from display info: "WOW" SIP from address: sip:WOW@pub-ip-domain.net SIP from address User Part: WOW SIP from address Host Part: pub-ip-domain.net SIP from tag: 7c6e2bc0567345288372495eb190f198 To: <sip:AMD@pub-ip-domain.net>;tag=347c5038ee5c41d8b92a6d473e80cf24 SIP to address: sip:AMD@pub-ip-domain.net SIP to address User Part: AMD SIP to address Host Part: pub-ip-domain.net SIP to tag: 347c5038ee5c41d8b92a6d473e80cf24 Call-ID: 7f8b4805ba4c4bc784370f99085af625 [Generated Call-ID: 7f8b4805ba4c4bc784370f99085af625] CSeq: 18468 ACK Sequence Number: 18468 Method: ACK Route: <sip:pub-ip-domain.net;transport=tcp;lr;nat=yes> Route URI: sip:pub-ip-domain.net;transport=tcp;lr;nat=yes Route Host Part: pub-ip-domain.net Route URI parameter: transport=tcp Route URI parameter: lr Route URI parameter: nat=yes User-Agent: Blink 6.0.3 (Windows) Content-Length: 0 [Packet 67: Kamailio sends acknowledgement back to WOW that it received the 200-OK ACK, but does NOT forward the ACK to AMD.] Frame 67: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface enp1s0, id 0 Section number: 1 Interface id: 0 (enp1s0) Interface name: enp1s0 Encapsulation type: Ethernet (1) Arrival Time: Jun 8, 2025 14:53:39.394825056 EDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1749408819.394825056 seconds [Time delta from previous captured frame: 0.013882451 seconds] [Time delta from previous displayed frame: 0.013882451 seconds] [Time since reference or first frame: 91.996189098 seconds] Frame Number: 67 Frame Length: 54 bytes (432 bits) Capture Length: 54 bytes (432 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:tcp] [Coloring Rule Name: TCP] [Coloring Rule String: tcp] Internet Protocol Version 4, Src: 192.168.100.50, Dst: 192.168.1.13 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT) Total Length: 40 Identification: 0xacb3 (44211) 010. .... = Flags: 0x2, Don't fragment ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 64 Protocol: TCP (6) Header Checksum: 0x4390 [validation disabled] [Header checksum status: Unverified] Source Address: 192.168.100.50 Destination Address: 192.168.1.13 Transmission Control Protocol, Src Port: 5060, Dst Port: 49990, Seq: 5124, Ack: 6111, Len: 0 Source Port: 5060 Destination Port: 49990 [Stream index: 0] [Conversation completeness: Incomplete, DATA (15)] [TCP Segment Len: 0] Sequence Number: 5124 (relative sequence number) Sequence Number (raw): 2050979231 [Next Sequence Number: 5124 (relative sequence number)] Acknowledgment Number: 6111 (relative ack number) Acknowledgment number (raw): 1801511848 0101 .... = Header Length: 20 bytes (5) Flags: 0x010 (ACK) 000. .... .... = Reserved: Not set ...0 .... .... = Accurate ECN: Not set .... 0... .... = Congestion Window Reduced: Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 0... = Push: Not set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set [TCP Flags: Â•Â•Â•Â•Â•Â•Â•AÂ•Â•Â•Â•] Window: 501 [Calculated window size: 64128] [Window size scaling factor: 128] Checksum: 0x4a97 [unverified] [Checksum Status: Unverified] Urgent Pointer: 0 [Timestamps] [Time since first frame in this TCP stream: 91.996189098 seconds] [Time since previous frame in this TCP stream: 0.043628822 seconds] [SEQ/ACK analysis] [This is an ACK to the segment in frame: 62] [The RTT to ACK the segment was: 0.043628822 seconds] [iRTT: 0.000813889 seconds] Note: When the call is reversed (AMD-to-WOW), WOW responds with 200-OK, which Kamailio forwards to AMD, but there is no ack-reponse at all from AMD to Kamailio server. WOW eventually hangs up.

1 0

help. execution in event_route takes too much time
by Сергей Приймак 16 Jun '25

16 Jun '25

- kamailio version version: kamailio 6.0.1 (x86_64/linux) fce50d - operating system where server is running: Linux Ubuntu 24 - CPU architecture of the system - 1 CPU - error log messages from syslog - no errors - if there is a coredump file, use gdb to extract the following: - information about when it happens: - - at startup - at shutdown - at runtime: - permanently ============= ISSUE DESCRIPTION =============== In case of event below, script execution takes too much time (40 sec): *event_route[dispatcher:dst-down] {exec_msg("/bin/bash -c '/usr/local/etc/kamailio/ipassign.sh &'");}* In case I run this script from shell it takes ~2 sec. ----------------------------------------------------------------------------------------------- Configs attached.

2 2

IMS to IMS communication
by ashokhs77＠gmail.com 16 Jun '25

16 Jun '25

I want to do an IMS to IMS communication - for subscriber querying. If a number dialed is not in the database of the local IMS, it should query the remote database via remote IMS and connect, if user is successfully found. Has anyone tried this? what all needs to be taken care for this..? Thanks & regards, Ashok

1 0

hfl not working as well
by ale Gural 14 Jun '25

14 Jun '25

Does anyone know why using $(hfl(Diversion)[0]) cuts off the last part of the value, while hdr doesn't? Thanks!

4 10

rtpengine error: no rtpp_set_list->rset_first
by disa_369＠msn.com 11 Jun '25

11 Jun '25

Hello to everyone. I deployed Kamailio on Debian system. Install was successfull. I have the task to use Kamailio as proxy between Avaya PBX and Videoconference System. Outgoing calls only from IPPhone ----- Avaya PBX ---sip----> Kamailio -----sip----> Video System-IVR Now Im trying setup rtpengine for proxy media . Kamailio has some errors by starting service. ERROR: rtpengine [rtpengine.c:3131]: select_rtpp_set(): no rtpp_set_list->rset_first Jun 06 12:07:00 zaks-sbc01-op /usr/sbin/kamailio[635658]: NOTICE: rtpengine [rtpengine.c:1815]: mod_init(): Default rtpp set 0 NOT found Missed out on something in config?

2 5

dns_hash_put(): unlinked item errors
by JR Richardson 10 Jun '25

10 Jun '25

Hey Folks, Running kamailio 5.8.4, haven't needed or used DNS functions previously but recently completed clearip integration, which requires sip request to use URL instead of IP and resolve where to send request. Within hours of adding URL lookups I started getting dns_hash unlinked errors. I correlated the log errors to when the URL changed IP. I assume the caching is working because kamailio sends to the same IP for a few minutes, then switches IP, sends to new IP for a few minutes, then switches IP again and this activity continues. Here are some log errors: switch IP Jun 10 14:14:17 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b9fcc0 Jun 10 14:14:19 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b9fcc0 switch IP Jun 10 14:15:00 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b9ee00 Jun 10 14:15:03 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b9ee00 switch IP Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8110]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b8e640 Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b8e640 switch IP Jun 10 14:20:37 siprouter1-pve186 /usr/local/sbin/kamailio[8109]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b3eb60 switch IP Jun 10 14:21:12 siprouter1-pve186 /usr/local/sbin/kamailio[8117]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b830f0 Jun 10 14:21:23 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b830f0 Here are my DNS config parameters, nothing I've changed made any difference. And as far as I can tell I'm not dropping any clearip queries. dns=no rev_dns=no use_dns_failover=on dns_try_ipv6=no I did find a patch update for this error back from 2023 and the patch is in my /src/core/dns_cache.c as expected but still getting errors. Any guidance in clearing this error? Thanks. JR

2 1

get ip status from dispatcher
by ale Gural 10 Jun '25

10 Jun '25

Hello, There is a way to get the status of specific ip of dispatcher in kamailio.cfg? not using kamcmd dispatcher.list, thanks!

3 2

How to detect originating and terminating?
by James Morrison 09 Jun '25

09 Jun '25

I'm trying to find a way to differentiate between originating and terminating legs. Currently in kex module, in core_stats.c I'm adding new counters for more response codes, I want to have two sets of counters, one for originating and one for terminating. In ims_getters.c file, I found a function called cscf_has_originating, which by description "Finds if the message contains the orig parameter in the first Route header" I'm calling it like the following: static int km_cb_rpl_stats_by_method(struct sip_msg *msg, unsigned int flags, void *param) { int originating = cscf_has_originating(msg); .... However it always returns CSCF_RETURN_FALSE (or -1). I added a log message and increased log level for core module: DEBUG: <core> [ims_getters.c:561]: cscf_has_originating(): I_originating: Header Route not found ERROR: kex [core_stats.c:424]: km_cb_rpl_stats_by_method(): In kex module received rpls, the return value of cscf_has_originating is: -1 That's because cscf_has_originating function is calling parse_headers function, trying to get msg->route but that route property is not set correctly in the previous step: if(parse_headers(msg, HDR_ROUTE_F, 0) < 0) { LM_DBG("I_originating: error parsing headers\n"); return CSCF_RETURN_FALSE; } so it returns -1 after checking msg->route value. Do you know any alternative solution? or do you know why msg->route value is 0 or NULL?

3 6

siptrace module not respecting send_sock after kamailio 5.6.6
by Daniel Donoghue 09 Jun '25

09 Jun '25

Hello, I have been using the siptrace module on a multihomed kamailio setup for some time now, with kamailio 5.5.7 and 5.6.6, without incident. I am listening to my external interface using something like: listen=tls:external_ip:5061 listen=tcp:external_ip:5060 Listen=tcp:internal_ip:5000 name "homer" And for siptrace... modparam("siptrace", "duplicate_uri", "sip:homer_ip:9060;transport=tcp") modparam("siptrace", "send_sock_name", "homer") I have also used send_sock_addr and force_send... This works as expected. I recently deployed this same setup using kamailio 6.0.1 and discovered that the send_sock is not being respected, even though the logs say it has been selected. Instead, tcpdump and careful examination of all the file descriptors for the kamailio processes reveal it is sending with the source set to my external_ip instead of the internal_ip. I have verified this on the same server, ruling out os level issues routing issues and have tried manually connecting using nc with the internal ip address for the source, which works. I tried downgrading, and found that the same is true for kamailio 5.7.6, 5.8.6 and 6.0.1 This issue only appears to affect siptrace as other sockets appear to use the correct source ip to, for example, connect to a database. I had a look at the change logs and documentation and cant see anything obvious that I need to change from a configuration perspective. Could anybody help? I would prefer to be running 6.0+ in my new production environment but wont be able to if this cannot be solved quickly. Many thanks for your help. With every blessing, -- Daniel Donoghue

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users June 2025